Martin Ammermüller wrote:
With high disk I/O and a 2.6.18-rc1 kernel i get these errors (depending
upon the work i do, up to several times a day):
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x400000 action 0x2 frozen
ata1.00: (BMDMA stat 0x20)
ata1.00: tag 0 cmd 0xc8 Emask 0x2 stat 0x58 err 0x0 (HSM violation)
Hmm... Interesting. It gets HSM violation first.
ata1: soft resetting port
ata1: port is slow to respond, please be patient
ata1: port failed to respond (30 secs)
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ATA: abnormal status 0xD8 on port 0xDCA18087
ATA: abnormal status 0xD8 on port 0xDCA18087
ATA: abnormal status 0xD8 on port 0xDCA18087
ATA: abnormal status 0xD8 on port 0xDCA18087
ATA: abnormal status 0xD8 on port 0xDCA18087
ata1.00: qc timeout (cmd 0xec)
ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata1.00: revalidation failed (errno=-5)
ata1: failed to recover some devices, retrying in 5 secs
ata1: hard resetting port
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: configured for UDMA/100
ata1: EH complete
Then two timeouts while recovering.
SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: drive cache: write back
Anyways, if your harddisk is doing this regularly,
your hardware is faulty. Maybe the connection between the controller
and the disk is the problem or the disk itself.
I did not get those errors with Windows XP and i am not the only one who
has problems running this particular laptop model with a linux kernel.
Ok, to be honest, there's actually only one person i know of which
bothered enough about exactly the same errors to send me an e-mail (he
discovered at least one of my messages to this list). But in my
experience there are almost always others getting the same error, but
which remain silent.
It might be that the drive is quirky and raises interrupts prematurely
sometimes. Depending on how the driver performs recovery, the effect
can be hidden from user. Can you try the attached patch and see how the
kernel acts?
--
tejun
diff --git a/drivers/scsi/sata_sil.c b/drivers/scsi/sata_sil.c
index d0a8507..6633738 100644
--- a/drivers/scsi/sata_sil.c
+++ b/drivers/scsi/sata_sil.c
@@ -380,11 +380,14 @@ static void sil_host_intr(struct ata_por
ap->eh_info.serror |= serror;
}
+ ata_port_printk(ap, KERN_ERR, "XXX: SATA_IRQ serror=%x\n", serror);
goto freeze;
}
- if (unlikely(!qc || qc->tf.ctl & ATA_NIEN))
+ if (unlikely(!qc || qc->tf.ctl & ATA_NIEN)) {
+ ata_port_printk(ap, KERN_ERR, "XXX: qc=%p ctl=%x\n", qc, qc ? qc->tf.ctl : 0);
goto freeze;
+ }
/* Check whether we are expecting interrupt in this state */
switch (ap->hsm_task_state) {
@@ -415,13 +418,17 @@ static void sil_host_intr(struct ata_por
case HSM_ST:
break;
default:
+ ata_port_printk(ap, KERN_ERR, "XXX: HSM=%d\n", ap->hsm_task_state);
goto err_hsm;
}
/* check main status, clearing INTRQ */
status = ata_chk_status(ap);
- if (unlikely(status & ATA_BUSY))
+ if (unlikely(status & ATA_BUSY)) {
+ ata_port_printk(ap, KERN_ERR, "XXX: BUSY status=%x\n",
+ status);
goto err_hsm;
+ }
/* ack bmdma irq events */
ata_bmdma_irq_clear(ap);
@@ -434,6 +441,7 @@ static void sil_host_intr(struct ata_por
err_hsm:
qc->err_mask |= AC_ERR_HSM;
freeze:
+ ap->eh_info.action |= ATA_EH_HARDRESET;
ata_port_freeze(ap);
}
