Date: Sat, 23 Nov 2002 01:37:45 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: cscotts@mindspring.com Cc: John Baldwin <jhb@FreeBSD.org>, current@FreeBSD.org Subject: Re: DP2 Fatal Trap Message-ID: <3DDF4C69.A2AB9B5F@mindspring.com> References: <XFMail.20021122105737.jhb@FreeBSD.org> <200211222210.24713.cscotts@mindspring.com> <3DDF305B.7C468ED6@mindspring.com> <200211230346.45917.cscotts@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Scott Sipe wrote: > I didn't make a backup copy (or mark down the errors) of the bad file or try > rebooting which in retrospect would have been a good idea..sorry--I just > fixed the file and saved it so I could compile some ports--and that worked. Just FWIW: if it was a transfer error, a backup copy would have been made from cache. As such, it would only be useful in seeing if the data was zeroed. It wouldn't help in the "lost word during burst transfer" case, or the "reboot to test for self-healing" case. If it happens again, then: (1) hd the file, and determine if the data was lost, or is merely not displaying because it was zeroed, and (2) reboot to see if it "heals". Both of these are very imporant tests. > I have an IWILL KK266 motherboard which has a "AMI MegaRaid" controller and a > VIA Apollo KT133A chipset. The FreeBSD drive is primary master ad0 on the > via ide line (both Current and Stable are on the same disk). I have a dvd > drive and a cdrw on the secondary channel. Then 2 harddisks, one each on the > RAID controller (I use the bios to alternate which drives are used for > booting--the RAID or the IDE) [ ... other information ... ] OK. None of this resembles hardware for which bugs have been reported to the -current or -hackers mailing lists. This is an affirmation (but not positive confirmation) that the problem is not in the disk controller, disk, or FreeBSD driver. The fact that you'v not had strange probelms with -stable indicates for certain that it's not a disk or controller problem. That leaves "other bug" (which is what I thought in the first place) or "driver bug". I don't think it's a driver bug, but I can't prove it isn't. > 1) Yes it happened with a generic kernel straight off the DP2 install CD. OK. No recompiles, fancy driver load directives, etc.. If John Baldwin wants to try and repeat your problem, he *may* need a copy of your rc.conf. DO NOT SEND THIS UNLESS REQUESTED TO DO SO. > 2) I had the problems directly off DP2 iso image burned cd install, so can > that tell you what you need to know about the cvs date or do you want me to > do more? OK; what this means, because there was no tag laid down, and there was not a published checkout datestamp that can be used to duplicate a -current system (according to John, it's a checkout of -CURRENT, hacked to change the name to "DP2" for the build), is that I will have to build a known kernel locally, so that I have source tree that duplicated the failure for you. Do you have it booting DP2 enough to replace the kernel, or is it fully reverted to -STABLE at this point? It would be very hard for me to build a full release CDROM ISO image and transfer it, without sending it through the mail. > 3) Yes, I'm at college on a fast connection (though with a limited upload) so > if you need to I can setup an ftp login for you on my computer. If you can live with just kernel replacements, then if you can set this up, I can give you a kernel which we will then hope *that it fails* as soon as tomorrow, or whenever is convenient, and, after you verify that it does, indeed, fail, then I can do the fix and give you another kernel 2-3 days after that (depending on the porting required, since it involves assmebly language). Let me know. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DDF4C69.A2AB9B5F>