Messages in this thread | | | Date | Sat, 11 Sep 1999 00:21:11 -0700 (PDT) | From | Andre Hedrick <> | Subject | Re: 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 majordomo@vger.rutgers.edu > Please read the FAQ at http://www.tux.org/lkml/ >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |