home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8181 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  2.2 KB
  1. Path: sparky!uunet!cs.utexas.edu!sdd.hp.com!caen!malgudi.oar.net!ucbeh.san.uc.edu!ucunix.san.uc.edu!zuazaga
  2. Newsgroups: comp.os.linux
  3. Subject: Re: Buffer corruption problems.
  4. Message-ID: <1992Aug14.013130.26395@ucunix.san.uc.edu>
  5. From: zuazaga@ucunix.san.uc.edu (Humberto Ortiz-Zuazaga)
  6. Date: Fri, 14 Aug 92 01:31:30 GMT
  7. References: <1992Aug13.163854.21617@midway.uchicago.edu> 
  8.  <BURLEY.92Aug13153840@geech.gnu.ai.mit.edu> <CORYWEST.92Aug13180939@rio-grande.rice.edu>
  9. Organization: University of Cincinnati
  10. Keywords: HD: read_intr:, errors
  11. Summary: HD-controller reset in BIG compiles
  12. Lines: 36
  13.  
  14. In article <CORYWEST.92Aug13180939@rio-grande.rice.edu> corywest@rice.edu (Cory West) writes:
  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. >    - Under heavy and prolonged disk I/O (in this example, while compiling
  31. >gdb from scratch) there seem to be problems with the buffer cache.  After 
  32. >compiling for a while, gcc will choke with a TON of strange errors
  33. and die.
  34.  
  35. I get a series of "HD: read_intr: status = 0x59", "HD: read_intr:
  36. error = 0x10" followed by an "HD-controller reset" on an odball
  37. Western Digital + Seagate IDE when doing big compiles ever since 0.96.
  38. The compilations proceed without error, however.
  39.  
  40. >    - The errors always include the same file (which is why I thought
  41. >perhaps that that particular file was living on a disk block that was going
  42. >belly up.  I plan to rename that file to .deadblock and putting a new copy
  43.  
  44. It may be the same file, if compiling the file excercises the bug (not
  45. reading it, compiling it). Check to see how much memory is used during
  46. the compile, or turn off optimization?
  47. -- 
  48. Humberto Ortiz-Zuazaga                            zuazaga@ucunix.san.uc.edu
  49. Dept. of Physiology & Biophysics                   University of Cincinnati
  50.