Re: IDE DMA problems on 2.4.0 with vt82c686a driver

[Vojtech Pavlik]

On Thu, Jan 11, 2001 at 09:41:55AM -0500, Mark Hahn wrote:
> > Since this looks like either a chipset, drive, or driver problem, I am 
> 
> no: the only entities involved with udma crc's are the drive,
> the controller (and the cable).  the kernel is not involved in any way
> (except to configure udma, of course.)

Well, that's the part where it is really easy to cause crc errors. But I
believe I got that right in the driver. Tested successfully on many VIA
chipsets.

> > occasionally (not often/constant, but sometimes) get CRC errors:
> > hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> > hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
> 
> nothing wrong here.  occasional crc retries cause no performance impact.

Also it should be noted that they don't cause any corruption (*). The worst
thing they can do is disabling DMA if they happen many times in a short
period of time. 

(*) - UDMA modes only. CRC errors are a big problem in PIO and
      MWDMA/SWDMA modes.

> > After reading some archives in linux-kernel, I tried changing some 
> > options. Then I changed out the 40 pin, 80 wire cable with a new one. 
> 
> great, since without the 80c cable, udma > 33 is illegal.

... note that he says 40pin, 80wire. That's the correct UDMA66 cable, it
has just 40 pins.

> is it safe to assume your cable is also 18" or less, with both ends
> plugged in (no stub)?  you might be able to minimize CRC retries
> by changing where the cable runs.  it's also conceivable that CRC
> errors would be caused by marginal power, bad trace layout on the 
> motherboard,

Bad trace on the motherboard is what I suspect on KT7's. It could be
designed a little longer or shorter than the others and a marginal clock
skew can cause the crc errors. Or the trace can lead too close to some
source of e/m noise.

> and definitely by overclocking (PCI other than 33 MHz).
> 
> > My main concern that I havnt beem able to find an answer for on any 
> > archives or documentation, Can this cause file system corruption in any way?
> 
> abosolutely not.  udma checksums each transfer.  when checksums don't match,
> the *hardware* retries the transfer (and incidentally reports the event,
> which Linux obligingly passes on to you.)

The software retries the transfer, the hardware just aborts. But it's
safe, anyways.

-- 
Vojtech Pavlik
SuSE Labs