Date: Tue, 15 Jan 2002 20:32:44 +0100 From: Nils Holland <nils@tisys.org> To: Brady Montz <bradym@mail.hydrologue.com> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: VIA crahes - solved (it seems)! Message-ID: <20020115203244.A97794@tisys.org> In-Reply-To: <200201152314.g0FNEvn29022@mail.hydrologue.com>; from bradym@mail.hydrologue.com on Tue, Jan 15, 2002 at 03:14:57PM -0800 References: <20020113224800.A82744@tisys.org> <3C42F7E1.3040508@magpage.com> <200201152200.g0FM0lT28843@mail.hydrologue.com> <20020115183113.A96245@tisys.org> <200201152314.g0FNEvn29022@mail.hydrologue.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 15, 2002 at 03:14:57PM -0800, Brady Montz stood up and spoke: > > One final note, I stress tested it on windows and linux specifically > looking for this problem, with no luck (or good luck, depending on > your point of view, it didn't crash though). And this machine ran > linux without a single crash for years before switching to > BSD. Crashes and all, I've grown fond of BSD and would rather not > switch back. A hardware glitch that is only tickled by one OS is > perfectly feasible. Yes, things are strange at time. As I said, my machine would crash as of last weeks sources, but with this Saturday's sources the problems are gone. The strange think is that according to my knowledge, no parts that could have had to do with the crash I was experiencing were modified in the new sources. So, sometimes it's better not to ask how a problem was solved - after all, a problem solving itself is probably the best thing that can happen to us ;-) > I've tested the RAM with the various ram testing software out there > (memtest86 being my favorite). What can I use to test the CPU or > motherboard? There may be software for that purpose, but from what I have heard such test software often misses problems that get triggered during real-world operations. There will also be hardware test equipment or testing mainboards and CPUs, but getting such stuff is probably not an option. So, what can be done? The best approach is probably swapping. Simply try the CPU in a different motherboard, exchange the RAM, exchange any expansion cards. Using such shuffeling, you should eventually be able to pin the problem down to a certain component, which is then the fualty one that needs replacing. Of course, this approach is sometimes a little hard. I remember when I first bought an Athlon Socket A System which had problems. I couldn't do much component swapping as the only other machines I had were K6-2 /Socket 7 based. Of course I could not swap boards and CPUs between the Socket A and Socket 7 systems ;-) Now that I'm at it, you may also want to set your BIOS settings to some conservative settings. I have seen a machine that behaves a little strange in terms of RAM timing settings. Specifically, if I set the DRAM Timing on that machine to normal, it won't boot at all and hangs during the POST. If I set it to "Turbo" it will boot, but crash under stress. The other tree settings "Medium", "Fast" and "SDRAM 8/10 ns" work totally fine, and the machine will not crash even if I let it repeatedly compile stuff overnight. Bottom line: If a system produces reproducible crashes, I'd first check the BIOS settings, set them to more "unoptimized" values and see what happens. If the problem persists, component swapping is probably the best method to track the problem down, though this may not always be easy due to the lack of exchange components at hand. Greetings Nils -- Nils Holland Ti Systems - FreeBSD in Tiddische, Germany http://www.tisys.org * nils@tisys.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020115203244.A97794>