James Bottomley wrote: > Theory number two is a block timeout cockup. It looks like > sdev->timeout is vestigial and has zero value, so we shouldn't be using > it in the start command, so try this. > > If this works, the correct fix will be to kill the sdev timeout > parameter so we get a compile failure where anything tries to use it. > > James > > --- > > diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c > index 3863617..de3f6d0 100644 > --- a/drivers/scsi/scsi_error.c > +++ b/drivers/scsi/scsi_error.c > @@ -933,7 +933,7 @@ static int scsi_eh_try_stu(struct scsi_cmnd *scmd) > > for (i = 0; rtn == NEEDS_RETRY && i < 2; i++) > rtn = scsi_send_eh_cmnd(scmd, stu_command, 6, > - scmd->device->timeout, 0); > + 3*SENSE_TIMEOUT, 0); > > if (rtn == SUCCESS) > return 0; > > Yes, this works with all of the SBP-2 bridges here which exhibit this false TEST UNIT READY "GOOD" status. BTW, 3 * SENSE_TIMEOUT == 30 seconds may actually be a little bit narrow as a START UNIT timeout. The disks which I tested here --- a few 7200 RPM IDE or SATA disks behind the SBP-2 bridges --- usually take about 7 seconds to spin up in single-disk enclosures and 14 seconds in dual-disk enclosures, since the bridge spins them up serially. But a dual-disk enclosure with Hitachi Deskstar 7K400 took 28 seconds. Maybe this should be used in scsi_eh_try_stu: include/scsi/scsi.h:#define START_STOP_TIMEOUT (60 * HZ) Thanks a lot, -- Stefan Richter -=====-==--- =-== ====- http://arcgraph.de/sr/ -- To unsubscribe from this list: 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
