Re: [2.4 PATCH:] Lengthen SCSI timeouts to deal with broken hardware

From: linas
Date: Tue Sep 30 2003 - 13:16:01 EST


On Tue, Sep 30, 2003 at 01:16:19PM -0400, Jeff Garzik wrote:
> On Tue, Sep 30, 2003 at 12:09:44PM -0500, linas@xxxxxxxxxxxxxx wrote:
> >
> >
> > --- drivers/scsi/scsi_obsolete.c.orig 2003-09-29 17:47:26.000000000 -0500
> > +++ drivers/scsi/scsi_obsolete.c 2003-09-29 17:51:40.000000000 -0500
> > @@ -118,10 +118,19 @@ static void scsi_dump_status(void);
> > #define ABORT_TIMEOUT SCSI_TIMEOUT
> > #define RESET_TIMEOUT SCSI_TIMEOUT
> > #else
> > +#if defined(__powerpc64__)
> > +/* Some Achip ARC765-based DVD-ROM's can take 15 seconds or more to reset.
> > + * All commands (sense, abort) will not get a response until the reset
> > + * completes. Lengthen timeouts to make up for this. */
> > +#define SENSE_TIMEOUT (20*HZ)
> > +#define RESET_TIMEOUT (2*HZ)
> > +#define ABORT_TIMEOUT (25*HZ)
>
> This should be device-dependent, not platform-dependent.


Hi Jeff,

Easier said than done. I could add a new bit to the device blacklist that
covers timeouts. However, one of the timeouts pops during the scsi
inquiry, before we've even identified the device type.

Let me review the changes to make this patch device-dependent:
-- add a new bitfield to the blacklist (in scsi_scan.c) for timeouts
-- add new fields to struct scsi_device that hold timeout values
-- make changes in various places to use the timeout value that
was stored in Scsi_Device, including, possibly, no longer passing
the timeout as a subroutine arg.

This would be a consderably larger, possibly controversial patch.
I suppose I can do it if that's what is needed, but I thought I'd opt
for the minimal, 'tactical' first, dirty as it is.

My goal is to get the fix in there, and make everybody happy in the
process. How should I proceed?

--linas

-
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/