[lkml]   [2001]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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

    > > 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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:28    [W:0.025 / U:4.220 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site