Date: Fri, 09 Jun 1995 13:15:09 -0700 From: "Justin T. Gibbs" <gibbs@freefall.cdrom.com> To: Peter Dufault <dufault@hda.com> Cc: davidg@freefall.cdrom.com (David Greenman), hackers@freebsd.org Subject: Re: cvs commit: src/sys/pci aic7870.c Message-ID: <199506092015.NAA02582@freefall.cdrom.com> In-Reply-To: Your message of "Fri, 09 Jun 95 14:47:13 EDT." <199506091847.OAA17606@hda.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>David Greenman writes: > >(sorry about that last empty message, David) > >> 1) SCSI_RESID_VALID was not getting set in xs->flags so even though the >> aic7xxx driver was doing the right thing, it was getting ignored by the >> upper level scsi code. This may affect tape drives, so I consider this >> a critical fix. > >No, the tape code sets the RESID flag itself based on the info field. > >Prior to adding the RESID_VALID flag for the aha1542 none of the >drivers had it, so there is no need for RESID_VALID unless we want >residuals to work properly in the host adapter code for host adapters >that can detect it. Don't worry that none of the other low level >drivers are setting the RESID_VALID flag. It is good that Justin >supports it now, since now the user calls can detect the number of >bytes actually transferred for this driver as well as the aha1542. Ah. Yes. I just assumed that more people were looking at it since scsi.8 was always ignoring the fact that a residual was returned. >RESID_VALID (IMHO) should go away, and if xs_resid gets set assume it was >set on purpose. Note it is not the same as b_resid that is still >bogusly used as the cylnder for the disk sort. Yes. I vote that it should die to. I was setting resid to 0 which I expected to be sufficient, and I was surprised to see that it wasn't. >> 2) xs->status was not set to zero during the initialization of a command. >> Although I don't think this should be the client's (ie the driver's) >> responsibility, it seems that it currently is, so it needs to be cleared. >> Without this change, the upper level scsi code will attempt to interpret >> the sense information on every command complete (since xs->status is >> usually left at 2, "check sense"). This gives a slight performance >> increase, as well as stops fooling /sbin/scsi into thinking there was >> an error on the command. > >You are right; it is foolish the way it is working now. >I'm the one who elevated xs->status to something used outside >of the host adapter drivers, and the only place it is even looked >at in the upper level code is here: > >> /sys/scsi/scsi_ioctl.c: screq->status = xs->status; > >where it is returned to the user as the target status for a user scsi call. > >That is why the only symptom was scsi(8) failing. The correct fix >is, as you said, to clear it up above. "scsi(8)" may not work >for other host adapters (and we may be getting the extra check sense >branches). > >I'd elect to clear it in get_xs() in scsi_base.c. After 2.0.5. :) >-- >Peter Dufault Real Time Machine Control and Simulation >HD Associates, Inc. Voice: 508 433 6936 >dufault@hda.com Fax: 508 433 5267 -- Justin T. Gibbs ============================================== TCS Instructional Group - Programmer/Analyst 1 Cory | Po | Danube | Volga | Parker | Torus ==============================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506092015.NAA02582>