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",
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
