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

[Steven Rostedt <rostedt@goodmis.org>]

On Fri, 24 Feb 2006, Jonathan Woithe wrote:

>
> I finally got around to doing this and the first two dumps are at the
> end of this message.  Many many more were sent to the logs though - as
> one would expect, since we know that in the fault condition this function
> is called very frequently without any end in site.

Thanks, it didn't find the bug for me, but it did get me a better idea of
what it's doing.  Now that you modified the kernel, I hope you are
comfortable in doing more of that :)

Remove the dump stack, and apply the following patch (should work with
both -rt16 and -rt17).  This is _not_ a bug fix (obviously) but will do
a lot more prints.  I don't know how many interrupts this driver produces
so beware that this can really fill the logs.

Apply the patch and then can you do the same and post the results? This
will give me a good idea at what is happening.  You'll want to remove the
patch afterwards, since it produces a lot of noise.

>
> I've put the *full* dump up at
>
>   http://www.atrad.com.au/~jwoithe/kernel/full_timeout_dump.bz2
>
> if anyone's interested.  Similarly, I moved the dump_stack() call
> outside the while() loop and obtained a dump in the case of things
> working correctly.  You can grab this from
>
>   http://www.atrad.com.au/~jwoithe/kernel/dump_loaded_ok.bz2
>
> Oh yes, the dump_stack() call was put *before* the snd_printk() call
> when I did the tests.  This makes no practical difference except that it
> explains why the output from this came after the dumps.
>
> Over the weekend I'll try to test 2.6.15-rt17 since that's recently come
> out.
>
> What next?
>

Here's the patch.

-- Steve

Index: linux-2.6.15-rt17/sound/pci/hda/hda_intel.c
===================================================================
--- linux-2.6.15-rt17.orig/sound/pci/hda/hda_intel.c	2006-02-08 08:34:07.000000000 -0500
+++ linux-2.6.15-rt17/sound/pci/hda/hda_intel.c	2006-02-24 02:28:24.000000000 -0500
@@ -486,10 +486,14 @@ static void azx_update_rirb(azx_t *chip)
 	u32 res, res_ex;

 	wp = azx_readb(chip, RIRBWP);
-	if (wp == chip->rirb.wp)
+	printk("%s: wp 0x%x\n",__FUNCTION__,wp);
+	if (wp == chip->rirb.wp) {
+		printk("%s: ?? bye bye\n",__FUNCTION__);
 		return;
+	}
 	chip->rirb.wp = wp;

+	printk("%s: rp=0x%x\n",__FUNCTION__,chip->rirb.rp);
 	while (chip->rirb.rp != wp) {
 		chip->rirb.rp++;
 		chip->rirb.rp %= ICH6_MAX_RIRB_ENTRIES;
@@ -497,13 +501,16 @@ static void azx_update_rirb(azx_t *chip)
 		rp = chip->rirb.rp << 1; /* an RIRB entry is 8-bytes */
 		res_ex = le32_to_cpu(chip->rirb.buf[rp + 1]);
 		res = le32_to_cpu(chip->rirb.buf[rp]);
-		if (res_ex & ICH6_RIRB_EX_UNSOL_EV)
+		if (res_ex & ICH6_RIRB_EX_UNSOL_EV) {
+			printk("%s: unsol event\n",__FUNCTION__);
 			snd_hda_queue_unsol_event(chip->bus, res, res_ex);
-		else if (chip->rirb.cmds) {
+		} else if (chip->rirb.cmds) {
 			chip->rirb.cmds--;
+			printk("%s: chip->rirb.cmds=0x%x\n",__FUNCTION__,chip->rirb.cmds);
 			chip->rirb.res = res;
 		}
 	}
+	printk("%s: out\n",__FUNCTION__);
 }

 /* receive a response */
@@ -767,11 +774,14 @@ static irqreturn_t azx_interrupt(int irq
 	u32 status;
 	int i;

+	printk("%s: irq %d\n",__FUNCTION__,irq);
 	spin_lock(&chip->reg_lock);

 	status = azx_readl(chip, INTSTS);
+	printk("%s: status INTSTS 0x%x\n",__FUNCTION__,status);
 	if (status == 0) {
 		spin_unlock(&chip->reg_lock);
+		printk("%s: no irq?\n",__FUNCTION__);
 		return IRQ_NONE;
 	}

@@ -791,6 +801,7 @@ static irqreturn_t azx_interrupt(int irq

 	/* clear rirb int */
 	status = azx_readb(chip, RIRBSTS);
+	printk("%s: status RIRBSTS 0x%x\n",__FUNCTION__,status);
 	if (status & RIRB_INT_MASK) {
 		if (status & RIRB_INT_RESPONSE)
 			azx_update_rirb(chip);
@@ -804,6 +815,7 @@ static irqreturn_t azx_interrupt(int irq
 #endif
 	spin_unlock(&chip->reg_lock);

+	printk("%s: out\n",__FUNCTION__);
 	return IRQ_HANDLED;
 }

-
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/