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

linas_at_austin.ibm.com
Date: 09/30/03

  • Next message: Andrea Arcangeli: "Re: [BUG] 2.4.x RT signal leak with kupdated (and maybe others)"
    Date:	Tue, 30 Sep 2003 13:12:56 -0500
    To: Jeff Garzik <jgarzik@pobox.com>
    
    

    On Tue, Sep 30, 2003 at 01:16:19PM -0400, Jeff Garzik wrote:
    > On Tue, Sep 30, 2003 at 12:09:44PM -0500, linas@austin.ibm.com 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Andrea Arcangeli: "Re: [BUG] 2.4.x RT signal leak with kupdated (and maybe others)"

    Relevant Pages

    • Re: experiences beyond 4 GB RAM with 2.4.22
      ... > 1) nfs clients see timeouts again, ... > fix it through more nfs-daemons and ... > 2) Box is very slow, kswapd looks very active during tar of a local harddisk. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.6.3 - 8139too timeout debug info
      ... > timeouts - but hopefully I have caught the info required. ... Umm.. ... The following patch (incremental patch) is some part reverts to ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Promise ATA/133 Errors With 2.6.10+
      ... > Timeouts have not changed or have increased in fact. ... Never mind, the offending harddisk has ceased to be yesterday, it is no ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [RFC] A more general timeout specification
      ... > specification of timeouts in new services. ... "precision" field. ... a new user interface I would add support for this. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: VIA SATA Raid needs a long time to recover from suspend
      ... >which need their delay increased. ... Right, changing ata_wait_idle's maximum to 100,000 would be a better fix ... the two timeouts following a resume (though without the stack dump, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)