Date: Wed, 29 Mar 1995 23:45:20 -0800 (PST) From: julian@tfs.com (Julian Elischer) To: dufault@hda.com (Peter Dufault) Cc: terry@cs.weber.edu, freebsd-hackers@freefall.cdrom.com Subject: Re: Preserving "record structure" during device writes Message-ID: <m0ruEuv-0003vwC@TFS.COM> In-Reply-To: <199503291852.NAA00423@hda.com> from "Peter Dufault" at Mar 29, 95 01:52:37 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> No, the tape drivers do I believe return short reads.. (they DID, in 1.1.5, but it was broken in 2.0 and I'm actually in the process of fixing it..) will get back to you on that :) julian > Terry Lambert writes: > > > > > I'm resurrecting my SCSI target stuff from 386bsd. > > > > > > If processor A tries to read 32 bytes from processor B, and processor > > > B only sends 8, physio keeps looping on the read until we either timeout > > > or receive the full 32 bytes (four transfers). > > > > > > What is the right way to handle this? My inclination is that > > > we want to return a short read, but then I can't just use rawread and > > > rawwrite. > > > > The short reads are necessary; remember the scanner stuff? > > No, I don't. Which scanner stuff? The only scanner firmware I've > written sends a header block saying what the blocking factor is so > that both ends know exactly what to expect for data blocks. It is > specifically done that way to be portable across systems with this > sort of problem. See, I've actually written some of the stupid > code that you curse when you have to interface to a given device. > > None of the scsi code currently return short lengths even if residual > code is handled in the drivers (and it is spotty, I looked this > morning) since they all go through rawread and rawwrite which > unconditionally loop on short reads. This probably only matters > for essentially raw devices such as a scanner, the processor device, > or the unknown device. > > HOST ADAPTER CODE "OWNERS": > > Locally I've added a flag similar to the bounce buffer flag that > says that residual lengths are handled by the driver. I'll probably > commit this code soon so you may want to look at fixing your resid > code. > > The "xs->resid" field is supposed to be the same as bp->b_resid: > the amount of data left untransferred. If you're in the code and > know how to fix it please do so. > > I have fixes for the 154x and the 174x. > > Peter > > -- > 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?m0ruEuv-0003vwC>