[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.02.1203062019340.2742@ionos>
Date: Tue, 6 Mar 2012 20:31:46 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Linus Torvalds <torvalds@...ux-foundation.org>
cc: Stefan Lippers-Hollmann <s.L-H@....de>,
Sven Joachim <svenjoac@....de>,
Greg KH <gregkh@...uxfoundation.org>,
LKML <linux-kernel@...r.kernel.org>, stable@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Jonathan Nieder <jrnieder@...il.com>,
linux-wireless@...r.kernel.org,
Stefano Brivio <stefano.brivio@...imi.it>
Subject: Re: [ 57/72] genirq: Unmask oneshot irqs when thread was not woken
On Tue, 6 Mar 2012, Thomas Gleixner wrote:
> On Tue, 6 Mar 2012, Thomas Gleixner wrote:
>
> > On Mon, 5 Mar 2012, Linus Torvalds wrote:
> >
> > > Thomas, should we just plan on reverting that commit from mainline? It
> > > clearly causes regressions.
> >
> > Give me a day or two to figure out why it breaks stuff. I have no idea
> > why it should wreckage anything.
>
> Hmm. This is interesting. The b43 driver has a primary handler which
> can return IRQ_NONE. So up to that change the interrupt line was kept
> disabled when that happened. Possibly the driver relies on that
> behaviour. Digging for a machine with a b43.
Does not reproduce. Now I was looking at the driver again, it does not
use IRQ_ONESHOT anyway.
So for handle_fasteoi_irq() this patch is actually a NOOP. So the only
affected handler would be handle_level_irq(). Still can't see how it
changes the !IRQ_ONESHOT behaviour :(
Stephan, Sven: Can you please provide the output of /proc/interrupts ?
Thanks,
tglx
--
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