Re: qstor driver -> irq 193: nobody cared

[Mark Lord]

Alberto Alonso wrote:
> OK, after adding the printk line I can start seeing
> results.
>
> I guess it has been close to 10 on quite a few
> occasions.
..
> # grep qstor /var/log/messages
> Nov 12 07:00:53 w100 kernel: sata_qstor: spurious=0
> Nov 12 07:00:53 w100 kernel: sata_qstor: spurious=1
> Nov 12 07:00:53 w100 kernel: sata_qstor: spurious=0
> Nov 12 07:00:56 w100 kernel: sata_qstor: spurious=1
> Nov 12 07:00:56 w100 kernel: sata_qstor: spurious=2
..
> On Sun, 2006-11-12 at 00:09 -0500, Mark Lord wrote:
> > Alberto Alonso wrote:
> > > The saga continues. It happened again this morning even with the
> > > patch:
> > ..
> > > > Mmm.. We could apply a bit of fuzzy tolerance for the odd glitch.
> > > > Try this patch (attached) and report back.
> > Did you add the printk() to the patch, as suggested?
..

Excellent!

So, either we have a very noisy bit of hardware in there,
or something is wrong with sata_qstor.c.

The device has two methods for dealing with commands.
Regular R/W uses the driver's host queue "packet" interface,
and all other commands pass through the legacy MMIO mechanism.

I'm betting on some bug/interaction with the latter.

Try this patch and see what happens, on top of the printk patch.

Thanks



--- linux/drivers/scsi/sata_qstor.c.printk	2006-11-06 09:50:02.000000000 -0500
+++ linux/drivers/scsi/sata_qstor.c	2006-11-13 09:25:49.000000000 -0500
@@ -431,6 +431,7 @@
 		if (ap &&
 		    !(ap->flags & ATA_FLAG_DISABLED)) {
 			struct ata_queued_cmd *qc;
+			u8 status = ata_check_status(ap);
 			struct qs_port_priv *pp = ap->private_data;
 			if (!pp || pp->state != qs_state_mmio)
 				continue;
@@ -438,7 +439,7 @@
 			if (qc && (!(qc->tf.flags & ATA_TFLAG_POLLING))) {
 
 				/* check main status, clearing INTRQ */
-				u8 status = ata_check_status(ap);
+				//u8 status = ata_check_status(ap);
 				if ((status & ATA_BUSY))
 					continue;
 				DPRINTK("ata%u: protocol %d (dev_stat 0x%X)\n",