From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 17:37:14 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 A4C541065679; Mon, 8 Nov 2010 17:37:14 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2B2458FC32; Mon, 8 Nov 2010 17:37:13 +0000 (UTC) Received: by gwj16 with SMTP id 16so3708623gwj.13 for ; Mon, 08 Nov 2010 09:37:13 -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=J6iMJgoeWVi8OfHg7wJvIJktNxMfinvbWbpZDwyVoMM=; b=N3dxE/P7PSaaZHVB+cjmJML6yL9AVXJJFNVAbFmSfsMDpERNxFHaRcSIV1hEMAYB3P qFOWxtCjgYWbxkx5caGuLXo98jP1SVksBjh9WuIJ41qfco7MsHG5iGH4RTk1qx7rNNwU 2SU6TGDVMg+R9MO1bQ0BG0YuahnjJKqO6Ou6o= 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=bKyHCwuueJ/v8BgRu8SHAQcomYuFQ1UUHpTb7F8uigb/cvfHAa52TvUc7O6jnAPFDM mnlhfNR8+vqjeHvUhalIHIRMZms3G8LGl80cGvY8byZQoyhwmY6+6c7Pyu29ZBXYQJkV fJW75t1MJ0UpZjh1UFitr1p9Lr5SrVNJ/u1p4= Received: by 10.204.60.199 with SMTP id q7mr684335bkh.39.1289237832362; Mon, 08 Nov 2010 09:37:12 -0800 (PST) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id p22sm126133bkp.21.2010.11.08.09.37.10 (version=SSLv3 cipher=RC4-MD5); Mon, 08 Nov 2010 09:37:11 -0800 (PST) Sender: Alexander Motin Message-ID: <4CD83535.1010008@FreeBSD.org> Date: Mon, 08 Nov 2010 19:36:53 +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> In-Reply-To: <4cd8320a.U7/OjtLLBVtE4dTy%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: Mon, 08 Nov 2010 17:37:14 -0000 Joerg Schilling wrote: > Alexander Motin wrote: >>> Your patch to libscg looks definitely OK if we only look at the new corrected >>> kernel driver behavior. >>> >>> There is a problem: >>> >>> In case that there is a sense data residual > 0, libscg will asume that there >>> is less sense data that really present in case that a "new" libscg is runnung >>> on an old kernel. >>> >>> 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. >>> I see no advantage in removing the call to fillbytes(). >> scgcheck tests how much sense data received by counting 0x00 and 0xff >> bytes. Zero-filling response buffer breaks that check. Though I have no >> idea if other crdtools' applications depend on these zeros. There could >> be some internal inconsistency. > > O, I need to check other low level transport adaptation layers and think about > this statement. > >>> Did you test a modified libscg on an unmodified kernel? >> Unmodified kernel by default doesn't return any sense data at all for >> new CAM-based ATA -- this changes should be invariant. New scgcheck runs >> same bad as old. It just can't become worse. :) >> >> Legacy atapicam wrapper ignores sense_len on input and doesn't fill >> sense_resig on output -- I haven't tested, but it also should be invariant. > > I am not only talking about ATAPI but abut SCSI in general. > > 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. -- Alexander Motin