Subject: Re: Buffer corruption problems. From: zuazaga@ucunix.san.uc.edu (Humberto Ortiz-Zuazaga) Date: Fri, 14 Aug 1992 01:31:30 GMT
In article <CORYWEST.92Aug13180939@rio-grande.rice.edu> corywest@rice.edu (Cory West) writes:
>In article <BURLEY.92Aug13153840@geech.gnu.ai.mit.edu>
>burley@geech.gnu.ai.mit.edu (Craig Burley) writes:
>
>> ...I believe there is a bug in Linux that has the following behavior:
>>
>> - causes Linux to "misread" one 1024KB chunk of data from a disk-based file
>> so that what your app ends up with is some _other_ 1024KB chunk
>> (apparently from the same file)
>>
>> - occurs only during very heavy disk access, such as megabytes accessed
>> continually
>>
>> - is intermittent, but happens enough to reproduce fairly easily
>[Etc...]
>
> - Under heavy and prolonged disk I/O (in this example, while compiling
>gdb from scratch) there seem to be problems with the buffer cache. After
>compiling for a while, gcc will choke with a TON of strange errors
and die.
I get a series of "HD: read_intr: status = 0x59", "HD: read_intr:
error = 0x10" followed by an "HD-controller reset" on an odball
Western Digital + Seagate IDE when doing big compiles ever since 0.96.
The compilations proceed without error, however.
> - The errors always include the same file (which is why I thought
>perhaps that that particular file was living on a disk block that was going
>belly up. I plan to rename that file to .deadblock and putting a new copy
It may be the same file, if compiling the file excercises the bug (not
reading it, compiling it). Check to see how much memory is used during
the compile, or turn off optimization?
-- Humberto Ortiz-Zuazaga zuazaga@ucunix.san.uc.edu Dept. of Physiology & Biophysics University of Cincinnati