>
>
>On Wed, 29 Apr 1998, MOLNAR Ingo wrote:
>>
>> it still had a bug which caused IRQ handler reenter under certain
>> conditions: the disabled_irq[] flag has two functions, first, it registers
>> disabled interrupts, but second, it keeps interrupts disabled if a handler
>> is executing. If disable_irq() is done heavily (like in 8390.c), then it
>> might happen that we'll have the IRQ enabled right after the
>> synchronize_irq() in disable_irq().
>
>Good spotting. However, this is actually not a IO-APIC specific bug: it
>turns out that this could happen with the old APIC too. Your patch fixes
>it only for the IO-APIC case.
>
>The bug also makes it clear that the in-progess disable really is
>different from the "explicit" disable. I've got a patch that clearly
>separates the two (both for the IO-APIC and the old APIC). For the usual
>reasons I haven't tested this yet, but I'll append a patch (relative to
>clean 2.1.98) that people can play around with.
>
>Whether we want to nest the explicit disable/enable or not is a secondary
>issue. The nesting makes sense for irq sharing, but I have to admit that
>I'm still a bit nervous about changing the logic, but at least this patch
>is a start towards making the nesting happen the same way on the IO-APIC
>as on the old APIC if we decide we do want to nest. I refuse to nest on
>one but not the other - that just makes no sense at all.
>
>[ This patch does not yet nest - the disable count is still just a single
> bit. But this patch allows for two things: checking "wait_for_irq()" on
> a per-irq basis by looking at IRQ_INPROGRESS and thus allowing us a more
> fine-grained wait and allowing us to do irq autodetection by looking at
> the same bit without actually having to do the ugly irq counting stuff.
> The patch actually does neither of these two things, but I'll get around
> to doing them soon unless somebody else beats me to it ]
>
>Comments?
>
> Linus
Neither of these two patches solved my NE2000 (a RealTek 8029 BTW) hanging on my
SMP box with smbclient. Ingo's generally lasted longer before hanging.
Steve.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu