[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200701302012.11891.liml@rtr.ca>
Date: Tue, 30 Jan 2007 20:12:11 -0500
From: Mark Lord <liml@....ca>
To: linux-kernel@...r.kernel.org,
"IDE/ATA development list" <linux-ide@...r.kernel.org>,
James Bottomley <James.Bottomley@...senpartnership.com>,
linux-scsi@...r.kernel.org
Subject: [PATCH] RESEND scsi_lib.c: continue after MEDIUM_ERROR
Fixed for 80-columns, and copying linux-scsi this time.
In ancient kernels, the SCSI disk code used to continue after
encountering a MEDIUM_ERROR. It would "complete" the good
sectors before the error, fail the bad sector/block, and then
continue with the rest of the request.
Kernels since about 2.6.16 or so have been broken in this regard.
They "complete" the good sectors before the error,
and then fail the entire remaining portions of the request.
This is very risky behaviour, as a request is often a merge
of several bios, and just because one application hits a bad sector
is no reason to pretend that (for example) an adjacent directly lookup also failed.
This patch fixes the behaviour to be similar to what we had originally.
When a bad sector is encounted, SCSI will now work around it again,
failing *only* the bad sector itself.
Signed-off-by: Mark Lord <mlord@...ox.com>
---
--- old/drivers/scsi/scsi_lib.c 2007-01-30 20:06:15.000000000 -0500
+++ linux/drivers/scsi/scsi_lib.c 2007-01-30 20:06:59.000000000 -0500
@@ -865,6 +865,13 @@
*/
if (sense_valid && !sense_deferred) {
switch (sshdr.sense_key) {
+ case MEDIUM_ERROR:
+ /* Bad sector. Fail it, and continue on with the rest */
+ if (scsi_end_request(cmd, 0,
+ cmd->device->sector_size, 1) == NULL) {
+ cmd->retries = 0; /* go around again.. */
+ return;
+ }
case UNIT_ATTENTION:
if (cmd->device->removable) {
/* Detected disc change. Set a bit
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists