[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.61.0612141900390.12730@yvahk01.tjqt.qr>
Date: Thu, 14 Dec 2006 19:04:30 +0100 (MET)
From: Jan Engelhardt <jengelh@...ux01.gwdg.de>
To: Linus Torvalds <torvalds@...l.org>
cc: Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Greg KH <gregkh@...e.de>, Andrew Morton <akpm@...l.org>,
linux-kernel@...r.kernel.org
Subject: Re: [GIT PATCH] more Driver core patches for 2.6.19
On Dec 14 2006 09:32, Linus Torvalds wrote:
>On Thu, 14 Dec 2006, Jan Engelhardt wrote:
>>
>> Rather than IRQ_HANDLED, it should have been: remove this irq
>> handler from the irq handlers for irq number N, so that it does
>> not get called again until userspace has acked it.
>
>That just means that the _handler_ won't be called. But the irq
>still stays active, and if it's shared, ALL THE OTHER HANDLERS FOR
>THAT INTERRUPT will be called.
>[...]
>And the reason was that it would send an irq, but we were expecting
>it on another interrupt. But if it showed up on something that was
>shared, you'd have a hung machine, because you'd just have the (say)
>ethernet driver saying "not for me", and returning. And obviously
>not able to actually shut it up, so when we returned from the
>interrupt handler, the interrupt happened immediately again.
Thanks for this explanation, I see the point. Removing the uio irq
handler will leave the irq chain only with "not for me" devices. In
that case, would it make sense to install a replacement uio handler
that says "yes, that's mine" [but ignoring it since userspace has not
yet finished with it]? (I think I've gotten into a loop since that
would be the IRQ_HANDLED case.) Mh, delicate problem.
-`J'
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists