Cable error. At least thats what the drive saw and the checksum is
computed controller<->drive without our involvement
A cable problem seems doubtful to me, but then again, I don't know
anything about how this code works.
I think it is important to remember that the earlier kernel versions
did NOT give me any errors. Errors occur with more recent kernels
with the exact same cables. (FYI, I read the archives, knew this was
a possible problem, the cables are new, I've swapped them with others
that I have handy with no change in behavior... they are 80 conductor
brand new Cables To Go ATA100 UDMA5 cables.)
> My primary concern is that the IDE driver seems to be making different
> choices in 2.4.9-13 for this chipset, and earlier kernels are making
> better choices -- or possibly failing silently? In any case, I
It may be the new kernel is smart enough to enable UDMA 100 and the cables
are marginal. The CRC error is a corruption that is then retried. Multiple
retries cause the kernel to drop to a lower UDMA speed
Right, except that my hdparm settings manually enable UDMA 100 with
absolutely no problem, and this occurs AFTER the errors.
Using "hdparm -Tt /dev/hdb" "hdparm /dev/hdb" "hdparm -i /dev/hdb" it
appears that the settings have worked, the disks are running in UDMA
100 with no errors except during the boot sequence.
I don't know how to get the system to tell me what initial settings
have been tried, but after the errors and the ide bus reset,
rc.sysinit sets parameters for the disks, and everything is fine from
there.
-- Bob
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/