From owner-cvs-sys  Thu Apr  3 20:21:47 1997
Return-Path: <owner-cvs-sys>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id UAA13621
          for cvs-sys-outgoing; Thu, 3 Apr 1997 20:21:47 -0800 (PST)
Received: (from gibbs@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id UAA13614;
          Thu, 3 Apr 1997 20:21:45 -0800 (PST)
Date: Thu, 3 Apr 1997 20:21:45 -0800 (PST)
From: "Justin T. Gibbs" <gibbs>
Message-Id: <199704040421.UAA13614@freefall.freebsd.org>
To: CVS-committers, cvs-all, cvs-sys
Subject: cvs commit:  src/sys/i386/scsi aic7xxx.c
Sender: owner-cvs-sys@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

gibbs       97/04/03 20:21:45

  Modified:    sys/i386/scsi  aic7xxx.c
  Log:
  NOOP commit to correct the comment for the last commit:
  Bump the timeout for an "ordered tag" recovery action from 1 to 5 seconds.
  
  Remove the multiple timeout panic.  Its very easy to get into a situation
  where a timedout command will time out a second time even though the
  recovery code is working fine.  A good example is:
  
  1) Command times out during recovery
  2) reset the timeout for the command
  3) Recovery actions complete and all transactions are requeued
  4) second timeout fires off which puts us back into recovery bogusly
  5) another transaction that timedout once during the first recovery action
     times out causing the panic.
  
  In essence, the correct solution to the problem is to put every transaction
  back up into the work queue and have their timeout handling done in the same
  way that all commands are handled.  The CAM layer makes this easy, so it
  will have to wait until then.
  
  Revision  Changes    Path
  1.111     +1 -1      src/sys/i386/scsi/aic7xxx.c