From owner-freebsd-current@FreeBSD.ORG Wed Jan 28 15:05:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BF6E16A4CE; Wed, 28 Jan 2004 15:05:58 -0800 (PST) Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A7D043D1F; Wed, 28 Jan 2004 15:05:56 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: from panzer.kdm.org (localhost [127.0.0.1]) by panzer.kdm.org (8.12.9/8.12.5) with ESMTP id i0SN5l64089301; Wed, 28 Jan 2004 16:05:47 -0700 (MST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.12.9/8.12.5/Submit) id i0SN5eJ6089300; Wed, 28 Jan 2004 16:05:40 -0700 (MST) (envelope-from ken) Date: Wed, 28 Jan 2004 16:05:40 -0700 From: "Kenneth D. Merry" To: Pav Lucistnik Message-ID: <20040128230540.GA89272@panzer.kdm.org> References: <1075254712.2786.42.camel@itouch-1011.prv.au.itouchnet.net> <20040128110230.A3524@beagle.fokus.fraunhofer.de> <1075287190.46456.7.camel@pav.hide.vol.cz> <20040128184039.GA86444@panzer.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040128184039.GA86444@panzer.kdm.org> User-Agent: Mutt/1.4.1i cc: Andrew Thomson cc: freebsd-current@freebsd.org Subject: Re: atapi cdrecord under 5.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Wed, 28 Jan 2004 23:05:58 -0000 [ resend from a different address so my post will go through, sorry for the duplicate ] On Wed, Jan 28, 2004 at 11:53:10 +0100, Pav Lucistnik wrote: > V st, 28. 01. 2004 v 11:07, Harti Brandt p??e: > > > That may be the same problem I discovered yesterday together with Joerg > > Schilling (the cdrecord author). According to him, for several kinds of CD > > recorders error returns from the recorder are expected by cdrecord (some > > recorders, for example, return an error for long writes, although they > > process it (this is allowed by the SCSI spec)). cdrecord handles these > > error (and they do not turn up as errors to the user), but in order to do > > this it expectes the CAM layer to return correct sense data after an error > > (the CAM spec requires the CAM layer to automatically issue a SENSE > > command after errors). As you can see in the above output, the sense data > > is all zero, which seems to be broken. At the moment it's not clear, where > > the problem exactly is: CAM, ATAPICAM or ATAPI. > > Since ATAng commit sense bytes are no longer automatically filled on > error conditions. This very regression was worked around in recent > growisofs (I did the testing for author). If you as kernel developer > could try looking into it that would be great... Since ATAPICAM doesn't do autosense itself, the error recovery code has to issue the request sense command. (That code was actually somewhat broken initially, since every other driver requests sense for a failed command. So ATAPICAM was the first SIM driver not to do it.) By default, though, commands that are issued through the pass(4) driver (like the commands from cdrecord) do not go through the error recovery code. You have to set the CAM_PASS_ERR_RECOVER flag on the CCB to enable error recovery. (And set the retry count appropriately.) For cdrecord, enabling error recovery in the kernel for its commands is probably not desirable. It probably needs to see errors and deal with them. So we've got two basic choices: - modify cdrecord, and other applications, to look for the CAM_AUTOSNS_VALID status flag on a failed CCB and issue the request sense command if necessary. - modify ATAPICAM to do autosense. The latter would probably be the easiest for application developers to deal with. I assume that you fixed growisofs by using the first method. Ken -- Kenneth Merry ken@FreeBSD.ORG