home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8166 < prev    next >
Encoding:
Text File  |  1992-08-13  |  2.7 KB  |  65 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!cs.utexas.edu!rice!corywest
  3. From: corywest@rice.edu (Cory West)
  4. Subject: Re: Buffer corruption problems.
  5. In-Reply-To: burley@geech.gnu.ai.mit.edu's message of 13 Aug 92 19:38:40 GMT
  6. Message-ID: <CORYWEST.92Aug13180939@rio-grande.rice.edu>
  7. Followup-To: comp.os.linux
  8. Sender: news@rice.edu (News)
  9. Organization: Well, none really, but I know where my socks are!
  10. References: <16078@ucdavis.ucdavis.edu> <1992Aug13.163854.21617@midway.uchicago.edu>
  11.     <BURLEY.92Aug13153840@geech.gnu.ai.mit.edu>
  12. Date: Fri, 14 Aug 1992 00:09:39 GMT
  13. Lines: 50
  14.  
  15. In article <BURLEY.92Aug13153840@geech.gnu.ai.mit.edu> 
  16. burley@geech.gnu.ai.mit.edu (Craig Burley) writes:
  17.  
  18. >  ...I believe there is a bug in Linux that has the following behavior:
  19. >
  20. >  -  causes Linux to "misread" one 1024KB chunk of data from a disk-based file
  21. >     so that what your app ends up with is some _other_ 1024KB chunk
  22. >     (apparently from the same file)
  23. >
  24. >  -  occurs only during very heavy disk access, such as megabytes accessed
  25. >     continually
  26. >
  27. >  -  is intermittent, but happens enough to reproduce fairly easily
  28. [Etc...]
  29.  
  30.     I have noticed some abnormalities, but I have been writing them
  31. off to a disk block in the process of going bad.  Here's what I have
  32. noticed:
  33.  
  34.     - Under heavy and prolonged disk I/O (in this example, while compiling
  35. gdb from scratch) there seem to be problems with the buffer cache.  After 
  36. compiling for a while, gcc will choke with a TON of strange errors and die.
  37. However, if I just restart make, the compiler will continue successfully
  38. with the file that it had just died on, but it will die a little later 
  39. down the line (after some more intensive I/O) under the same circumstances.
  40. After a couple of tries, I can usually get through the entire make.
  41.  
  42.     - I am running on MFM drives on a 486-33 with 4 Megs RAM (gcc 2.2.2d and
  43. gcc 2.2.2 and Linux 0.97 PL1), so while compiling large things, my disks never 
  44. stop to breath, especially if I am trying to do something else while the compile 
  45. is running.
  46.  
  47.     - The errors always include the same file (which is why I thought
  48. perhaps that that particular file was living on a disk block that was going
  49. belly up.  I plan to rename that file to .deadblock and putting a new copy
  50. of the file in the directory to test this theory).  I am also going to run some
  51. more large compiles to see if I can reproduce this error elsewhere in the 
  52. system.
  53.  
  54.     I don't know what it is yet, and I'm not sure if it's anything, but
  55. I'll see what I can reproduce and hopefully we can determine if this is an
  56. OS bug or a hardware bug and whether or not it has anything to do at all with
  57. the above problem.
  58.  
  59.     Anyone else out there having problems?
  60.  
  61.  
  62.  
  63.                     Cory West
  64.                     corywest@rice.edu
  65.