Subject: Re: Feb. 29 kernel
To: Jarle Fredrik Greipsland <jarle@runit.sintef.no>
From: Justin T. Gibbs <gibbs@freefall.freebsd.org>
List: current-users
Date: 03/03/1996 18:01:26
>Old versions of the upper level scsi drivers, at least for disks, used
>to ignore the value in xs->residue if the transfer completed
>successfully.  They don't do that anymore.  The fix attached below
>tries to conserve the transfer length accounting, but keeps around a
>boolean value for each transfer that says whether the transfer count
>has ever been 0.  If it has once been 0, and the status code is GOOD,
>just do xs->residue = 0;  This fixes my problem, at least.  Something
>similar may work for the esp driver as well.
>
>					-jarle

I haven't fully reviewed your patch, but I think that a more generic
solution is needed.  At the end of each data phase, the residual is always
correct, so you update the residual as the number of sg segments left and the
number of bytes left to transfer in the current segment at that time.  This
implies that the residual is never affected unless the target goes into the
data phase so an implied restore data pointers cannot corrupt the residual
if a target reconnects and never goes into a data phase.  You can also
delay calculating the amount of residual comprised by left over SG segments
until the transaction completes.  If you count the current SG segment in
your residual SG count, you can even simply test for a residual by only
looking to see if the SG count is non-zero.  The aic7xxx sequencer code
has used this approach for some time and I've never seen the types of
problems you report.

--
Justin T. Gibbs
===========================================
  FreeBSD: Turning PCs into workstations
===========================================