> I've been done this booting w/o options and with the
> "ide0=noautotune" option. Haven't tried a non-SMP kernel yet.
>
> Start with these 6 messages:
>
> Feb 28 23:44:50 peter kernel: hda: write_intr: status=0xd0 { Busy }
> Feb 28 23:44:50 peter kernel: ide0: reset: success
> Feb 28 23:44:50 peter kernel: hda: recal_intr: status=0xd0 { Busy }
> Feb 28 23:44:50 peter kernel: ide0: reset: success
> Feb 28 23:44:51 peter kernel: hda: recal_intr: status=0xd0 { Busy }
> Feb 28 23:44:51 peter kernel: end_request: I/O error, dev 03:03, sector 3948627
>
> Repeat with different sector numbers. After a few
> iterations, I start getting these periodically (each following an
> end_request line):
Perhaps the IO-APIC decreased the "hardware irq event" --> "irq handler
called" latency considerably? If the drive's firmware is slightly incorrect,
and does not ensure that BUSY is low before raising INTRQ, a lower latency
might allow us to see this (previously invisible) firmware race.
Does something like the following patch help?
Gadi
--- linux/drivers/block/ide.c~ Sun Mar 1 19:25:44 1998
+++ linux/drivers/block/ide.c Sun Mar 1 19:25:44 1998
@@ -1277,6 +1277,7 @@
} while ((hwif = hwif->next) != hwgroup->hwif);
if (irq == hwif->irq && (handler = hwgroup->handler) != NULL) {
ide_drive_t *drive = hwgroup->drive;
+ int retry = 5;
#if 1 /* temporary, remove later -- FIXME */
{
struct request *rq = hwgroup->rq;
@@ -1291,6 +1292,8 @@
#endif /* temporary */
hwgroup->handler = NULL;
del_timer(&(hwgroup->timer));
+ while ((GET_STAT() & BUSY_STAT) && retry--)
+ udelay(10);
/* if (drive->unmask)
ide_sti(); HACK */
handler(drive);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu