From owner-freebsd-stable Tue Jan 15 11:33: 0 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mcqueen.wolfsburg.de (pns.wobline.de [212.68.68.5]) by hub.freebsd.org (Postfix) with ESMTP id 3B1D537B417 for ; Tue, 15 Jan 2002 11:32:55 -0800 (PST) Received: from colt.ncptiddische.net (ppp-30.wobline.de [212.68.69.30]) by mcqueen.wolfsburg.de (8.11.3/8.11.3/tw-20010821) with ESMTP id g0FJWpw18350; Tue, 15 Jan 2002 20:32:51 +0100 Received: from tisys.org (jodie.ncptiddische.net [192.168.0.2]) by colt.ncptiddische.net (8.11.6/8.11.6) with ESMTP id g0FJYFX85894; Tue, 15 Jan 2002 20:34:16 +0100 (CET) (envelope-from nils@tisys.org) Received: (from nils@localhost) by tisys.org (8.11.6/8.11.6) id g0FJXKC97921; Tue, 15 Jan 2002 20:33:20 +0100 (CET) (envelope-from nils) Date: Tue, 15 Jan 2002 20:32:44 +0100 From: Nils Holland To: Brady Montz Cc: freebsd-stable@FreeBSD.ORG Subject: Re: VIA crahes - solved (it seems)! Message-ID: <20020115203244.A97794@tisys.org> Mail-Followup-To: Brady Montz , freebsd-stable@FreeBSD.ORG References: <20020113224800.A82744@tisys.org> <3C42F7E1.3040508@magpage.com> <200201152200.g0FM0lT28843@mail.hydrologue.com> <20020115183113.A96245@tisys.org> <200201152314.g0FNEvn29022@mail.hydrologue.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200201152314.g0FNEvn29022@mail.hydrologue.com>; from bradym@mail.hydrologue.com on Tue, Jan 15, 2002 at 03:14:57PM -0800 X-Operating-System: FreeBSD jodie.ncptiddische.net 4.5-RC FreeBSD 4.5-RC X-Machine-Uptime: 8:17PM up 10:35, 2 users, load averages: 0.13, 0.03, 0.01 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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