lkml.org 
[lkml]   [1999]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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 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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.067 / U:0.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site