lkml.org 
[lkml]   [2001]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: IDE DMA problems on 2.4.0 with vt82c686a driver
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:28    [from the cache]
©2003-2011 Jasper Spaans