From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 17:23:31 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 508421065673 for ; Mon, 8 Nov 2010 17:23:31 +0000 (UTC) (envelope-from joerg.schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com) Received: from relay01-haj2.antispameurope.com (relay01-haj2.antispameurope.com [83.246.65.51]) by mx1.freebsd.org (Postfix) with ESMTP id D1C0D8FC19 for ; Mon, 8 Nov 2010 17:23:30 +0000 (UTC) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 0BF7716008A; Mon, 8 Nov 2010 18:23:28 +0100 (CET) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 7C4EB160082; Mon, 8 Nov 2010 18:23:26 +0100 (CET) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id oA8HNQ3s028569; Mon, 8 Nov 2010 18:23:26 +0100 (MET) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Nov 2010 18:23:26 +0100 Date: Mon, 08 Nov 2010 18:23:22 +0100 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) To: mav@FreeBSD.org Message-ID: <4cd8320a.U7/OjtLLBVtE4dTy%Joerg.Schilling@fokus.fraunhofer.de> References: <4CD45209.5010607@FreeBSD.org> <20101105192028.GA68728@alchemy.franken.de> <4cd822df.o/wBtwsNCXiy8xZn%Joerg.Schilling@fokus.fraunhofer.de> <4CD82E2A.3070407@FreeBSD.org> In-Reply-To: <4CD82E2A.3070407@FreeBSD.org> User-Agent: nail 11.22 3/20/05 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 08 Nov 2010 17:23:26.0747 (UTC) FILETIME=[A76DB6B0:01CB7F69] X-Mailman-Approved-At: Mon, 08 Nov 2010 17:30:13 +0000 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:23:31 -0000 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. > > 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? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily