Re: irq 16: nobody cared

[Thomas Gleixner]

On Mon, 22 Apr 2013, Takashi Iwai wrote:
> At Mon, 22 Apr 2013 11:13:10 +0200,
> Borislav Petkov wrote:
> > 
> > On Mon, Apr 22, 2013 at 10:32:17AM +0200, Takashi Iwai wrote:
> > > Hm, if it's really due to a stray irq, just adding the missing
> > > synchronize_irq() like below would help?
> > > 
> > > 
> > > Takashi
> > > 
> > > ---
> > > diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> > > index 7b213d5..262dbf1 100644
> > > --- a/sound/pci/hda/hda_intel.c
> > > +++ b/sound/pci/hda/hda_intel.c
> > > @@ -2682,6 +2682,8 @@ static void azx_stop_chip(struct azx *chip)
> > >  	/* disable interrupts */
> > >  	azx_int_disable(chip);
> > >  	azx_int_clear(chip);
> > > +	if (chip->irq >= 0)
> > > +		synchronize_irq(chip->irq);
> > 
> > Nope, it doesn't help - I see the same splat.
> 
> Thanks.  Then I have no idea what's missing in the current
> azx_suspend() and azx_resume() codes.

I asked Boris to add a disable_irq() on top of the azx_suspend()
function and that does not help either, but it tells us that the
interrupt storm arrives _BEFORE_ azx_suspend() is invoked.

So some other device shuts down and causes that. The obvious question
is whether this interrupt line is shared with something else.

Boris, can you please provide the irq16 line of /proc/interrupts
before you invoke suspend? 

If it's shared we know which driver is shutdown before hda_intel and
perhaps leaves its device in a weird state.

If it's not shared, it still might be shared behind the scene. The
other device uses MSI(X) and when shutdown MSI is disabled so the
default IRQ route which points to IRQ16 would be active again.

I assume, that the RCU stuff just causes enough timing difference to
uncover the underlying issue.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/