[lkml]   [1999]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Lockups - lost interrupt

    Alan I know something about the lost interrupts is directly related to
    drive timings. There is a spinlock somewhere to be caught, but I can not
    find the beasty. Lob me that "ikd patch", please.

    I can forcable wreck the timing values and invoke the error.
    Also some of the quick drives must be forcable back speeded on slower
    chipsets. Also there are a few chipsets that really get nasty because of
    the extremely tight tolerances (well -- zero margin -- almost).

    Lastly there are several drives that claim ATA-66, but timeout and there
    is nothing to date to catch and convert/update the transfer rates.

    With the huge cache buffers and dual processor drives, yes there is a
    vender out there throttling the drives with two onboard processors, the
    fun is only beginning.

    To get an idea on the variables....

    Leading or lagging interuppts from the chipset.
    Variably based on the limit size imposed on the chipset FIFO.
    Command queing of the drives are on this side of the horizen and moving
    fast, ie SCSI work horse power is coming to IDE.

    There is more, but it is late and I am now only one kernel behind the
    curve to catch up on patching.

    OT, do you want the very latest back code for 2.2.13 that I have to finish
    creating for 2.3.18/9?

    Andre Hedrick
    The Linux IDE guy

    On Fri, 10 Sep 1999, Alan Cox wrote:

    > > > Does anybody have any idea what could be causing this? Is this a bad
    > > > motherboard? CPU?
    > > Since I have 3 systems doing it, others have also reported similar,
    > > I think it could be kernel related....
    > I'm still digging into this. I do have some ideas what may be involved. There
    > are about three different cases here
    > 1. VIA chipset bug - known, understood, non SMP
    > 2. A few triton boards - probably a hardware issue
    > 3. SMP - looks like a lock bug.
    > Running the ikd patch is the best help here. I think it will show you a
    > spinlock deadlock. The trace from that should find the guilty party
    > -
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to
    > Please read the FAQ at

    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:53    [W:0.024 / U:58.792 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site