Messages in this thread Patch in this message | | | Date | Sun, 1 Mar 1998 19:31:38 +0300 (IST) | From | Gadi Oxman <> | Subject | Re: IDE still misbehaving in pre-2.1.89-4 [WAS: Can't set UltraDMA mode 2 on Quantum Fireball SE] |
| |
On Sat, 28 Feb 1998, Adam D. Bradley wrote:
> 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
| |