Date: Mon, 27 Mar 2000 10:39:11 -0800 (PST) From: =?iso-8859-1?q?Tommy=20Hallgren?= <thallgren@yahoo.com> To: Jeremiah Gowdy <jgowdy@home.com> Cc: freebsd-smp@FreeBSD.ORG Subject: Re: SMP and vn Message-ID: <20000327183911.18682.qmail@web124.yahoomail.com>
next in thread | raw e-mail | index | archive | help
--- Jeremiah Gowdy <jgowdy@home.com> skrev: > > I've read about Abit BP6 problems(SMP+Idle==hang) on Linux-kern, but > > thought it was a Linux-related problem. :-/ > > Don't say that ! I'm about to buy one :( Hehe, my BP6(2x366Mhz not overclocked) box works just fine. But to worry you even more, read this: http://users.ev1.net/~redelm/ I got the URL from linux-kern. Could it be true that I can damage my computer by using his program? I've never really believed in such programs, but one never knows. :^) Here's the message: From: Robert Redelmeier (redelm@ev1.net) Date: Sun Mar 26 2000 - 13:40:48 EST Samuli wrote: > Yes, a non-idle bp6 machine won't lockup, at least my didn't. When running > a rc5/other number crunching app I have achieved 30+ day uptimes. Make > the machine a 95% idle one and I'll give it a week, max. Tested with > all available BIOSes and the BX-trick. I've been working on the BP6 instability issue for some months now. First I developed `burnP6` to test CPU's and cooling. But machines still locked up, and the MS-Windows crowd reported CRC unzipping errors. So I developed `burnBX` to test RAM and the controller. Success! I can generate RAM errors and occasional lockups. Needless to say, RAM errors are extremely serious, and will certainly cause a crash or lockup if they occur during a kernel instruction fetch. Since the errors are distributed across many addresses, and even in a few different bits, I don't think the SDRAM is actually causing it. Most likely it is a problem with the 3.3V power supply. Also possible is a fundamental weakness in the Celeron IO drivers not being designed for the extra capacitance. Less likely, it is a problem with the BX chip [they've been overclocked to 133 MHz] or mobo trace routing [too simple to follow the rules]. An idle system really isn't. Especially with X active, there will be screen redraws that will approach `burnBX` in severity of RAM loading. The power supply may not be able to handle the load transient well, and the voltage sags too much. I'm a little unhappy with my 300W PS, because I've measured transients down to 3.16V, and statistically it's likely that I get below 3V. Nonetheless, I'm happy with my BP6 and it's week+ stable (loaded or not) at 2 * 5.5 * 97 MHz. I've just released the "stable" :) version of `burnBX`. It is a very intense RAM tester with max bandwidth asm block-move instructions and an evil data pattern to rapidly provoke errors. I still use and recommend Chris Brady's memtest-86 as a general memory tester. Most importantly, it tests kernel-space RAM, which `burnBX` cannot. I would invite people with stability problems to run `burnBX`. I'd be very surprised (and want to hear about) anybody that can run `burnBX` for 1+ hour, yet still gets lockups. > Face it, the board has flaws. The only "flaw" I can see is it uses powersupply 3.3V, instead of regulating it from 5V as some Asus boards do. But that shouldn't be a problem if a good powersupply is chosen. I'd use the AMD Athlon list at http://www1.amd.com/athlon/power . -- Robert Redelmeier author `cpuburn` http://users.ev1.net/~redelm Mvh: Tommy ===== Tommy Hallgren(tommy@frontpartner.com) Briljantg. 31, SE-421 49, Göteborg Tel.: +46 (0)709 - 312 404 (GSM) Tel.: +46 (0)31 - 47 65 28 (Home) __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000327183911.18682.qmail>