Comment 6 for bug 1757030

On Wed, Mar 21, 2018 at 04:42:25PM -0000, Thomas Schmitt wrote:
>
> Looking at the source code of growisofs it seems that no command RESERVE
> TRACK is sent for DVD+R DL. libburn sends it if it decided for DAO/SAO-like
> writing for which it announces the amount of data in advance.
>
> You could risk a medium and run xorrecord with explicit option -tao
> in order to see whether it fails too:
>
> xorrecord dev=/dev/sr0 -v -tao -pad 2017.iso
>
> (If no -tao or -dao is given, i expect libburn to decide for -dao.)

With -tao option, xorrecord has no trouble at all.

> > :-[ WRITE@LBA=0h failed with SK=5h/ASC=21h/ACQ=04h]: Invalid argument
>
> It is not normal that a blank medium cannot take a first WRITE command
> to block 0 and carrying 16 blocks. The error code stems from the drive.
> But i cannot imagine what growisofs could have done wrong to get this
> reply to its command.

Is there an easy way to dump the raw commands before the one that
failed? Maybe growisofs has put the drive into a weird state so that
this subsequent normal-looking command fails.

> > [5509731.308149] ata1.00: status: { DRDY }
> > [5509736.352258] ata1: link is slow to respond, please be patient (ready=0)
> > [5509741.332040] ata1: device not ready (errno=-16), forcing hardreset
>
> Some quite short timeout period is to see here. After only 5 seconds the
> first complaint appears. 5 seconds later, the device gets reset.
>
> It is not clear to me whether the error was perceived by growisofs before
> or after that reset.

The reset preceded the userspace error.

> If no deterministic explanation can be found, then you have to expect that
> xorrecord could fail too with that drive at some random occasion.

I suppose, but I have zero problems with xorrecord with any drive or
media so far, so I feel that this is a bug in growisofs with this
specific drive.

--
Ryan C. Underwood, <email address hidden>