Messages in this thread | | | Date | Fri, 19 Dec 1997 19:18:50 +0100 (CET) | From | MOLNAR Ingo <> | Subject | Re: 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
| |