Date: Tue, 8 May 2001 10:01:52 -0400 From: Rocco Caputo <troc@netrus.net> To: Doug Russell <drussell@saturn-tech.com> Cc: Jonathan Belson <jon@witchspace.com>, freebsd-stable@FreeBSD.ORG Subject: Re: Lockups with -Stable on Athlon Message-ID: <20010508100152.B934@eyrie.homenet> In-Reply-To: <Pine.BSF.4.21.0105071636050.99490-100000@beastie.saturn-tech.com>; from drussell@saturn-tech.com on Mon, May 07, 2001 at 04:40:59PM -0600 References: <3AF6EE86.FC021C05@witchspace.com> <Pine.BSF.4.21.0105071636050.99490-100000@beastie.saturn-tech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I had a problem with at Athlon-1000 HP machine (Pavilion 8860). It would run fine until I tried "make buildworld", and then it would freeze solid. This happened nearly every time, but it might take hours to hang the machine. Nothing else would kill it, though, and I tried a lot of things. Changing the RAM didn't help, and I tried six different modules (three 256MB pc133s; three 128MB pc100s) in a variety of combinations. I finally was able to reproduce the problem quickly and consistently with a small C program: 1. Allocate a 16MB chunk of memory, and strobe it constantly to keep it in physical memory. "strobe" is a function that increments every 256th byte to keep the region active. This strobed 16MB region is what finally made the testcase freeze the machine. Otherwise it would happily run for as long as I'd let it. 2. Allocate 50 chunks of memory, strobing the 16MB chunk after each malloc. 3. Fill each of the 50 memory chunks to swap them in, strobing the 16MB segment after each memset. 4. Free each of the 50 memory chunks, strobing the 16MB segment after each free. Repeat until the system stops responding. In my case, that's usually within 60 to 300 seconds. Yes, 1 to 5 minutes, sometimes a little longer, but a total system freeze every time. The Windows executable is at <http://poe.perl.org/misc/hpdie.zip>; in case someone wants to try it. The file is under 16KB. By default, it allocates fifty 5MB chunks. All told, it's a little more than twice my machine's 128MB physical memory. The chunk size can be tweaked with a single integer argument. `hpdie 10` will allocate 10MB chunks (about 516MB total). `hpdie 0` will probably crash. :) I stupidly deleted the source, and the binary is for Windows, and the machine is on its way to a repair facility, so about all I can offer sourcewise is an untested rewrite from memory. Good luck. -- Rocco Caputo / troc@netrus.net / poe.perl.org / poe.sourceforge.net On Mon, May 07, 2001 at 04:40:59PM -0600, Doug Russell wrote: > > On Mon, 7 May 2001, Jonathan Belson wrote: > > > machine - but again, why do the other OSes work fine? > > Because they can't possibly push your hardware as hard as FreeBSD does. > Adding an extra clock cycle of net delay in one little operation is all it > might take to make one of these timing issues never show up on another OS. > > (Not to mention, they don't usually stay up long enough to find out. :) ) > > All of these people who are seeing the same type of crashing problem, are > all probably using memory that just isn't up to snuff. > > I've seen this NUMEROUS times on Athlons (I use mainly A7Vx boards). > EVERY SINGLE TIME, changing to truly good RAM (ie. Micron, perhaps > Infineon), has cured the problem. Most Hyundai I've seen, for example, > will run fine at 100 MHz in the Athlon, but not at 133 MHz, but will work > fine in many other boards at 133 MHz. > > Of course, I can usually make Windows crash with the poor memory, too. > > Later...... <Doug> 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?20010508100152.B934>