atapi cdrecord under 5.2

[Harti Brandt]

On Wed, 28 Jan 2004, Kenneth D. Merry wrote:

KDM>[ resend from a different address so my post will go through, sorry for the
KDM>duplicate ]
KDM>
KDM>On Wed, Jan 28, 2004 at 11:53:10 +0100, Pav Lucistnik wrote:
KDM>> V st, 28. 01. 2004 v 11:07, Harti Brandt p??e:
KDM>>
KDM>> > That may be the same problem I discovered yesterday together with Joerg
KDM>> > Schilling (the cdrecord author). According to him, for several kinds of CD
KDM>> > recorders error returns from the recorder are expected by cdrecord (some
KDM>> > recorders, for example, return an error for long writes, although they
KDM>> > process it (this is allowed by the SCSI spec)). cdrecord handles these
KDM>> > error (and they do not turn up as errors to the user), but in order to do
KDM>> > this it expectes the CAM layer to return correct sense data after an error
KDM>> > (the CAM spec requires the CAM layer to automatically issue a SENSE
KDM>> > command after errors). As you can see in the above output, the sense data
KDM>> > is all zero, which seems to be broken. At the moment it's not clear, where
KDM>> > the problem exactly is: CAM, ATAPICAM or ATAPI.
KDM>>
KDM>> Since ATAng commit sense bytes are no longer automatically filled on
KDM>> error conditions. This very regression was worked around in recent
KDM>> growisofs (I did the testing for author). If you as kernel developer
KDM>> could try looking into it that would be great...
KDM>
KDM>Since ATAPICAM doesn't do autosense itself, the error recovery code has to
KDM>issue the request sense command.  (That code was actually somewhat broken
KDM>initially, since every other driver requests sense for a failed command.
KDM>So ATAPICAM was the first SIM driver not to do it.)

ATAPICAM does autosense, it's just commented out, because of a bad
interaction with ATAng.

KDM>By default, though, commands that are issued through the pass(4) driver
KDM>(like the commands from cdrecord) do not go through the error recovery
KDM>code.  You have to set the CAM_PASS_ERR_RECOVER flag on the CCB to enable
KDM>error recovery.  (And set the retry count appropriately.)
KDM>
KDM>For cdrecord, enabling error recovery in the kernel for its commands is
KDM>probably not desirable.  It probably needs to see errors and deal with
KDM>them.
KDM>
KDM>So we've got two basic choices:
KDM> - modify cdrecord, and other applications, to look for the
KDM>   CAM_AUTOSNS_VALID status flag on a failed CCB and issue the request
KDM>   sense command if necessary.
KDM> - modify ATAPICAM to do autosense.
KDM>
KDM>The latter would probably be the easiest for application developers to deal
KDM>with.

Yes, and it is the only reliable way. The problem is that you need to
sense as soon as the error happens - the drive must stop processing queued
commands and the driver must stop queueing new commands to the driver
until it has reported sense data. If you put the processing in the user
process, the driver must cause the driver to continue processing as soon
as the driver has returned an error, because it cannot know, whether the
application will sense or not. If there are other commands to the driver
in the queues, the sense data will simply be lost and the application will
see junk. So this is only reliable if you ensure that only one processing
is giving commands on a given drive, which generally you don't want to do.

Also the CAM standard is very clear on this.

harti

KDM> KDM>I assume that you fixed growisofs by using the first method.
KDM>
KDM>Ken

-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
brandt at fokus.fraunhofer.de, harti at freebsd.org