"Guy T. Rice" <[EMAIL PROTECTED]> writes:
> I installed Mandrake 7.1 on several computers at work and everything
> worked flawlessly. However, I installed it on my home computer, and
> discovered a bug. My primary HD remains readable, but my second HD
> (slave drive on the same IDE bus) becomes unreadable. Actually, it
> appears to read, but sometimes a single bit will be set that shouldn't
> be. It's about a one in a million chance, but one bit in a million
> means attempting to gunzip any file over 125K usually results in an
> error, only extremely small RPMs can be installed, etc.
>
> I have an identical copy of a particular large file on my primary and
> secondary HD. If I compare the two (with "cmp"), it reports a difference
> at a particular byte, and continues to report it at that byte. But if I
> reboot, it reports the first difference at a different byte. (Perhaps
> caching accounts for this -- rebooting clears the cache and read errors
> are more or less random.)
>
> This probably did not occur in 7.0. It also disappears if I switch to
> kernel-linus. It reappears if I switch back to the standard kernel
> (either the one off the final 7.1 CD or the new one in updates). From
> this I surmise the problem is caused by one of the kernel patches that
> was added between 7.0 and 7.1.
>
> Here's a bit of hardware info, let me know if you want anything else:
>
> Excerpt from dmesg (booting under kernel-2.2.16-9mdk):
(...)
> hdb: QUANTUM Bigfoot TX8.0AT, 7665MB w/69kB Cache, CHS=977/255/63
> (hdb is the one that reads incorrectly.)
Quantum Bigfoot are said to be not as reliable as other hd (there was some
series that all crashed after some times (the rw head just stick on the hd :-( )).
I don't think it's an eide driver bug : it's just that the new driver stress
more hardware (if your eide hd and controller reports to support udma, you
just want to use it). the problem won't appear with kernel-linus because it's
nicer with hardware (try hdparm -Tt on /dev/hda to compare).
For me, it's a hardware bug (hd or cable; eg, for udma66, lots of read error
were due to bad cables ...)
see you.
