Re: Linux 2.6.25-rc4

[Bartlomiej Zolnierkiewicz]

On Sunday 16 March 2008, Linus Torvalds wrote:
> 
> On Sun, 16 Mar 2008, Bartlomiej Zolnierkiewicz wrote:
> > 
> > We don't do error handling for special commands (REQ_TYPE_ATA_*) at all,
> > ide_error() just dumps device's status/error register(s) and finishes early:
> 
> Well that sounds bogus too, for all the same reasons already outlined. The 
> DRQ flag needs to be cleared up on error!

OK, lets try it.

From: Bartlomiej Zolnierkiewicz <bzolnier@xxxxxxxxx>
Subject: [PATCH] ide: correctly handle DRQ bit set on error also for special requests

commit 4d977e43d8ae758434e603cf2455d955f71c77c4 ("ide: check BUSY and ERROR 
status bits before reading data in drive_cmd_intr()") changed DRQ handling
logic (as pointed out by Linus).

Fix it by flushing leftover data for commands using PIO-in protocol
and special requests (rq->cmd_type == REQ_TYPE_ATA_TASKFILE).

Cc: Anders Eriksson <aeriksson@xxxxxxxxxxx>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@xxxxxxxxx>
---
against 2.6.25-rc5, untested

 drivers/ide/ide-io.c |   11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

Index: b/drivers/ide/ide-io.c
===================================================================
--- a/drivers/ide/ide-io.c
+++ b/drivers/ide/ide-io.c
@@ -540,12 +540,19 @@ EXPORT_SYMBOL_GPL(__ide_error);
  
 ide_startstop_t ide_error (ide_drive_t *drive, const char *msg, u8 stat)
 {
-	struct request *rq;
+	ide_hwif_t *hwif = drive->hwif;
+	struct request *rq = hwif->hwgroup->rq;
 	u8 err;
 
+	if (rq && rq->cmd_type == REQ_TYPE_ATA_TASKFILE) {
+		if (hwif->data_phase == TASKFILE_IN && (stat & DRQ_STAT) &&
+		    (hwif->host_flags & IDE_HFLAG_ERROR_STOPS_FIFO) == 0)
+			try_to_flush_leftover_data(drive);
+	}
+
 	err = ide_dump_status(drive, msg, stat);
 
-	if ((rq = HWGROUP(drive)->rq) == NULL)
+	if (rq == NULL)
 		return ide_stopped;
 
 	/* retry only "normal" I/O: */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/