> > 4. Every interrupt is delivered twice! Setting ei_debug in 8390.c
> > to 4 shows, that after _every_ normal interrupt a second one is
> > delivered with the interrupt status register set to 0 (which
> > means: no interrupt condition present).
> > Digging deeper into this, I noticed that the interrupt counters
> > of both CPUs are incremented, but the interrupt routine is
> > called by the same CPU. That would mean, that a second interrupt
> > is raised, while the first is still running and is later delivered
> > by a self_IPI.
>
> hm. This could be the pin<->idx bug, disable_IO_APIC_irq() has a chance to
> disable the wrong pin, thus resulting in IRQ storms. Does this still
> happen with io-apic-patch-2.1.101-I? It doesnt happen here, exactly as
> many IRQs as should happen.
>
Could this not be the problem that the local APIC is acking a little bit
too early for the level triggered interrupt resulting in another IRQ being
generated by the IOAPIC ('cos the interrupt line is still asserted)?.
The only way it seems like is to ack after handling the irq event.
But with that there are all sorts of other problems. So, is it
possible to try something like this,
in do_level_ioapic_irq before calling disable_IO_APIC_irq make the irq
edge triggered (muck around with the redirection tables again :( ) and
then disable and ack the IRQ. After handling the event set the irq back to
level triggered and then enable_IO_APIC_irq. I dont know whether it will
regenerate the interrupt if the interrupt line is still high at this
point. But atleast after acking the IRQ, the interrupt is not generated
immediately if the IRQ line is still high.
Weird eh!
I tried this method (101 - F patch) on the do_level_ioapic_irq and
enforced level-trigger mode semantics for all the IRQs. It seemed to have
fixed some other problems for me. (ping -f used to lose packets on my 3com
card but now it does not).
Anyway I have no means to verify the other stuff about level-triggered
irqs, but atleast the system wont crash and will boot properly.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu