Mark Lord wrote:
Malcolm Gillies wrote:
By swapping around components, I've established that the problem is
unlikely due to the cable (which is 50cm long 80-wire), hard disk or
controller. When I swap to another, slower CF card (one that only
supports PIO rather than MWDMA), the error goes away and the hard disk
operates happily at UDMA/33.
..
ata1.00: CFA: SanDisk SDCFH-1024, HDX 4.07, max MWDMA2
ata1.00: 2001888 sectors, multi 0: LBA
ata1.01: ATA-7: SAMSUNG HD400LD, WQ100-14, max UDMA/100
ata1.01: 781422768 sectors, multi 0: LBA48
ata1.01: limited to UDMA/33 due to 40-wire cable
ata1.00: configured for MWDMA2
ata1.01: configured for UDMA/33
..
The fastest DMA speed reported for the CF is MWDMA2, which is considerably
slower than UDMA/33. When two devices share a cable, normally both must be
limited to the speed of the slower device, which is MWDMA2 in this case.
Both devices report being capable of 120ns cycle times for DMA,
but UDMA double-clocks those cycles, something that is incompatible
with non-UDMA devices.
I don't think we can safely assume that UDMA can co-operate with non-UDMA
on the same cable. In this case, it might be causing the CF device to
falsely detect control cycles.
The mystery for me is that
1) there are no errors reported for the CF device, only for the UDMA HD
2) the HD runs error-free at UDMA/33 when I use a different, PIO-only CF
card but otherwise the same cabling, adaptor etc.
In response to Alan's suggestion, the second point suggests it's not a
cabling problem.
Any suggestions on how to debug this further appreciated.
cheers,
Malcolm
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
