From owner-freebsd-current@FreeBSD.ORG Thu Nov 11 10:29:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06340106564A; Thu, 11 Nov 2010 10:29:12 +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 27D458FC08; Thu, 11 Nov 2010 10:29:10 +0000 (UTC) Received: by bwz2 with SMTP id 2so1745219bwz.13 for ; Thu, 11 Nov 2010 02:29:10 -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=IBkmn7OjqaG8WH8tmY8jbDAX2tB+EFBeKS8TkX98YRo=; b=Im8CNONFvQTsxaC/ORkRK9l2KSrirGk9O0x3ONTGEzEL/QHLLUNfB6sC6ykQWW4U5A cwNvB6wnEgz22xVgUABtb41mQFxhj3Vi1OUAGAU2MsGBMf7rfkS43QgZjsr75VLIMeD7 otLa5gKixxFsoncTuRUD+qnbFyw/vDdMwHRbM= 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=puHTSR07x7EZyr2Yer1RraanUVyXIpAjDQ+4c97ebMUP27VTHwyTzNuwCy6te2PyS1 7Bajt99mILHleAdHp8+ip8npwIRgLzTe+ic0PurArYm3rPDOgb13XnM/A8O3bx0t2HHc Kos4RANrezdPhpCV2Y+aKY8SzBFJDEThs7NvY= Received: by 10.204.27.20 with SMTP id g20mr1051611bkc.114.1289471349947; Thu, 11 Nov 2010 02:29:09 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id r21sm845182bkj.22.2010.11.11.02.29.07 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 02:29:08 -0800 (PST) Sender: Alexander Motin Message-ID: <4CDBC55B.1040307@FreeBSD.org> Date: Thu, 11 Nov 2010 12:28:43 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) 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> In-Reply-To: <4cdbbfef.v4cr/k2jZr9gdpyF%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-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 10:29:12 -0000 Joerg Schilling wrote: > Alexander Motin wrote: >>>>> Given the fact that many drives will probably only return 18 bytes of sense >>>>> data, this will happen every time libscg is told to fetch more sense than the >>>>> drive is willing to return. >>>>> >>>>> Is there a way to distinct an old kernel from a new one? >>>> I don't see the problem. Previous kernel in most cases reported >>>> sesnse_resid == 0, lying that there is more sense data then really is. >>>> New one should report real (often positive) value. In both cases >>>> sesnse_resid value measured from the value submitted to the kernel. >>> Did the old kernel return a zero sense_resid for any implemented SCSI >>> transport? Libscg is a generic SCSI transport library and cdrecord is just one >>> user of this lib. >> Not sure I understand your question. Zero sesnse_resid is absolutely >> normal situation if device gave same amount of sense as application >> requested. As I can see, many of SCSI controllers report sesnse_resid >> properly. I may assume that some, like atapicd don't -- in that case >> you'll also see 0 there. > > FreeBSD-CAM did try to fetcth more than 18 bytes of sense data and it may be > that some drives did return only 18 bytes. In this case, I would asume that > there is a resid > 0. As I have said, many drivers return resid properly, but some others - don't. These changes should just improve situation. >>> Do you know the CAM behavior for other SCSI transports? >> I don't have real SCSI CD to test, but a as I can see, most of SCSI >> controllers return sense data automatically. Sense fetching changes >> should not affect/break anything there. > > 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. -- Alexander Motin