lkml.org 
[lkml]   [1997]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 8390.c + 2.1 SMP, IO-APIC irq handling anomaly, 2.1.73 patch

On Fri, 19 Dec 1997, Alan Cox wrote:

> > the first solution was to add a 10 usecs delay to
> > synchronize_irq(), then i tried to find a wait-less
>
> Not a fix if its the posting delay from an IRQ. There's a related 2.0.x
> funny btw when irq's get forwarded across cpu's and they are shared some
> boards in some situations go astray.

note that the 'worst case' is when the APIC has just posted _this_ irq. It
means the CPU has started it's INTA cycle, nothing will delay that. If
there is some other message traffic holding the APIC up, then we wont have
this problem in the first case. There is a 2 usecs safety gap to catch
'noise' effects. I've tried hard to get those messages (stuff like flood
pinging and heavy disk usage pops up such timing bugs pretty fast), but no
message. The IO APIC itself is serial, if it has committed to do
something. This is all pure speculation though.

> Maybe someone with a bit of time should bite the bullet and use the apic as
> God intended for its distribution and priority lockouts

i've done the harder part of that already (look back linux-smp archives,
i've posted the patch that activates the better parts of the IO-APIC), but
we had bigger IRQ handling problems at that time ... now things look quite
stable, i will try to get the dynamic IRQ routing stuff running again. Not
that this changes the fundamental problem: drivers written for UP muck
with the card's irq line directly ...

-- mingo


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