From owner-freebsd-scsi@FreeBSD.ORG Thu Nov 11 13:07:31 2010 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A96E1065694; Thu, 11 Nov 2010 13:07:31 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 884CB8FC08; Thu, 11 Nov 2010 13:07:30 +0000 (UTC) Received: by bwz2 with SMTP id 2so1889170bwz.13 for ; Thu, 11 Nov 2010 05:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=a+pDfTT/zJsOxqc61Ol7WgkltbK1q8HNA3j1kujoJrQ=; b=rb+dMtjoYOvHnUg+J03C+pDstOgGpdMNfsp4e8BRN+8ZWj0DCHCdTW/iB+twBRdpjF l0HcEfypqvdpt48s/LyToeZgC0C1/pubTl2s31KS4n62INEt0/ftwos2wokLnM996k5B ytZaY5hX3KdxvtArO2IIgGiZ482aSV0ZXmTxM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=FxafP9goUSkzLj23mec3y3Ogy48FcQJlI+3u0WibEwH4nALNl/xwC7zgVa0gl2NDBK u5rJr8at9SlxI+0n4lHyB8hfCCsTA3Nr+KxdHfnrX0GAGTPjQGU14Bus/ijw5KdDbk20 m9X4vP3sZzj0SdFbV3zYUNFqaYvtzlurVS4E4= Received: by 10.204.76.67 with SMTP id b3mr1332240bkk.62.1289480848796; Thu, 11 Nov 2010 05:07:28 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 4sm919804bki.1.2010.11.11.05.07.26 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 05:07:27 -0800 (PST) Sender: Alexander Motin Message-ID: <4CDBEA8B.1020306@FreeBSD.org> Date: Thu, 11 Nov 2010 15:07:23 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Joerg Schilling References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> <4CD83535.1010008@FreeBSD.org> <4cdbbfef.v4cr/k2jZr9gdpyF%Joerg.Schilling@fokus.fraunhofer.de> <4CDBC55B.1040307@FreeBSD.org> <4cdbc65f.bo+mYNFB2GPwXmq7%Joerg.Schilling@fokus.fraunhofer.de> In-Reply-To: <4cdbc65f.bo+mYNFB2GPwXmq7%Joerg.Schilling@fokus.fraunhofer.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, marius@alchemy.franken.de Subject: Re: Sense fetching [Was: cdrtools /devel ...] X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 13:07:31 -0000 Joerg Schilling wrote: > Alexander Motin wrote: > >>> The question still remains whether the previous implementation did return resid >>>> 0 in some cases. In this case, I would need to implement both variants in the >>> libscg adaption layer and I would need to know whether I am running on an old >>> version or on a new version kernel. Do you know of a simple method to implement >>> this distinction? >> Yes, some drivers were permanently reporting zero resid, while others >> (mostly real SCSI) were reporting proper values. Now it is the same, >> just more cases should work properly. >> >> Why do you want/need to distinguish them? You should already handle >> non-zero resid properly. Zero resid may be wrong in some cases, but at >> first I don't see fatal problem from it and at second I don't see what >> can you do about it. >> >> If I am missing something - sorry, explain it to me please. > > Compare the number of sense bytes I like to request (18) with the number > previous FreeBSD versions did actually request. It is obvious that in case > there is a resid reported onm an old kernel, libscg (with your chanhge) would > believe that probably less that the absolute minumum of sense data is available. Kernel code I have changed affects only controllers without automatic sense fetching. For such controllers CAM previously always reported zero sense_resid, independently of requested size (which actually was also ignored in this case). So previously whatever you asked for 18 or 32 bytes - sense_resid was always zero, like if you got full 18 or 32 bytes. That was wrong. Now, in the same situation, if device wants to return let's say 20 bytes -- you will get 0 and 12 bytes of sense_resid respectively, meaning 18 and 20 bytes of received sense. AFAIK sense_resid always measured from the requested sense_len. In my patch for libscg you may see that I have changed both request and response paths. Resulted sense_count should be absolutely the same. -- Alexander Motin