home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / bsd / 5554 < prev    next >
Encoding:
Text File  |  1992-09-11  |  2.7 KB  |  60 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!sun-barr!ames!pacbell.com!network.ucsd.edu!qualcom.qualcomm.com!servo.qualcomm.com!karn
  3. From: karn@servo.qualcomm.com (Phil Karn)
  4. Subject: Re: Fixed: Runs at 8MHz, Crashes at 33MHz, 386bsd
  5. Message-ID: <1992Sep11.200736.20247@qualcomm.com>
  6. Sender: news@qualcomm.com
  7. Nntp-Posting-Host: servo.qualcomm.com
  8. Organization: Qualcomm, Inc
  9. References: <1992Sep8.070731.21159@bernina.ethz.ch>
  10. Date: Fri, 11 Sep 1992 20:07:36 GMT
  11. Lines: 47
  12.  
  13. In article <1992Sep8.070731.21159@bernina.ethz.ch> torda@igc.ethz.ch (Andrew Torda) writes:
  14. >Some time ago, I complained with the following problem:
  15. >
  16. >     At 8 MHz, my machine appears perfectly stable.
  17. >     At 33 MHz, I get repeated trap type 12 panics.
  18. [...]
  19. >The most concrete suggestions were to either add wait states or buy
  20. >faster memory. Couldn't add any more wait states, but I managed to
  21. >swap 8Mb of 80ns simms for 70 ns simms.
  22. >
  23. >Instantly, I could rebuild kernels or run my little crash program
  24. >which simply allocated ever increasing amounts of memory and scribbled
  25. >through it.
  26. >The peculiarity is that with the old memory, I had been able to run
  27. >dos, windows in enhanced mode and even SCO unix.
  28. >It would still be nice to know what the cause is and why 386bsd
  29. >provokes the problem.
  30.  
  31. Very interesting. I've been having similar problems with my 486-50
  32. (with 16 meg, Adaptec SCSI controller and NE-2000). A good way to
  33. crash it is to go into one of the source trees and run make. Often I
  34. couldn't get through half a dozen nroff's of man pages before a panic,
  35. usually a message from vm_fault() that I interpret to be the kernel
  36. dereferencing a bogus pointer. Sometimes it wouldn't even get through
  37. the reboot before it would panic again. Applying every patch in sight
  38. didn't seem to help the problem.
  39.  
  40. So, inspired by your note, I just tried hitting my machine's Turbo
  41. switch, knocking its clock speed down to 10 Mhz (at least that's what
  42. the display on the front panel says). And the machine now seems *much*
  43. more stable. It's gotten through several source directories without
  44. incident so far, albeit much more slowly.
  45.  
  46. One possible theory (stress *theory*): many modern PC chipsets provide
  47. registers to control things like bus clock speeds, memory wait states,
  48. etc. Much more convenient than the hardware jumpers on old motherboards.
  49. Since these are usually set by the BIOS setup program and forgotten,
  50. perhaps something in 386BSD is scribbling over them (or their CMOS
  51. save areas) unintentionally? Going to faster memory, or slowing the
  52. machine down, would let the machine run with these unintentionally
  53. changed settings. This theory would also explain why the same machine
  54. could run other systems at full speed without problem, because they
  55. leave the control registers alone.
  56.  
  57. Comments?
  58.  
  59. Phil
  60.