diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2008-03-18 21:26:24 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2008-03-18 21:26:24 -0700 |
commit | 6c3c3158a81d6a92d335dd27ad9eb43f6b4c664b (patch) | |
tree | fc740e2fff9c0f3d9e75848b6e106f4251dc7ec7 /drivers/ide | |
parent | d5eee405723eedbd621275e045ac9b36f668c39f (diff) | |
download | kernel_samsung_smdk4412-6c3c3158a81d6a92d335dd27ad9eb43f6b4c664b.zip kernel_samsung_smdk4412-6c3c3158a81d6a92d335dd27ad9eb43f6b4c664b.tar.gz kernel_samsung_smdk4412-6c3c3158a81d6a92d335dd27ad9eb43f6b4c664b.tar.bz2 |
IDE: Make taskfile interface more robust wrt unexpected end-of-command
Now that we handle all the special commands using REQ_TYPE_ATA_TASKFILE
rather than using the old REQ_TYPE_ATA_CMD model, we need to also
emulate the lack of full taskfile data that comes with the old command
model (ie when commands are generated with the HDIO_DRIVE_CMD ioctl
rather than using the HDIO_DRIVE_TASK[FILE] ioctls).
In particular, this means that we should handle command completion the
more relaxed way that the old drive_cmd_intr() code did. It allows
commands to finish early even if they don't use up all the data that we
thought we had for them.
This fixes a regression seen by Anders Eriksson where some SMART
commands sent by smartd would cause a boot-time system hang on his
machine because the IDE command handling code didn't realize that the
command had completed.
Tested-by: Anders Eriksson <aeriksson@fastmail.fm>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Ingo Molnar <mingo@elte.hu>
Acked-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'drivers/ide')
-rw-r--r-- | drivers/ide/ide-taskfile.c | 36 |
1 files changed, 27 insertions, 9 deletions
diff --git a/drivers/ide/ide-taskfile.c b/drivers/ide/ide-taskfile.c index 0518a2e..4c86a8d 100644 --- a/drivers/ide/ide-taskfile.c +++ b/drivers/ide/ide-taskfile.c @@ -423,6 +423,25 @@ void task_end_request(ide_drive_t *drive, struct request *rq, u8 stat) } /* + * We got an interrupt on a task_in case, but no errors and no DRQ. + * + * It might be a spurious irq (shared irq), but it might be a + * command that had no output. + */ +static ide_startstop_t task_in_unexpected(ide_drive_t *drive, struct request *rq, u8 stat) +{ + /* Command all done? */ + if (OK_STAT(stat, READY_STAT, BUSY_STAT)) { + task_end_request(drive, rq, stat); + return ide_stopped; + } + + /* Assume it was a spurious irq */ + ide_set_handler(drive, &task_in_intr, WAIT_WORSTCASE, NULL); + return ide_started; +} + +/* * Handler for command with PIO data-in phase (Read/Read Multiple). */ static ide_startstop_t task_in_intr(ide_drive_t *drive) @@ -431,18 +450,17 @@ static ide_startstop_t task_in_intr(ide_drive_t *drive) struct request *rq = HWGROUP(drive)->rq; u8 stat = ide_read_status(drive); - /* new way for dealing with premature shared PCI interrupts */ - if (!OK_STAT(stat, DRQ_STAT, BAD_R_STAT)) { - if (stat & (ERR_STAT | DRQ_STAT)) - return task_error(drive, rq, __FUNCTION__, stat); - /* No data yet, so wait for another IRQ. */ - ide_set_handler(drive, &task_in_intr, WAIT_WORSTCASE, NULL); - return ide_started; - } + /* Error? */ + if (stat & ERR_STAT) + return task_error(drive, rq, __FUNCTION__, stat); + + /* Didn't want any data? Odd. */ + if (!(stat & DRQ_STAT)) + return task_in_unexpected(drive, rq, stat); ide_pio_datablock(drive, rq, 0); - /* If it was the last datablock check status and finish transfer. */ + /* Are we done? Check status and finish transfer. */ if (!hwif->nleft) { stat = wait_drive_not_busy(drive); if (!OK_STAT(stat, 0, BAD_STAT)) |