home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8218 < prev    next >
Encoding:
Text File  |  1992-08-14  |  3.6 KB  |  82 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!cs.utexas.edu!natinst.com!scott
  3. From: scott@natinst.com (Scott A. Taylor)
  4. Subject: Re: Buffer corruption problems.
  5. Message-ID: <1992Aug14.133132.15512@natinst.com>
  6. Followup-To: comp.os.linux
  7. Summary: No buffer probs here.
  8. Keywords: buffer problem, SCSI, stability, solid, rock
  9. Sender:  Scott Taylor (scott@natinst.com)
  10. Nntp-Posting-Host: eagle.natinst.com
  11. Organization: National Instruments, Austin, TX
  12. References: <1992Aug13.163854.21617@midway.uchicago.edu> <BURLEY.92Aug13153840@geech.gnu.ai.mit.edu> <CORYWEST.92Aug13180939@rio-grande.rice.edu>
  13. Date: Fri, 14 Aug 1992 13:31:32 GMT
  14. Lines: 66
  15.  
  16. In article <CORYWEST.92Aug13180939@rio-grande.rice.edu> corywest@rice.edu (Cory West) writes:
  17. >In article <BURLEY.92Aug13153840@geech.gnu.ai.mit.edu> 
  18. >burley@geech.gnu.ai.mit.edu (Craig Burley) writes:
  19. >
  20. >>  ...I believe there is a bug in Linux that has the following behavior:
  21. >>
  22. >>  -  causes Linux to "misread" one 1024KB chunk of data from a disk-based file
  23. >>     so that what your app ends up with is some _other_ 1024KB chunk
  24. >>     (apparently from the same file)
  25. >>
  26. >>  -  occurs only during very heavy disk access, such as megabytes accessed
  27. >>     continually
  28. >>
  29. >>  -  is intermittent, but happens enough to reproduce fairly easily
  30. >[Etc...]
  31. >
  32. >    I have noticed some abnormalities, but I have been writing them
  33. >off to a disk block in the process of going bad.  Here's what I have
  34. >noticed:
  35. >
  36. >    - Under heavy and prolonged disk I/O (in this example, while compiling
  37. >gdb from scratch) there seem to be problems with the buffer cache.  After 
  38. >compiling for a while, gcc will choke with a TON of strange errors and die.
  39. >However, if I just restart make, the compiler will continue successfully
  40. >with the file that it had just died on, but it will die a little later 
  41. >down the line (after some more intensive I/O) under the same circumstances.
  42. >After a couple of tries, I can usually get through the entire make.
  43. >
  44. >    - I am running on MFM drives on a 486-33 with 4 Megs RAM (gcc 2.2.2d and
  45. >gcc 2.2.2 and Linux 0.97 PL1), so while compiling large things, my disks never 
  46. >stop to breath, especially if I am trying to do something else while the compile 
  47. >is running.
  48. >
  49. >    - The errors always include the same file (which is why I thought
  50. >perhaps that that particular file was living on a disk block that was going
  51. >belly up.  I plan to rename that file to .deadblock and putting a new copy
  52. >of the file in the directory to test this theory).  I am also going to run some
  53. >more large compiles to see if I can reproduce this error elsewhere in the 
  54. >system.
  55. >
  56. >    I don't know what it is yet, and I'm not sure if it's anything, but
  57. >I'll see what I can reproduce and hopefully we can determine if this is an
  58. >OS bug or a hardware bug and whether or not it has anything to do at all with
  59. >the above problem.
  60. >
  61. >    Anyone else out there having problems?
  62. >
  63. >
  64. >
  65. >                    Cory West
  66. >                    corywest@rice.edu
  67.  
  68. I am running 0.96c pl2 with the latest SCSI drivers from woz.headrest.colorado.
  69. edu, and I have not had any problems like this, even under heavy load (i.e.
  70. building a new kernel in one VC while compiling groff, GNU file utils, text
  71. utils, etc. in another).  I have 8 megs of RAM and an UltraStor 14F w/ 213 MB 
  72. Maxtor disk in a 386-25 with no cache. I do not have swapping enabled.  Maybe 
  73. this problem is paging- or cache-related?
  74.  
  75. I have used (and abused ;-) ) linux pretty heavily in the past, and it has
  76. been solid as a rock (Thanks Linus and everyone else involved!).
  77. -- 
  78. Scott Taylor            |
  79. (512) 795-6837          | "Well, I wanted to work with gymnasts." -David Byrne
  80. scott@natinst.com       |
  81. ** NI pays me to write their code, not their opinions, and that's what I do **
  82.