home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / os / linux / 10267 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  4.6 KB
  1. Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!torvalds
  2. From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: GP faults and other trivia. . .
  5. Message-ID: <1992Sep9.094232.17759@klaava.Helsinki.FI>
  6. Date: 9 Sep 92 09:42:32 GMT
  7. References: <1992Sep8.104048.1@ualr.edu>
  8. Organization: University of Helsinki
  9. Lines: 87
  10.  
  11. In article <1992Sep8.104048.1@ualr.edu> nmspillers@ualr.edu writes:
  12. >
  13. >Anyhoo, the crux of my question is this--I'm working with Linux 0.96c
  14. >(no patches yet, I want to solve this problem first) and trying to compile
  15. >the kernel.  I usually get a general protection fault somewhere in the kernel
  16. >compile, this leads to a 4-11 meg (no lie!) core and the compile degenerates
  17. >into signal 11 and 6 compiler errors. [ deleted ]
  18.  
  19. There has been some talk about these kinds of things lately, so I might
  20. as well answer this..
  21.  
  22. If you see intermittent system failure (core dumping in gcc etc) that
  23. are not easily repeatable, and don't necessarily happen at the same
  24. location every time, there are a couple of possible reasons:
  25.  
  26.  (a) kernel bugs
  27.  (b) weird/buggy hardware
  28.  (c) installation problems
  29.  
  30. (a) is certainly possible, although the fact that the same thing works
  31. on a lot of other machines/setups does make me wonder about some
  32. reports.  (c) on the other hand usually results in easily repeatable
  33. problems: they occur at the same point each time. 
  34.  
  35. The above (mostly deleted) description does sound like a memory problem:
  36. I should probably enable the NMI just to get a warning about it, but I
  37. think current versions of linux disable it at bootup (I think I disable
  38. it as soon as possible as the system cannot handle it during setup, and
  39. after the system is up and running and a NMI could be handled, I never
  40. re-enable them.  I haven't looked into in a long time, so I could be
  41. wrong.)
  42.  
  43. Alternate reasons are disk read errors, although the drivers do check
  44. error conditions, and you should see kernel messages if they occur.  And
  45. if you are wondering "why only gcc?", the reason is probably that gcc is
  46. the one program that usually eats up most of your memory, and actively
  47. shuffles things around.  So if you have a bad memory chip or the linux
  48. disk driver has some problems, they usually show up in gcc - that's when
  49. all the buffers are in use, and most of your memory is being excercised
  50. a lot. 
  51.  
  52. Note that memory problems are more likely to show up under linux-0.97
  53. and newer: not because they are more fragile, but simply because they
  54. use memory much more dynamically, and are more likely to take full
  55. advantage of the memory you have got. 
  56.  
  57. So the first things to check when seeing problems like the above is if
  58. it's hardware-related: one good way to do this is usually to slow down
  59. the machine to 8MHz or whetever, and see if the errors go away.  If they
  60. do, it's probably not a software bug (although races etc can be
  61. timing-dependent: not very frequent).  Other things you can do is try
  62. out some system testing software: but note that linux usually is a
  63. better system tester than most of these especially if they run onder
  64. 16-bit DOS and don't check 32-bit accesses to high memory etc. 
  65.  
  66. ----- change of subject
  67.  
  68. Reading the above, your reaction might be "he's obviously trying to
  69. blame the hardware to get out of a tight spot".  True.  But it's also a
  70. case of standard bug-reporting of a operating system: with most other
  71. programs you can usually safely blame the program.  While any bug report
  72. is preferable to none, there are things you can do to help me find it
  73. all.  So I might as well use this post to mention some of them, true of
  74. most bug-reports:
  75.  
  76.  - mention all the necessary information.  Too much data can be
  77. confusing (and boring), and too little can lead to other problems, so
  78. this isn't easy.  Use your own judgement, but THINK about it a bit
  79. before. 
  80.  
  81.  - try to make it repeatable, and find the minimal example.  This is
  82. also almost always difficult or impossible, as the obvious bugs are
  83. certainly fixed, but it helps /a lot/ if you can simplify the bug-report
  84. a bit. 
  85.  
  86.  - if you cannot make it repeatable or simple, assume it's a hardware
  87. problem, and start from that.  Try different setups.  If possible,
  88. different machines, but if not, try to change your setup as much as
  89. possible, and see if anything changes. 
  90.  
  91.  - If the problem changes or disappears due to hardware changes, it
  92. might still be a software bug, so you might still want to send it in as
  93. such.  But add your test-results to the report.  And if the problem
  94. seems to be hardware-independent, mentioning the fact that you tested it
  95. it in your report is likely to get your report a higher priority. 
  96.  
  97.         Linus
  98.