home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8154 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  3.1 KB
  1. Path: sparky!uunet!olivea!sgigate!odin!mips!sdd.hp.com!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!yale!mintaka.lcs.mit.edu!ai-lab!life.ai.mit.edu!burley
  2. From: burley@geech.gnu.ai.mit.edu (Craig Burley)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: Buffer corruption problems.
  5. Message-ID: <BURLEY.92Aug13153840@geech.gnu.ai.mit.edu>
  6. Date: 13 Aug 92 19:38:40 GMT
  7. References: <16078@ucdavis.ucdavis.edu> <1992Aug13.163854.21617@midway.uchicago.edu>
  8. Sender: news@ai.mit.edu
  9. Followup-To: comp.os.linux
  10. Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139
  11. Lines: 50
  12. In-reply-to: ace3@quads.uchicago.edu's message of 13 Aug 92 16:38:54 GMT
  13.  
  14. In article <1992Aug13.163854.21617@midway.uchicago.edu> ace3@quads.uchicago.edu (Tony 'LLama' Acero) writes:
  15.  
  16.    I have no idea what's going on and would appreciate any input! :-)
  17.    (The smiley is to indicate I'm not complaining and half-expecting
  18.    that I've done something bone-headed)
  19.  
  20. I'm not sure about your problem or the person's to whose post you followed up,
  21. but...
  22.  
  23. ...I believe there is a bug in Linux that has the following behavior:
  24.  
  25. -  causes Linux to "misread" one 1024KB chunk of data from a disk-based file
  26.    so that what your app ends up with is some _other_ 1024KB chunk
  27.    (apparently from the same file)
  28.  
  29. -  occurs only during very heavy disk access, such as megabytes accessed
  30.    continually
  31.  
  32. -  is intermittent, but happens enough to reproduce fairly easily
  33.  
  34. -  might be SCSI-related (I have a SCSI system) but, based on responses I've
  35.    gotten from others saying they've seen the same behavior, probably isn't
  36.  
  37. -  is still in 0.97 and perhaps happens somewhat more often there (though of
  38.    course it's hard to measure this)
  39.  
  40. I keep putting off exploring this bug myself for various reasons, such as:
  41. I'm not a Linux-kernel hacker yet; I keep hoping someone else will fix it
  42. first; it's hard to debug when your own dev system _has_ the intermittent
  43. failure; I'm too busy with GNU Fortran; I'm waiting for the newer SCSI
  44. code with 4K blocks to see how that affects the bug (since that might be an
  45. important clue); I'm waiting until I have extfs &c up an running reliably
  46. so I can make use of my currently wasted disk space before tackling this
  47. bug; I'm just plain lazy; I'd rather play tennis with my wife; etc.
  48.  
  49. I'm convinced that when I finally decide to tackle the bug (rather than just
  50. write a shell script and program to create a test-case to demonstrate it,
  51. as I've done so far), I'll blow 72 hours on it and _then_ find it someone
  52. else found and fixed it!  (Unfortunately, nobody responded to my posted
  53. test case saying they'd reproduced the problem, much less had the know-how
  54. and desire to look into it themselves.  If anyone wants, I could repost it
  55. to the mailing list as I did last time.  Email me, don't post here, to
  56. keep traffic low, if you want me to post the test case.)
  57.  
  58. Of course it could be a hardware bug in my system, but seeing as others
  59. _seem_ to have the same problem on wildly different hardware, I doubt it.
  60. --
  61.  
  62. James Craig Burley, Software Craftsperson    burley@gnu.ai.mit.edu
  63. Member of the League for Programming Freedom (LPF)
  64.