On Mon, 2006-04-24 at 10:29 -0500, Gustavo Guillermo Pérez wrote:
> Then I have an Idea, what happen if on scsi_lib.c where resides the faulty
> code:
> if (!(req->flags & REQ_QUIET))
> dev_printk(KERN_INFO,
> &cmd->device->sdev_gendev,
> "Device not ready.\n");
> scsi_end_request(cmd, 0, this_count, 1);
> return;
> I change scsi_end_request(cmd, 0, this_count, 1);
> by a comparison about vendor ID and Model
> and then if is a buggy one executes scsi_requeue_command(q, cmd); instead of
> scsi_end_request(cmd, 0, this_count, 1);
Let's actually debug the problem before trying to fix it. It would be
helpful to know what type of not-ready this is (and whether it's
internally generated in usb or firewire, but that comes later).
Try this addition and see what it tells us.
James
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 7b0f9a3..cd9df1b 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1074,9 +1074,12 @@ void scsi_io_completion(struct scsi_cmnd
scsi_requeue_command(q, cmd);
return;
}
- if (!(req->flags & REQ_QUIET))
+ if (!(req->flags & REQ_QUIET)) {
scmd_printk(KERN_INFO, cmd,
- "Device not ready.\n");
+ "Device not ready: ");
+ scsi_print_sense_hdr("", &sshdr);
+ }
+
scsi_end_request(cmd, 0, this_count, 1);
return;
case VOLUME_OVERFLOW:
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
