[summary] Re: burncd 'blank' not terminating ?

[Søren Schmidt]

Luigi Rizzo wrote:
> summary: there was some discussion on how to
> fix the problem, in 6.x, with "burncd -f /dev/acd0 -v blank" getting
> stuck with this message
>
> 	blanking CD, please wait..
>
> This used to work on 4.x.
>
> 6.x changes in two places:
>
>  *  the ioctl handler, acd_get_progress() in /sys/dev/ata/atapi-cd.c
>     does a much stricter error checking, expecting the ATA_SENSE_VALID
>     bit set in response to the ATAPI_READ_CAPACITY call.
>     None of my DVD drives do that:
>
> 	acd0: DVDR <HL-DT-ST DVDRAM GSA-4163B/A101> at ata1-master UDMA33
> 	acd0: DVDR <HL-DT-ST DVDRAM GSA-H10N/JL10> at ata0-slave UDMA33
>
>     even though they do report a valid progress status if you disable
>     the check for ATA_SENSE_VALID, and in fact they do work under 4.x
>
>  *  usr.sbin/burncd/burncd.c waits for a transition of CDRIOCGETPROGRESS
>     from 90..99 to 0, which fails to be detected because the ioctl()
>     always returns 0 when ATA_SENSE_VALID is not set.
>
> In private mail, Soren mentioned that the spec (whatever it is called)
> says that the ATA_SENSE_VALID 'shall be set' when returning a valid value,
> so he is slightly dubious on removing the check in atapi-cd.c
>
> Also, it seems that the proper way to check for completion is to issue
> the TEST UNIT READY command, which is accessible through the CDIOCRESET
> ioct.
>
> I suggest the following two fixes:
> 1. change burncd.c as below, so that if CDRIOCGETPROGRESS does not return
>    anything good, it calls CDIOCRESET to determine when the command
>    is complete.
>    This can be improved by calling CDIOCRESET unconditionally as a
>    termination test
>   
FWIW just checking with TEST UNIT READY in general for progress will 
fail for lots of devices, but it might be that those have prober 
progress reporting so the sum of doing both is of benefit.
> 2. change atapi-cd.c to return something even if ATA_SENSE_VALID is
>    unset. Apparently there is a lot of non-complying hardware around
>    so restricting to what the spec says is like shooting ourselves
>    in the foot.
>   
As I mentioned lots of devices does return garbage there so its more a 
question on which pool of devices you want to have working and which you 
wont, so its not a solution, rather a decision on which devices to 
support properly, I chose those that follow specs.
>       Again, if burncd.c uses CDIOCRESET to determine the completion
>    of the 'blank' operation, we don't care if the return value from
>    CDRIOCGETPROGRESS is incorrect, because we don't rely on it.
>   
Right, but that will leave out reporting of progress which has been 
asked for lots of times since some of this takes time.

As usual there is no easy solution, its a question on which devices work 
and which wont, and that unfortunatly changes over time...


-Søren