Hi
i can prevent the EPERM failures of ioctl(SG_IO) by opening the
device file /dev/sg1 with O_RDWR rather than O_RDONLY.
In block/raw-posix.c:raw_open_common i implemented this hack:
printf("block/raw-posix.c: raw_open_common(\"%s\", %x)\n",
filename, s->open_flags);
if (strncmp(filename, "/dev/sg", 7) == 0) {
s->open_flags |= O_RDWR;
printf("block/raw-posix.c: /dev/sg hack: s->open_flags is now %x\n",
s->open_flags);
}
before
s->fd = -1;
fd = qemu_open(filename, s->open_flags, 0644);
This enables CD-RW burning.
Burning of DVD+RW still fails quite badly, though.
Paolo:
May i ask for the favor that you try to add O_RDWR to the qemu_open()
call of passthrough devices ?
----------------------------------------------------------------------
While booting the guest, i get these messages
block/raw-posix.c: raw_open_common("/dvdbuffer/i386-install.qemu", 1000)
block/raw-posix.c: raw_open_common("/dvdbuffer/i386-install.qemu", 1002)
block/raw-posix.c: raw_open_common("/dev/sg1", 1000)
block/raw-posix.c: /dev/sg hack: s->open_flags is now 1002
block/raw-posix.c: raw_open_common("/dev/sg1", 1000)
block/raw-posix.c: /dev/sg hack: s->open_flags is now 1002
block/raw-posix.c: raw_open_common("/dvdbuffer/pseudo_drive", 1000)
block/raw-posix.c: raw_open_common("/dvdbuffer/pseudo_drive", 1000)
The printf for failed ioctl is still present, but does not report
anymore:
posix-aio-compat.c: handle_aiocb_ioctl: ioctl(12, 0x2285, ), ret= -1 , errno=
1
I dare to burn a DVD+RW
xorriso -for_backup -scsi_log on -dev /dev/sr0 -add /usr/include --
It blocks on
SET STREAMING
b6 00 00 00 00 00 00 00 00 00 1c 00
To drive: 28b
00 00 00 00 00 00 00 00 00 23 04 88 10 00 00 00 00 00 03 e8
10 00 00 00 00 00 03 e8
The guest system finally gets incommunicado, while the qemu process
on the host consumes 100 % CPU.
No further messages appear on the qemu start terminal.
After 10 minutes i issued on the host "kill -9" to get rid of the qemu
process.
I can start it again, but it does not accept SSH connections but rather
lets the CPU glow at 100 %. It can be killed again.
I reboot the host.
Now qemu can boot the guest again.
I retry with with CD-RW (and thus no SET STREAMING)
It burns !
Afterwards i have one more session on the CD-RW.
Drive current: -dev '/dev/sr1'
Drive type : vendor 'TSSTcorp' product 'CDDVDW SH-S223B' revision 'SB02'
Media current: CD-RW
Media product: 97m15s35f/79m59s74f , Nan-Ya Plastics Corporation
Media status : is written , is appendable
Media blocks : 43153 readable , 309794 writable , 359847 overall
TOC layout : Idx , sbsector , Size , Volume Id
ISO session : 1 , 0 , 27633s , ISOIMAGE
ISO session : 2 , 39183 , 3818s , ISOIMAGE
Media summary: 2 sessions, 31753 data blocks, 62.0m data, 605m free
Media nwa : 50053s
I do a checkread with the MD5s of the single content files, which
were generated and recorded by xorriso option -for_backup:
$ xorriso -for_backup -dev /dev/sr1 -check_md5_r sorry / --
...
Media summary: 2 sessions, 31753 data blocks, 62.0m data, 605m free
Volume id : 'ISOIMAGE'
xorriso : UPDATE : 65536 content bytes read in 6 seconds
xorriso : UPDATE : 13931k content bytes read in 11 seconds
xorriso : UPDATE : 30202k content bytes read in 16 seconds
xorriso : UPDATE : 45284k content bytes read in 21 seconds
xorriso : UPDATE : 61991k content bytes read in 26 seconds
xorriso : UPDATE : 64692k content bytes read in 27 seconds
File contents and their MD5 checksums match.
Comparing ISO image content with hard disk content:
$ xorriso -dev /dev/sr1 -compare_r /usr/include /usr/include
...
xorriso : UPDATE : 6015501 content bytes read in 9 seconds
Both file objects match as far as expectable.
$
Whew !
-----------------------------------------------------------------
Ok. But why does it fail with SET STREAMING ?
This will demand a completely new dive into the entrails of qemu.
Maybe not before tomorrow.
-----------------------------------------------------------------
Above hack does not repair the timeouts with READ DISC STRUCTURE,
which i use to inquire DVD media.
The problematic commands are accompanied by this ioctl failure:
posix-aio-compat.c: handle_aiocb_ioctl: ioctl(12, 0x2285, ),
ret= -1 , errno= 22
This is EINVAL /* Invalid argument */.
The debugging message appears as soon the SCSI command is attempted,
not waiting until the timeout finally snaps.
I verified once again on the host system, that the commands succeed.
They deliver large results:
READ DISC STRUCTURE
ad 00 00 00 00 00 00 04 08 04 00 00
From drive: 2052b
...
READ DISC STRUCTURE
ad 00 00 00 00 00 00 11 01 04 00 00
From drive: 260b
...
But the mere size cannot be the reason, because on the guest, the
third command succeeds with 2052 bytes of payload data (as on the host):
READ DISC STRUCTURE
ad 00 00 00 00 00 00 00 08 04 00 00
From drive: 2052b
...
-----------------------------------------------------------------
Have a nice day :)
Thomas
