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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
