Date: Fri, 9 Jun 1995 14:47:13 -0400 (EDT) From: Peter Dufault <dufault@hda.com> To: davidg@freefall.cdrom.com (David Greenman) Cc: hackers@freebsd.org Subject: Re: cvs commit: src/sys/pci aic7870.c Message-ID: <199506091847.OAA17606@hda.com> In-Reply-To: <199506091806.LAA21171@freefall.cdrom.com> from "David Greenman" at Jun 9, 95 11:06:55 am
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. 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. > 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. -- Peter Dufault Real Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506091847.OAA17606>