Date: Fri, 22 Nov 2002 23:38:03 -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: <3DDF305B.7C468ED6@mindspring.com> References: <XFMail.20021122105737.jhb@FreeBSD.org> <200211221427.31031.cscotts@mindspring.com> <3DDEC261.B5BEDFDC@mindspring.com> <200211222210.24713.cscotts@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Scott Sipe wrote: > Alright, this is pretty frustrating. I've installed DP2 4 or 5 times now > (each time reformatting). > > The first time the installation program acted really weird and didn't do the > install correctly. Not useful information, but expected, based on your other reports. Most people would accuse you of overclocking. 8-). > The second time I had weird random core dump problems so that I > couldn't even log in. Ditto. > The third time I think was with the trap 12 when I started tcsh... > now I reinstalled and it SEEMS to be working fine. At least enough > that I was able to compile a custom kernel, and compile most of > the gnome suite from ports too (and then to remove it ;). The trap 12 is a real problem. The useful information you posted before was the traceback. The fact that the error occurred where no such error should be possible is indicative of a hardware problem: either bad RAM, or a cooked CPU (usually a result of overclocking), or a CPU bug from the vendor, or a problem with the data as it was transferred from the hard drive (a disk or controller problem; rarely, a driver problem, though it's not likely, since you got as far as you did). > There was ONE problem I had -- one of the g++ include files > (limits) had one line that was corrupted and I could fix. > the line was like: > > coint name_more; (somethingl ike that) > > when it should have been > const int name_more10; If this was actually it, then it dropped 32 bits on its way into cache. Did you try rebooting, to see if the file "healed itself"? This would support the theory of a disk/controller/driver error. Is this maybe a CMD 640B or similar IDE/ATAPI controller? Note that this could also be a result of a dirty cache line and/or a CPU bug, but it's more likely to *change* characters, rather than deleting them. The correct thing to do would probably be to "hd" the file, to see if the characters were not there, or if they were converted to non-displaed characters (e.g. four "0x00"'s). > (line 1710 iirc) > > so basically it seems like I'm getting random data corruption at random times > with random results. fwiw, I'm running stable off the same harddisk as I > type this. Stable has this problem? Yes or No? > sorry if this throws a wrench in things again. No, it doesn't. But it would help if you answered the question about whether or not Stable has the problem, too, and the first three questions I asked. If it's the CPU bug, I *can* provide a kernel that fixes the problem, I believe. I just have to be able to create a kernel that has the problem, first, and since my hardware doesn't have the problem locally, that leaves your hardware, for the testing. -- 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?3DDF305B.7C468ED6>