From owner-cvs-sys  Thu Apr 24 09:53:08 1997
Return-Path: <owner-cvs-sys>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id JAA16528
          for cvs-sys-outgoing; Thu, 24 Apr 1997 09:53:08 -0700 (PDT)
Received: from freefall.freebsd.org (freefall.cdrom.com [204.216.27.21])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA16474;
          Thu, 24 Apr 1997 09:52:39 -0700 (PDT)
From: "Justin T. Gibbs" <gibbs@FreeBSD.org>
Received: (from gibbs@localhost)
	by freefall.freebsd.org (8.8.5/8.8.5) id JAA16278;
	Thu, 24 Apr 1997 09:52:20 -0700 (PDT)
Date: Thu, 24 Apr 1997 09:52:20 -0700 (PDT)
Message-Id: <199704241652.JAA16278@freefall.freebsd.org>
To: CVS-committers@FreeBSD.org, cvs-all@FreeBSD.org, cvs-sys@FreeBSD.org
Subject: cvs commit:  src/sys/dev/aic7xxx aic7xxx.reg aic7xxx.seq
Sender: owner-cvs-sys@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

gibbs       97/04/24 09:52:20

  Modified:    sys/dev/aic7xxx  aic7xxx.reg aic7xxx.seq
  Log:
  The following scenario would result in a bogus residual being reported
  if SCB Paging was enabled:
  
      disconnect with more data to transfer
      disconnected SCB gets paged out
      target reconnects so we page SCB back in
      target completes transfer so residual is 0
      target disconnects
      SCB gets reused but not paged out since the residual is 0 (optimization)
      target reconnects so we page the SCB back in
      we report a residual because of stale residual information.
  
  The fix for this is to set a flag that forces the SCB to be paged back
  up to the host if we page in an SCB with a residual
  
  Pointed out by: Doug Ledford <dledford@dialnet.net>
  
  Revision  Changes    Path
  1.3       +2 -2      src/sys/dev/aic7xxx/aic7xxx.reg
  1.73      +6 -1      src/sys/dev/aic7xxx/aic7xxx.seq