Hi,
i begin to suspect that you might suffer from two
independent problems:
- A growisofs bug with DAO on new kernels, found in april 2014:
https://lists.debian.org/cdwrite/2012/04/msg00010.html
- Poor drive-media compatibility in the case of the xorriso
burn runs.
On a side note:
Mind to share with me the way you started a VM with connection
to the real DVD drive ? This is on my TO-LEARN list.
-----------------------------------------------------------------
Detail discussion:
> OK, so that is exclusively a thing of the writer device, if I understand
> this correctly.
I rather assume that some characteristic of the DAO run
causes the new kernel to abort the pending transaction.
> > My grand unified error list has these candidates:
> [snip bec' error code isn't there]
All the listed errors could cause the growisofs message
if the "sense bytes" are retuned in format "Descriptor"
rather than the format "Fixed" expected by growisofs.
The lower four bits of byte 2 ar "SK" in "Fixed".
The whole byte 2 is "ASC" in "Descriptor" format.
(cdrecord would make it easier to decode because it
shows the raw sense bytes with an error message.
Google "Sense bytes: 72".)
Urm, this brought me to a discussion on cdwrite mailing
list three years ago. It has a striking similarity with
the growisofs run that threw the error:
https://lists.debian.org/cdwrite/2012/04/msg00010.html
and follow-ups. Honza Horak stated this in msg00012.html:
"Regarding the alignment I observe growisofs always writes
16 blocks chunks, even the last one, no matter if the
original iso was aligned to 16 blocks or not."
After finally acknowledging the validity of the bug, i wrote
in msg00016.html:
"In general i wonder why this never showed up as a bug up to now.
It depends on the kernel whether this oversized parameter
of struct sg_io_hdr.dxfer_len can do harm. The actual transfer
length can be deduced from the SCSI command."
So we have a nice suspect here.
If the old kernel deduced the transfer size from the correct
command byte string ("CDB") then it sent a correct transaction.
If the new kernel used the size announced in the API structure
sg_io_hdr, then it used the wrong size and got at odds with
the drive.
But why did the xorriso DAO run fail then ?
Honza Horak tested with cdrskin, which uses libburn like xorriso.
At that time it could at most be version 1.2.6.
Nevertheless:
What happens if you pad up your ISO image to full 32 KB,
or if you apply the growisofs patch at the end of
https://lists.debian.org/cdwrite/2012/04/msg00015.html
> Aug 3 08:55:37 lxcl01 kernel: [244027.061869] sr 5:0:0:0: [sr0] unaligned
> transfer
This could possibly be a consequence of the growisofs bug.
One half of the kernel might believe in the write operation
being aligned to 32 KB, the other might then see non-aligmnent
in the command bytes.
> $ xorriso -outdev /dev/sr0 -toc
> ...
> ISO session : 1 , 0 , 641721s , DVDVIDEO
> Media summary: 1 session, 641871 data blocks, 1254m data, 0 free
Now what is this ?
It still says there is a readable track.
What do you get from this chreckread run (done via SG_IO,
not via buffered i/o):
xorriso -outdev /dev/sr0 -check_media use=outdev --
Testing with a CD-R i get:
Drive current: -outdev '/dev/sr0'
Media current: CD-R
Media status : is written , is closed
Media summary: 1 session, 103514 data blocks, 202m data, 0 free
xorriso : UPDATE : 32 blocks read in 3 seconds , 0.2xC
xorriso : UPDATE : 1024 blocks read in 4 seconds , 13.2xC
...
xorriso : UPDATE : 103514 blocks read in 65 seconds = 21.2xC
Media checks : lba , size , quality
Media region : 0 , 103512 , + good
Media region : 103512 , 2 , 0 tao_end
This says that no hardware read errors were reported.
Else one would see some error messages of xorriso and libburn.
If you want to compare the data with your image, you may use
xorriso -outdev /dev/sr0 -check_media use=outdev data_to=image_copy.iso --
and truncate the resulting file image_copy.iso to the size of the
original image file, before running diff.
(Use of xorriso command -outdev rather than -indev avoids the
attempt to load ISO 9660 meta data.)
> after several attempts with open / close CD-tray on the computer
> the DVD is eventually recognized by the OS and DVD menu can be
> used and video shown,
Looks like poor optics.
libburn has few influence on the physical quality of the
burn. Low write speed is said to help, but i cannot confirm
this opinion from any hard facts.
> I'll try and get a new drive coming Monday.
An ill drive would have to be ill with old kernel too.
First get another spindle of DVD-R from a different brand.
-----------------------------------------------------------
Now how does a virtual real drive work ?
btrace wrote:
> 11,0 2 12 13.123822746 13161 G N [ATA-1]
> 11,0 2 13 13.123824660 13161 I R 128 (5a 00 2a 00 00 00 00 00
> 80 00 ..) [ATA-1]
> 11,0 2 14 13.123824957 13161 D R 128 (5a 00 2a 00 00 00 00 00
> 80 00 ..) [ATA-1]
> 11,0 2 15 13.125130048 0 C R (5a 00 2a 00 00 00 00 00 80
> 00 ..) [0]
This is probably the guest kernel inquiring the mode page
0x2A in order to tell the stuff in /proc/sys/dev/cdrom/info.
> 11,0 1 34 58.500371538 13161 G N [ATA-1]
> 11,0 1 35 58.500373545 13161 I R 36 (ad 00 00 00 00 00 00 ff
> 00 24 00 ..) [ATA-1]
> 11,0 1 36 58.500373892 13161 D R 36 (ad 00 00 00 00 00 00 ff
00
> 11,0 1 37 58.502316526 13161 G N [ATA-1]
> 11,0 1 38 58.502317545 13161 I R 32 (51 00 00 00 00 00 00 00
> 20 00 ..) [ATA-1]
> 11,0 1 39 58.502317688 13161 D R 32 (51 00 00 00 00 00 00 00
> 20 00 ..) [ATA-1]
> 11,0 1 40 58.503564947 13161 G N [ATA-1]
> 11,0 1 41 58.503565887 13161 I R 32 (52 01 00 00 00 01 00 00
> 20 00 ..) [ATA-1]
> 11,0 1 42 58.503566042 13161 D R 32 (52 01 00 00 00 01 00 00
> 20 00 ..) [ATA-1]
These are the commands for dvd+rw-mediainfo sections
READ DVD STRUCTURE[#0h]:
...
READ DISC INFORMATION:
...
READ TRACK INFORMATION[#1]:
...
So obviously the commands from the guest indeed pass through the
kernel of the host.
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/3018560391267209...@scdbackup.webframe.org
