home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / bsd / 5563 < prev    next >
Encoding:
Text File  |  1992-09-11  |  5.0 KB  |  105 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
  3. From: terry@cs.weber.edu (A Wizard of Earth C)
  4. Subject: Re: Fixed: Runs at 8MHz, Crashes at 33MHz, 386bsd
  5. Message-ID: <1992Sep11.222258.2144@fcom.cc.utah.edu>
  6. Sender: news@fcom.cc.utah.edu
  7. Organization: Weber State University  (Ogden, UT)
  8. References: <1992Sep8.070731.21159@bernina.ethz.ch> <1992Sep11.200736.20247@qualcomm.com>
  9. Date: Fri, 11 Sep 92 22:22:58 GMT
  10. Lines: 93
  11.  
  12. In article <1992Sep11.200736.20247@qualcomm.com> karn@servo.qualcomm.com (Phil Karn) writes:
  13. >In article <1992Sep8.070731.21159@bernina.ethz.ch> torda@igc.ethz.ch (Andrew Torda) writes:
  14. >>
  15. >>     At 8 MHz, my machine appears perfectly stable.
  16. >>     At 33 MHz, I get repeated trap type 12 panics.
  17. >[...]
  18. >>The most concrete suggestions were to either add wait states or buy
  19. >>faster memory. Couldn't add any more wait states, but I managed to
  20. >>swap 8Mb of 80ns simms for 70 ns simms.
  21. >>
  22. >>Instantly, I could rebuild kernels or run my little crash program
  23. >>which simply allocated ever increasing amounts of memory and scribbled
  24. >>through it.
  25. >>The peculiarity is that with the old memory, I had been able to run
  26. >>dos, windows in enhanced mode and even SCO unix.
  27. >>It would still be nice to know what the cause is and why 386bsd
  28. >>provokes the problem.
  29. >
  30. >Very interesting. I've been having similar problems with my 486-50
  31. >(with 16 meg, Adaptec SCSI controller and NE-2000). A good way to
  32. >crash it is to go into one of the source trees and run make. Often I
  33. >couldn't get through half a dozen nroff's of man pages before a panic,
  34. >usually a message from vm_fault() that I interpret to be the kernel
  35. >dereferencing a bogus pointer. Sometimes it wouldn't even get through
  36. >the reboot before it would panic again. Applying every patch in sight
  37. >didn't seem to help the problem.
  38. >
  39. >So, inspired by your note, I just tried hitting my machine's Turbo
  40. >switch, knocking its clock speed down to 10 Mhz (at least that's what
  41. >the display on the front panel says). And the machine now seems *much*
  42. >more stable. It's gotten through several source directories without
  43. >incident so far, albeit much more slowly.
  44. >
  45. >One possible theory (stress *theory*): many modern PC chipsets provide
  46. >registers to control things like bus clock speeds, memory wait states,
  47. >etc. Much more convenient than the hardware jumpers on old motherboards.
  48. >Since these are usually set by the BIOS setup program and forgotten,
  49. >perhaps something in 386BSD is scribbling over them (or their CMOS
  50. >save areas) unintentionally? Going to faster memory, or slowing the
  51. >machine down, would let the machine run with these unintentionally
  52. >changed settings. This theory would also explain why the same machine
  53. >could run other systems at full speed without problem, because they
  54. >leave the control registers alone.
  55. >Comments?
  56.  
  57. One.  Bus mastering controllers using DMA.
  58.  
  59.     Most of these controllers have clocks you can set to tell it how
  60. long it *MUST* relinquish the bus for and how frequently you have to do
  61. it.  I ran in this problem while writing a Am33C93A SCSI interface driver
  62. for a WD7000-FASST2.  The system would crash occasionally.
  63.  
  64. From the Western Digital documentation [with comments]:
  65.  
  66.     "The maximum on time [where the controller owns the bus] should
  67.      be 15uS less all overhead time required to allow the host to
  68.      service memory refresh cycles, including DMA bus arbitration
  69.      time."
  70.  
  71. My theory is that the aha1542b isn't letting the memory refresh.  When
  72. you start actually using a lot of memory (say during a compile), you get
  73. up into the region where it isn't refreshing (since the refresh proceeds
  74. up to the the point that the bus is grabbed away, the lower the memory,
  75. the "safer" it is).
  76.  
  77. *This* is why the "memory problem" can't be identified with a memory
  78. test program (other than 386bsd, of course ;-)).  SCO has pessimistic
  79. assumptions about the speed of the machine, or actually tests to see
  80. how much time it can grab, and so doesn't have a problem.
  81.  
  82. Test:  Anyone have a non-SCSI system that has the "works OK at 8MHz but
  83. not at 33MHz" problem?  I realize this isn't a definitive test, as I
  84. might get responses from someone running 200ns RAM saying "Yeah; funny...
  85. no one else seems to have the problem", but it should give a weight of
  86. SCSI-with-problem vs. not-SCSI-with-problem.
  87.  
  88. Not to discount the "low core being overwritten" theory, but if you
  89. were getting the problem after warm boot *only*, then I could see it;
  90. otherwise, it's unlikely that low core would be getting blown on one
  91. machine and not another.
  92.  
  93.  
  94.                     Terry Lambert
  95.                     terry_lambert@gateway.novell.com
  96.                     terry@icarus.weber.edu
  97. ---
  98. Any opinions in this posting are my own and not those of my present
  99. or previous employers.
  100. -- 
  101. -------------------------------------------------------------------------------
  102.                                         "I have an 8 user poetic license" - me
  103.  Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
  104. -------------------------------------------------------------------------------
  105.