Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel!munnari.oz.au!hp9000.csc.cuhk.hk!uakari.primate.wisc.edu!ames!pacbell.com!network.ucsd.edu!qualcom.qualcomm.com!servo.qualcomm.com!karn From: karn@servo.qualcomm.com (Phil Karn) Subject: Re: Fixed: Runs at 8MHz, Crashes at 33MHz, 386bsd Message-ID: <1992Sep11.200736.20247@qualcomm.com> Sender: news@qualcomm.com Nntp-Posting-Host: servo.qualcomm.com Organization: Qualcomm, Inc References: <1992Sep8.070731.21159@bernina.ethz.ch> Date: Fri, 11 Sep 1992 20:07:36 GMT Lines: 47 In article <1992Sep8.070731.21159@bernina.ethz.ch> torda@igc.ethz.ch (Andrew Torda) writes: >Some time ago, I complained with the following problem: > > At 8 MHz, my machine appears perfectly stable. > At 33 MHz, I get repeated trap type 12 panics. [...] >The most concrete suggestions were to either add wait states or buy >faster memory. Couldn't add any more wait states, but I managed to >swap 8Mb of 80ns simms for 70 ns simms. > >Instantly, I could rebuild kernels or run my little crash program >which simply allocated ever increasing amounts of memory and scribbled >through it. >The peculiarity is that with the old memory, I had been able to run >dos, windows in enhanced mode and even SCO unix. >It would still be nice to know what the cause is and why 386bsd >provokes the problem. Very interesting. I've been having similar problems with my 486-50 (with 16 meg, Adaptec SCSI controller and NE-2000). A good way to crash it is to go into one of the source trees and run make. Often I couldn't get through half a dozen nroff's of man pages before a panic, usually a message from vm_fault() that I interpret to be the kernel dereferencing a bogus pointer. Sometimes it wouldn't even get through the reboot before it would panic again. Applying every patch in sight didn't seem to help the problem. So, inspired by your note, I just tried hitting my machine's Turbo switch, knocking its clock speed down to 10 Mhz (at least that's what the display on the front panel says). And the machine now seems *much* more stable. It's gotten through several source directories without incident so far, albeit much more slowly. One possible theory (stress *theory*): many modern PC chipsets provide registers to control things like bus clock speeds, memory wait states, etc. Much more convenient than the hardware jumpers on old motherboards. Since these are usually set by the BIOS setup program and forgotten, perhaps something in 386BSD is scribbling over them (or their CMOS save areas) unintentionally? Going to faster memory, or slowing the machine down, would let the machine run with these unintentionally changed settings. This theory would also explain why the same machine could run other systems at full speed without problem, because they leave the control registers alone. Comments? Phil