From: Michael Buesch <mb@bu3sch.de>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Threaded interrupt handlers broken?
Date: Sun, 16 Aug 2009 23:01:21 +0200 [thread overview]
Message-ID: <200908162301.21775.mb@bu3sch.de> (raw)
In-Reply-To: <alpine.LFD.2.00.0908162201220.2782@localhost.localdomain>
On Sunday 16 August 2009 22:05:59 Thomas Gleixner wrote:
> On Sun, 16 Aug 2009, Michael Buesch wrote:
> > On Sunday 16 August 2009 16:25:13 Thomas Gleixner wrote:
> > > On Sun, 16 Aug 2009, Michael Buesch wrote:
> > > > On Sunday 16 August 2009 15:22:29 Thomas Gleixner wrote:
> > > >
> > > > > > + if (0&&unlikely(desc->status & IRQ_DISABLED)) {
> > > > >
> > > > > So the interrupt is marked disabled. How do you setup the handler
> > > > > ? And what does the primary handler do ? Can you post your driver
> > > > > code please?
> > > >
> > > > This patch converts the b43 driver to threaded interrupts:
> > > > http://bu3sch.de/patches/wireless-testing/20090816-1535/patches/002-b43-threaded-irq-handler.patch
> > >
> > > On the first glance this looks not too bad. the unlocked access to the
> > > irq status registers looks a bit scary, but that is not relevant for
> > > the problem at hand.
> >
> > Yeah it does ;)
> >
> > > > It kind of works with this hack applied to kernel/irq/manage.c
> > >
> > > Hmm. Is the interrupt of the device shared ?
> >
> > It's registered as shared, but on my machine it is not shared with anything else.
> >
> > > If yes, what's the other
> > > device on that interrupt line ? what puzzles me is the fact that the
> > > IRQ_DISABLED flag is set. Is there anything unusual in dmesg ?
> >
> > Here's my current kernel log with the two patches applied:
> > http://bu3sch.de/misc/dmesg
>
> Hmm. Nothing interesting AFAICT, but it would be really interesting to
> find out why the IRQ_DISABLED flag is set.
>
> Can you add some debug into disable_irq() e.g. WARN_ON(irq ==
> BC43_IRQ_NR); so we can see what disables that interrupt.
I do not see a warning, if I put this into __disable_irq():
WARN_ON(irq == 52);
/proc/interrupts shows 52 as IRQ number for b43.
And dmesg shows "... irq 52 on host ... mapped to virtual irq 52".
So I guess the test is OK and the flag is added by some other means.
Maybe by some weird powerpc architecture code?
It seems a little bit weird, however, that the WARN_ON does not even trigger
on module unload, which as far as I can tell should disable the IRQ line
in the free_irq() call (no other shared devices on this IRQ).
--
Greetings, Michael.
next prev parent reply other threads:[~2009-08-16 21:01 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-16 9:53 Threaded interrupt handlers broken? Michael Buesch
2009-08-16 10:14 ` Michael Buesch
2009-08-16 12:45 ` Michael Buesch
2009-08-16 13:22 ` Thomas Gleixner
2009-08-16 13:46 ` Michael Buesch
2009-08-16 14:25 ` Thomas Gleixner
2009-08-16 17:51 ` Michael Buesch
2009-08-16 20:05 ` Thomas Gleixner
2009-08-16 21:01 ` Michael Buesch [this message]
2009-08-16 21:28 ` Thomas Gleixner
2009-08-17 10:23 ` Michael Buesch
2009-08-17 10:56 ` Thomas Gleixner
2009-08-17 11:03 ` Thomas Gleixner
2009-08-17 11:12 ` Thomas Gleixner
2009-08-17 11:37 ` Michael Buesch
2009-08-17 12:14 ` Thomas Gleixner
2009-08-17 12:30 ` Michael Buesch
2009-09-04 18:55 ` Michael Buesch
2009-09-04 19:05 ` Michael Buesch
2009-09-04 19:35 ` Michael Buesch
2009-09-04 19:37 ` Sebastian Andrzej Siewior
2009-08-16 13:19 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200908162301.21775.mb@bu3sch.de \
--to=mb@bu3sch.de \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.