Re: 2.6.15-rt16: possible sound-related side-effect

[Jonathan Woithe <jwoithe@physics.adelaide.edu.au>]

Hi all

> > > > In the last week I have updated the kernel on our laptop to 2.6.15-rt16.
> > > > By and large this worked well and had the attractive side effect of making
> > > > the clock run at the correct speed once more.
> > > >
> > > > During development of an ALSA patch I had the need to remove and reinsert
> > > > the hda-intel and hda-codec modules on numerous occasions.  Every so often
> > > > (perhaps once every 5 or 6 times on average) the initialisation sequence of
> > > > hda-intel would get hung up and the associated insmod would never return.  A
> > > > reboot was required to clear the problem.  The following messages were
> > > > written to syslog repeatedly and often:
> > > >
> > > >   Feb  5 21:36:24: ALSA sound/pci/hda/hda_intel.c:511: azx_get_response timeout
> > > >   Feb  5 21:36:26 halite last message repeated 9 times
> > > >   Feb  5 21:36:29 halite kernel: printk: 31 messages suppressed.
> > > >
> > > > I have noticed the "azx_get_response timeout" messages in earlier kernels
> > > > as well, but up until now the hda initialisation hasn't gotten hung up.
> > > >
> > > > The latching up of the hda-intel initialisation does not appear to occur
> > > > when doing the same thing under a non-RT 2.6.15 kernel.  Furthermore, I have
> > > > had an instance where the lockup occured while cold-booting an unmodified
> > > > 2.6.15-rt16, which rules out any changes I made to ALSA as the cause of the
> > > > problem.  In any case the changes I was making to ALSA don't affect the
> > > > initialisation code.
> > > >
> > > > Prior to this kernel I was running an unmodified 2.6.14-rt21 kernel and
> > > > while these messages did occur they didn't cause hda-intel to lock up.
> > > >
> > > > Any suggestions as to what might be causing this and/or of further tests
> > > > which might help narrow down the cause?
:
> Sorry, I was thinking your kernel locked up, not just the insmod.  OK,
> forget about what I asked.

No problem.

> > The "azx_get_response timeout" is only produced by a single function:
> > azx_get_response() in hda_intel.c.  This in turn seems to be called from
> > only one location - azx_codec_create() in hda_intel.c.  azx_probe() calls
> 
> It's not called there. It's setup as a function pointer, so it is called
> when another fuction calls the get_response pointer.

Yep, you're right - I misread the code the other day, probably because I
was in a hurry.  My turn to be sorry. :)

> If you want to know where it is being called from, do add the following:
> 
> static unsigned int azx_get_response(struct hda_codec *codec)
> {
> 	azx_t *chip = codec->bus->private_data;
> 	int timeout = 50;
> 
> 	while (chip->rirb.cmds) {
> 		if (! --timeout) {
> 			snd_printk(KERN_ERR "azx_get_response timeout\n");
> +			dump_stack();
> 			chip->rirb.rp = azx_readb(chip, RIRBWP);
> 			chip->rirb.cmds = 0;
> 			return -1;
> 		}
> 		msleep(1);
> 	}
> 	return chip->rirb.res; /* the last value */
> }
> 
> that will show the call trace of the function.
> :
> > Any other suggestions as to tests which might narrow down the problem's cause?
> 
> Yeah, could you just add that dump_stack to see who is calling this.  Then
> we can look into that.

No problem.  I'll do this sometime over the weekend and report the findings
early next week.

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