Date: Tue, 22 Dec 1998 16:16:33 -0700 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Julian Elischer <julian@whistle.com> Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>, scsi@FreeBSD.ORG Subject: Re: 3.0R && AHA1540A == no go Message-ID: <199812222324.QAA02978@pluto.plutotech.com> In-Reply-To: Your message of "Tue, 22 Dec 1998 15:11:43 PST." <Pine.BSF.3.95.981222150613.10686A-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>On Tue, 22 Dec 1998, Justin T. Gibbs wrote: > >> >From memory, the old driver tried to handle this case >> >so you might look there for clues... >> >> The old driver never used the residual reporting opcodes and >> the SCSI framework in general ignored residual information. > >The reseidual infrmation was not used because some adapters didn't supply >it. >However those same adaptrers can be assumed to either totally fail or >succeed in disk operations (so you KNOW the residual), or on tape devices, >the residual arrives later in a sense block. (for short reads) In most cases, the complications occur for things like mode pages, inquiry data, and sense data. You need to proactively bzero these structures before performing the operation just in case the device does not fill the allocated space and the controller does not provide residual information. I don't know if all scenarios where these requests are performed follow this protocol. >2/the old st.c (fore getting residuals on tapes) Already done in the sa driver. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812222324.QAA02978>