home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / os / linux / 10285 < prev    next >
Encoding:
Internet Message Format  |  1992-09-09  |  3.0 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!wupost!darwin.sura.net!ra!tantalus!eric
  2. From: eric@tantalus.dell.com (Eric Youngdale)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: GP faults and other trivia. . .
  5. Message-ID: <3544@ra.nrl.navy.mil>
  6. Date: 9 Sep 92 15:08:42 GMT
  7. References: <1992Sep8.104048.1@ualr.edu> <1992Sep9.094232.17759@klaava.Helsinki.FI>
  8. Sender: usenet@ra.nrl.navy.mil
  9. Organization: Naval Research Laboratory
  10. Lines: 54
  11.  
  12. In article <1992Sep9.094232.17759@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
  13. >If you see intermittent system failure (core dumping in gcc etc) that
  14. >are not easily repeatable, and don't necessarily happen at the same
  15. >location every time, there are a couple of possible reasons:
  16. >
  17. > (a) kernel bugs
  18. > (b) weird/buggy hardware
  19. > (c) installation problems
  20. >
  21.  
  22.     There is one other possibility, (which is probably a subset of (a)),
  23. and that is a compiler bug which leads to incorrect code being generated.
  24. This could lead to a buggy kernel, but you could stare at the source code all
  25. day long and never have a clue as to what is going wrong.  We do need to keep
  26. in mind that gcc 2.2.2 is still considered a beta release, and RMS does
  27. consider 1.40 (and 1.41) to be a more stable compiler.  In fact, if there are
  28. weird unexplainable problems with the kernel, we might want to consider
  29. compiling the kernel with 1.40 (or 1.41), and seeing if the problems go away
  30. (although I do not know if it is still possible to compile the kernel with
  31. 1.40).  RMS has been making noises about a gcc 2.3 release sometime in early
  32. October. 
  33.  
  34.     I should point out that I have not yet seen any evidence of a compiler
  35. bug being responsible for any problems with the kernel.
  36.  
  37. >So the first things to check when seeing problems like the above is if
  38. >it's hardware-related: one good way to do this is usually to slow down
  39. >the machine to 8MHz or whetever, and see if the errors go away.  If they
  40. >do, it's probably not a software bug (although races etc can be
  41. >timing-dependent: not very frequent).  Other things you can do is try
  42. >out some system testing software: but note that linux usually is a
  43. >better system tester than most of these especially if they run onder
  44. >16-bit DOS and don't check 32-bit accesses to high memory etc. 
  45.  
  46.     I would not berate the system testing software out there as much as
  47. Linus does.  It is probably true that 32 bit memory access is probably not
  48. tested, but if you have a bad SIMM (or a bad contact in the SIMM socket), it is
  49. a fairly painless way to find out about it.
  50.  
  51.     In general I have found Linux to be quite stable, and whenever
  52. I do see strange intermittent behavior, it is one of two things:
  53.  
  54.     a) the CMOS settings are corrupted.
  55.     b) One of the SIMMs is not making good contact.
  56.  
  57. I have found (a) to happen much more often that I would like, but whenever
  58. I get weird behavior, I will simply reload the CMOS from the defaults in the
  59. BIOS, and this usually gets things going.  I have only seen (b) once.
  60.  
  61. -Eric
  62.  
  63. --
  64. Eric Youngdale
  65. eric@tantalus.nrl.navy.mil
  66.