public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox