On Fri, 07 Jul 2000, Thierry Vignaud wrote:
> 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).
Huh. According to hdparm, it's not using dma at all.
/dev/hdb:
multcount = 16 (on)
I/O support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 0 (off)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 977/255/63, sectors = 15698592, start = 0
> 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 ...)
Alas, I don't have udma66, my motherboard is older than that...
As far as I'm concerned, if one piece of software can read a piece of
hardware perfectly, whereas another piece of software has difficulty with
it, that's an obvious software problem. There may be hardware issues
involved, but what it boils down to is the second piece of software isn't
robust enough to support as much hardware as the first one does. The
second piece of software is doing something with the hardware in question
that it shouldn't. If there's no way to disable that feature (i.e. some
hdparm setting to make it work), the software's busted and needs to be
fixed.
