[Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi, i sent the following to Paolo Bonzini and Stefan Hajnoczi. Stefan advised > In the future I think it's appropriate to CC qemu-devel since others > in the community may be interested in virtio-scsi discussions too. So i forward my mail to this list. I am subscribed now. A first test report of SCSI passthrough without virtio-scsi will follow soon. Hi, being unsure whether my cause is appropriate for qemu-devel list, i write directly to you, who recently discussed virtio-scsi on that list. If there is a better place, please direct me to it. I would like to participate as tester in the development of virtio-scsi. In the october 2011 archive of qemu-devel list, i found a link to http://wiki.qemu.org/Features/VirtioSCSI with Status: Under development. Not ready for real-world use yet. Features: [...] SCSI passthrough Is there an outlook when it will be ripe for testing SCSI transactions with CD-ish drives ? My goal is to operate a real DVD burner drive from within a Debian GNU/Linux 6.0.3 i386 as guest on a Debian GNU/Linux 6.0.2 amd64. The SCSI commands are transported by the guest system via ioctl(SG_IO). Burn program is xorriso, which uses libburn to communicate with the drive. I am developer of both, but quite a newbie when it comes to virtual machines. I have SCSI specs SPC, SBC, MMC, and some experience in reading and applying them. I can test with DVD drives at IDE/ATAPI, SATA, and USB on real installations of GNU/Linux, FreeBSD 8 and OpenSolaris svn 134. No experience with kernel programming or bus hardware issues. (libburn is an MMC driver in userspace.) - What i tried so far: The qemu version of Debian 6.0.2 is 0.12.5. So i also built 0.15.1 from the release tarball. I experienced no different behavior, though. I tried -drive file=/dev/sr1,if=virtio,media=cdrom which yields the same results as -drive if=scsi. (See below.) Especially the emulated drive identifies itself as vendor 'QEMU' product 'QEMU DVD-ROM' revision '0.15' rather than vendor 'TSSTcorp' product 'CDDVDW SH-S223B' revision 'SB02' of the real one. Obviously i do not get SCSI passthrough here. Before this i tried -cdrom /dev/sr1 The emulated QEMU DVD-ROM rev 0.12 and rev 0.15 expectedly turned out to be usable for reading only. With -drive file=/dev/sr1,if=scsi,bus=4,unit=0,media=cdrom the emulated QEMU DVD-ROM has similar restrictions as with -cdrom, and additionaly states that there is no medium loaded. E.g. with this SCSI transaction: TEST UNIT READY 00 00 00 00 00 00 +++ sense data = F0 00 02 00 00 00 00 0A 00 00 00 00 3A 00 00 00 00 00 +++ key=2 asc=3Ah ascq=00h ( 4 ms) The block device driver of GNU/Linux sees no medium either: dd: opening `/dev/sr0': No medium found This happens with real /dev/sr1 and with an ISO image in a regular file. - Have a nice day :) Thomas
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi, Stefan Hajnoczi wrote: > In the future I think it's appropriate to CC qemu-devel since others > in the community may be interested in virtio-scsi discussions too. Ok. I'll forward my original mail and this reply to qemu-devel. > The current state is that CD-ROM passthrough with virtio-scsi does not > work yet because the in-kernel SCSI target needs a patch to allow the > GET EVENT STATUS NOTIFICATION command which newish Linux kernel use to > poll CD-ROMs. I have the exploration of this command on my own TODO list. Good to know that it might make problems in the kernel. -- > In theory QEMU with -drive file=/dev/sg0,if=scsi,... should provide > SCSI passthrough. QEMU is a userspace process so it uses the > scsi-generic driver to pass through SCSI commands. You could try that > (note this is without virtio-scsi and should work today in theory). The following experiments show quite ill effects. I could need instructions how to install and use qemu from git on Debian GNU/Linux 6.0.2 without disturbing the installed qemu-0.12.5 from apt-get. Currently i run 0.15.1 from release tarball as ./qemu-0.15.1/i386-softmmu/qemu with no special indication that this would cause the problems. The installed 0.12.5 capsizes at the same occasionsi, albeit with different symptoms. Nevertheless i get a message at startup Could not open option rom 'sgabios.bin': No such file or directory which indicates that this is not the intended way to have a qemu for testing. So when i get a git clone, it would be best to have a more conventional test setup. (Be it only for kvm acceleration.) -- First try is on qemu-0.15.1: ./qemu-0.15.1/i386-softmmu/qemu \ -nographic \ -m 512 \ -net nic,model=ne2k_pci \ -net user,hostfwd=tcp::5557-:22 \ -hda /dvdbuffer/i386-install.qemu \ -drive file=/dev/sg2,if=scsi,bus=4,unit=0,media=cdrom Now i have two drives by one option. xorriso -devices reports 0 -dev '/dev/sr0' rwrw-- : 'TSSTcorp' 'CDDVDW SH-S223B' 1 -dev '/dev/sr1' rwrw-- : 'QEMU' 'QEMU DVD-ROM' with /dev/sr1 being an empty drive. (Is this a known bug ?) But /dev/sr0 seems to work well, on the first glimpse. Trying to burn something, being logged in via SSH $ xorriso -dev /dev/sr0 -add /usr/lib reads old session, adds files, but when writing should begin: Connection to localhost closed by remote host. Connection to localhost closed. and i get the host system prompt. The window where i ran qemu says: qemu: ./qemu_dir/qemu-0.15.1/hw/lsi53c895a.c:540: lsi_do_dma: Assertion `s->current' failed. With the installed qemu-0.12.5: kvm \ -nographic \ -m 512 \ -net nic,model=ne2k_pci \ -net user,hostfwd=tcp::5557-:22 \ -hda /dvdbuffer/i386-install.qemu \ -drive file=/dev/sg2,if=scsi,bus=4,unit=0,media=cdrom The drive shows up, this time as /dev/sr1, but gets temporarily stuck when i ask it to show the table-of-content. The stuck SCSI command is READ DISC STRUCTURE ad 00 00 00 00 00 00 04 00 04 00 00 ... waiting 200 seconds for ioctl(SG_IO) to time out ... From drive: 4b 00 00 00 00 libburn next tries another READ DISC STRUCTURE with format 0x11 rather than 0x04, waits another 200 seconds, reads format 0x00, which succeeds immediately. The table-of-content looks ok, though. The old session is present, the new one was not written. The qemu start window reports each time, when the 200 seconds of timeout have elapsed: lsi_scsi: error: Unimplemented message 0x06 lsi_scsi: error: Unimplemented message 0x06 Again i try to burn a session: $ xorriso -dev /dev/sr1 -add /usr/lib It reads the old session, adds files, but when writing should begin, it does not crash qemu but rather stalls. The whole guest system is incommunicado now. The second SSH session has stalled, new SSH sessions cannot be initiated. ssh_exchange_identification: Connection closed by remote host kvm is running at 100 percent CPU. After 15 minutes, i killed the kvm process. An attempt to restart kvm leads to a stalled guest soon after i logged in via SSH, before i could do anything with the DVD drive. I see messages lsi_scsi: error: Unimplemented message 0x06 scsi-generic: Tag 0x0 already in use 0x100cd60 and have to use kill -9 this time. But a new kvm process appears, cannot be killed, and blocks my ssh-fowarding port 5557. I have to reboot the host system, to get rid of that process. -- qemu-0.12.5: I repeated the stuck burn run with xorriso option -scsi_log on. It stalls after this transaction 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 kvm uses 0 to 1 percent CP
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi, Stefan Hajnoczi wrote: > I actually suggest focussing just > on qemu.git/master because that is where developers mostly invest > their time. I did now git clone git://git.qemu.org/qemu.git cd qemu && ./configure && make I assume this binary is the right one for my "AMD Athlon(tm) II X4 620" ./x86_64-softmmu/qemu-system-x86_64 Together with -L ...absolute.path.../pc-bios it still complains on startup Could not open option rom 'sgabios.bin': No such file or directory I cannot spot a file sgabios.bin on the entire host machine by find / -name sgabios.bin 2>/dev/null I repeated the experiments as on qemu-0.15.1. Same results. If i shall do any further experiments, please give me direct instructions. (I'm not much accustomed to qemu and git. Assume that i know nothing beyond what i show here.) In detail: -- Host system is Debian GNU/Linux 6.0.2 amd64: Linux ... 2.6.32-5-amd64 #1 SMP Tue Jun 14 09:42:28 UTC 2011 x86_64 GNU/Linux qemu start command: ...absolute.path.../x86_64-softmmu/qemu-system-x86_64 \ -L ...absolute.path.../pc-bios \ -nographic \ -m 512 \ -net nic,model=ne2k_pci \ -net user,hostfwd=tcp::5557-:22 \ -hda /dvdbuffer/i386-install.qemu \ -drive file=/dev/sg1,if=scsi,media=cdrom I left out -enable-kvm for now, as i suspect it of causing the bad effects on the host, which i experienced with qemu-0.12.5. Guest system is Debian GNU/Linux 6.0.3 i386: Linux ... 2.6.32-5-686 #1 SMP Mon Oct 3 04:15:24 UTC 2011 i686 -- Drive list as detected by xorriso: 0 -dev '/dev/sr0' rwrw-- : 'TSSTcorp' 'CDDVDW SH-S223B' 1 -dev '/dev/sr1' rwrw-- : 'QEMU' 'QEMU DVD-ROM' Inspection: Drive type : vendor 'TSSTcorp' product 'CDDVDW SH-S223B' revision 'SB02' Media current: CD-RW Media status : is written , is appendable Media summary: 1 session, 27783 data blocks, 54.3m data, 626m free Drive type : vendor 'QEMU' product 'QEMU DVD-ROM' revision '0.15' Media current: is not recognizable Media status : is not present The emptiness is indicated by GET CONFIGURATION showing no current profile, and by sense code (2,3A,00) with TEST UNIT READY. The Linux block device driver comes to the same conclusion: dd: opening `/dev/sr1': No medium found -- Burn attempt on CD-RW: xorriso -for_backup -scsi_log on -dev /dev/sr0 -add /usr/lib -- fails and leaves the CD-RW unchanged. (With CD-RW, qemu does not abort as with DVD+RW.) Undesirable SCSI transaction outcome with these commands: PREVENT/ALLOW MEDIA REMOVAL 1e 00 00 00 01 00 +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 06 00 00 00 00 +++ key=B asc=00h ascq=06h ( 0 ms) MODE SELECT 55 10 00 00 00 00 00 00 3c 00 To drive: 60b 00 00 00 00 00 00 00 00 05 32 01 00 00 00 00 00 00 00 00 00 00 00 00 96 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 06 00 00 00 00 +++ key=B asc=00h ascq=06h ( 0 ms) SET CD SPEED bb 00 ff ff 06 e4 00 00 00 00 00 00 +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 06 00 00 00 00 +++ key=B asc=00h ascq=06h ( 0 ms) WRITE(10) 2a 00 00 00 99 0f 00 00 10 00 +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 06 00 00 00 00 +++ key=B asc=00h ascq=06h ( 4 ms) (This tried to send 32 kB of data to block 39183 decimal, where the new track has to start.) SYNCHRONIZE CACHE 35 02 00 00 00 00 00 00 00 00 +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 06 00 00 00 00 +++ key=B asc=00h ascq=06h ( 0 ms) CLOSE TRACK/SESSION 5b 01 02 00 00 00 00 00 00 00 +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 06 00 00 00 00 +++ key=B asc=00h ascq=06h ( 0 ms) The sense code is listed in MMC as: B 00 06 I/O PROCESS TERMINATED -- Now with DVD+RW rather than CD-RW: The attempt to learn about the medium causes two timeouts after 200 seconds each. (I should reduce the time for these experiments.) xorriso -scsi_log on -dev /dev/sr0 -toc has timeouts with READ DISC STRUCTURE ad 00 00 00 00 00 00 04 00 04 00 00 and READ DISC STRUCTURE ad 00 00 00 00 00 00 11 00 04 00 00 but not with READ DISC STRUCTURE ad 00 00 00 00 00 00 00 00 04 00 00 From drive: 4b 08 02 00 00 -- Burn attempt with DVD+RW: xorriso -for_backup -scsi_log on -dev /dev/sr0 -add /usr/lib -- with undesirable outcome of PREVENT/ALLOW MEDIA REMOVAL 1e 00 00 00 01 00 +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 06 00 00 00 00 +++ key=B asc=00h ascq=06h ( 0 ms) SET
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi, Paolo Bonzini wrote: > I suggest trying with 1.0-rc (origin/master). Am i on the right track with git clone git://git.qemu.org/qemu.git ? > scsi-block uses > read+write for READ/WRITE CDBs and SG_IO for everything else. That sounds scary to me. On real Linux systems it is not advisable to mix SG_IO and block device driver. At least not with optical media. Often the block device does not learn about status changes until the tray gets ejected and reloaded manually or by the block device driver. If i load it by START/STOP UNIT via SG_IO, then the block device driver believes there are no readable blocks on the medium. Shall i really try this ? In my experiments WRITE(10) did fail. But so did other commands. Critical is most probably the failure of MODE SELECT 55 10 00 00 00 00 00 00 3c 00 To drive: 60b 00 00 00 00 00 00 00 00 05 32 01 00 00 00 00 00 00 00 00 00 00 00 00 96 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 06 00 00 00 00 +++ key=B asc=00h ascq=06h ( 0 ms) which shall announce the CD write parameters to the drive (Mode Page 5). Without it, you have no control and depend on the existence of a suitable default. Actually i cannot spot in my experiments a single successful command with transfer direction to the drive. READ(10), on the other hand, works well. Have a nice day :) Thomas
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi,
i wrote:
> > The sense code is listed in MMC as:
> >B 00 06 I/O PROCESS TERMINATED
Paolo Bonzini wrote:
> Is it good or bad? :) I see it even in the very first command.
It does not indicate success. MMC only has the meager info above.
SPC-3 says in table 27 about sense key B:
"Bh : ABORTED COMMAND: Indicates that the device server aborted
the command. The application client may be able to recover by
trying the command again."
It does not come from the real drive, i am very sure.
So unless you find a particular reason in qemu, i doubt that repetition
will help.
> What do these give on the host? Sounds like another LSI emulation bug.
All is well with the drive on the host.
This is my test machine, which checks build and function of xorriso
with GNU/Linux, FreeBSD 8, and OpenSolaris. It also tested the
freshly released libcdio-0.83 by Rocky Bernstein which uses
on Linux ioctl(CDROM_SEND_PACKET) rather than ioctl(SG_IO).
When i had trouble with vanishing udev links on Debian 6.0.2,
i also tested with wodim. It worked as good as can be expected.
> > The current release 1.1.6 will not recognize QEMU DVD-ROM because
> > of its inconsistent Mode Page 2Ah with short Page Length (18 decimal).
> The page length is indeed 18 for IDE and 20 for SCSI. I made some changes
> to that page recently, but left the 18 because I feared causing regression.
> But if that is a bug, we can probably fix it in 1.0.
This riddles me.
In hw/scsi-disk.c:mode_sense_page() i see that the page 0x2A
(now MODE_PAGE_CAPABILITIES) gets filled with 22 bytes, compliant
to MMC-1. (Later MMCs have longer minimum sizes.)
But libburn receives only 20 of them, because the Page Length
is reported as 0x12 in the 10th byte of the reply:
MODE SENSE
5a 00 2a 00 00 00 00 00 1c 00
From drive: 28b
00 22 70 00 00 00 00 00 2a 12 00 00 71 60 29 00 02 c2 00 02
02 00 02 c2 00 00 00 00
Nevertheless i see in hw/scsi-disk.c
p[1] = 0x14;
So how is this altered to 0x12 in the further course of processing ?
Further, the Mode Data Length is 0x22, announcing 34 + 2 = 36 overall
bytes in the reply, which matches neither Page Length 0x12 nor 0x14,
but would match Page Length 26 decimal = 0x1a.
A real DVD-ROM drive ('HL-DT-ST' 'DVD-ROM GDR8162B') rather tells
MODE SENSE
5a 00 2a 00 00 00 00 00 1c 00
From drive: 28b
00 20 41 00 00 00 00 00 2a 18 3f 00 71 73 2b 23 21 13 01 00
01 00 0d c8 00 00 00 00
so that libburn repeats the transaction with adjusted Allocation Length
MODE SENSE
5a 00 2a 00 00 00 00 00 22 00
From drive: 34b
00 20 41 00 00 00 00 00 2a 18 3f 00 71 73 2b 23 21 13 01 00
01 00 0d c8 00 00 00 00 00 00 00 01 00 00
(Some Linux transports react badly if the Allocation Length surpasses
the actually available amount of bytes. So i adopted this two-step
strategy, which i learned from growisofs by Andy Polyakov.)
> > Is it a known bug that 'QEMU DVD-ROM' is always empty if it stems
> > from option -drive if=scsi ?
> No, it is not a bug. Remember this is an IDE DVD-ROM. It is not
> instantiated by -drive if=scsi: it is the same device that -cdrom crsates,
You are the expert. So i do not contradict.
But it behaves differently. The devices created by -cdrom do have
a medium loaded. The 'QEMU DVD-ROM' from -drive if=scsi have no medium.
(But the other drive 'CDDVDW SH-S223B' from -drive file=/dev/sg1,if=scsi
has a medium and replies the same as on the host system.)
I just checked with the git clone.
Readable are
-cdrom /dev/sr0
-cdrom /dvdbuffer/pseudo_drive (a regular file)
with dd and with xorriso (via guest SG_IO).
No medium is found in
-drive file=/dev/sr0,if=scsi,media=cdrom
-drive file=/dvdbuffer/pseudo_drive,if=scsi,media=cdrom
which report like the /dev/sg1 based 'QEMU DVD-ROM':
No current profile (00 00 in bytes 6 and 7 of reply):
GET CONFIGURATION
46 00 00 00 00 00 00 00 14 00
From drive: 20b
00 00 00 10 00 00 00 00 00 00 03 08 00 10 00 00 00 08 00 00
Error condition 2 3A 00 MEDIUM NOT PRESENT on
TEST UNIT READY
00 00 00 00 00 00
+++ sense data = F0 00 02 00 00 00 00 0A 00 00 00 00 3A 00 00 00 00 00
+++ key=2 asc=3Ah ascq=00h ( 4 ms)
> try inspecting /dev/disk and sysfs. The ATAPI and SCSI code is
> indeed very similar and will be even more similar in 1.0, but for now they
> are distinct.
They are not easy to distinguish since /dev/hdX passed the way.
$ ls /dev/disk
ata-QEMU_HARDDISK_QM1scsi-SATA_QEMU_HARDDISK_QM1
ata-QEMU_HARDDISK_QM1-part1 scsi-SATA_QEMU_HARDDISK_QM1-part1
ata-QEMU_HARDDISK_QM1-part2 scsi-SATA_QEMU_HARDDISK_QM1-part2
ata-QEMU_HARDDISK_QM1-part5 scsi-SATA_QEMU_HARDDISK_QM1-part5
With the "-part" suffixes, this does not look like a DVD+RW,
which always only has one logical track.
$ ls -l /sys/bus/scsi/devices
total 0
lrwxrwxrwx 1 root root 0 Nov 2 18:30 0:0:0:0 ->
../../../devices/pci:00/:00:01.1/host0/target0:0:0/0:0:0:0
lrwxrwxrwx 1 root root 0 Nov 2 18:30 1:
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi, i wrote: > > So how is this altered to 0x12 in the further course of processing ? Paolo Bonzini wrote: > Because you're using an *IDE* (ATAPI) CD-ROM, not SCSI. See hw/ide/atapi.c. You convinced me. But this does not explain yet the difference in behavior of both groups of IDE DVD-ROMs. Why are those of -drive if=scsi empty ? > Ok, in your counting I should have written 20 for IDE (0x12 + page number + > page size) and 22 for SCSI (0x14 + page number + page size). Why the distinction by transport bus ? Mode page 2Ah is a matter of the drive alone. MMC is independent of the bus. MMC-1 prescribes Page Length 0x14 = 20. This counts the bytes after byte 1 of the mode page. So the page size is 22 bytes. The last byte is the LSB of Current Write Speed (MMC-1 table 103). SPC-1 prescribes to prefix the result of MODE SENSE(10) with 8 bytes of Mode Parameter Header. The first two are MSB and LSB of Mode Data Length. Mode Data Length = 8 + Page Length = 28 = 0x1c The total size of the reply should be 30 bytes. Like 00 1c xx xx xx xx xx xx 2a 14 xx ... up to 30 bytes ... The history of mode page 2Ah is colorful. In MMC-2, the mode page has 26 bytes rather than 22. In MMC-3, the length is variable. At least 32 bytes, with the number of 4-byte write speed descriptors in bytes 30 and 31. In MMC-4 to MMC-6 it is only briefly mentioned as legacy feature. Since all MMC drivers have to be aware of MMC-1 compliant drives, it is well ok to stay with MMC-1, although DVD drives appear first in MMC-2. So i would propose to replace 28 by 30, and set buf[28], buf[29] to 0 in hw/ide/atapi.c , cmd_mode_sense() , case MODE_PAGE_CAPABILITIES I tried to check whether buf[] is large enough in the callers. With some fgrepping i finally end up in hw/ide/core.c:ide_init1() s->io_buffer_total_len = IDE_DMA_BUF_SECTORS*512 + 4; s->io_buffer = qemu_memalign(2048, s->io_buffer_total_len); So roughly this should be ok ... if qemu_memalign() has the job to allocate at least s->io_buffer_total_len bytes. I did not yet find out, why the IDE drive emulation emits a Mode Data Length of 0x22. With Page Length 0x12 it should have been 0x1a. 8 too many. Have a nice day :) Thomas
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi,
i forgot to address this concern:
Paolo Bonzini wrote:
> The page length is indeed 18 for IDE and 20 for SCSI. I made some changes
> to that page recently, but left the 18 because I feared causing regression.
> But if that is a bug, we can probably fix it in 1.0.
The SCSI client is supposed to announce a maximum desired amount of
reply data with MODE SENSE. I see this Allocation Length in use
inside hw/ide/atapi.c:cmd_mode_sense()
if (buf[0] == GPCMD_MODE_SENSE_10) {
max_len = ube16_to_cpu(buf + 7);
} else {
max_len = buf[4];
}
...
ide_atapi_cmd_reply(s, 28, max_len);
and
static void ide_atapi_cmd_reply(IDEState *s, int size, int max_size)
{
if (size > max_size)
size = max_size;
So no driver or application should get overwhelmed by two bytes more
of size, if it correctly submitted its own desired number as Allocation
Length of the commands MODE SENSE(6) or MODE SENSE(10).
Have a nice day :)
Thomas
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi, first i want to thank Paolo for his patience. > So if you specified "-drive if=scsi" *and* "-cdrom", you'd get two non-empty > drives. Indeed. With -drive file=/dev/sr0,if=scsi,media=cdrom -cdrom /dvdbuffer/pseudo_drive i get two drives with media: 0 -dev '/dev/sr0' rwrw-- : 'QEMU' 'QEMU DVD-ROM' 1 -dev '/dev/sr1' rwrw-- : 'QEMU' 'QEMU CD-ROM' /dev/sr0 is from hw/ide/atapi.c:cmd_mode_sense() MODE SENSE 5a 00 2a 00 00 00 00 00 1c 00 From drive: 28b 00 22 70 00 00 00 00 00 2a 12 3b 00 71 60 2b 00 02 c0 00 02 02 00 02 c0 00 00 00 00 /dev/sr1 indeed differs in behavior MODE SENSE 5a 00 2a 00 00 00 00 00 2d 00 From drive: 45b 00 24 00 80 00 00 00 08 00 23 05 40 00 00 08 00 2a 14 3b 00 7f ff 2f 00 22 60 00 02 08 00 0b 00 00 00 0b 00 0b 00 00 00 00 00 00 00 00 Which gives me something to work on. libburn does not take into respect the Block Descriptor of 8 bytes which sits between Mode Data Header and mode page. So it misinterpets the result and demands the wrong Allocation Length. This error is explainable by my reading of MMC-5 which prescribes in table 653: "Block Descriptor Length = 0" MMC-1 on the other hand has in Annex B.4.1 : "The Mode Parameter Block Descriptor does not apply to ATAPI devices, and the Block Descriptor Length in the Mode Parameter Header shall be set to 0." My thanks to qemu and the developers of its SCSI CD-ROM for showing me this misconception in libburn. If i do only -drive file=/dev/sr0,if=scsi,medium=cdrom i get one empty drive, obviously from hw/ide/atapi.c:cmd_mode_sense(): MODE SENSE 5a 00 2a 00 00 00 00 00 1c 00 From drive: 28b 00 22 70 00 00 00 00 00 2a 12 3b 00 71 60 29 00 02 c0 00 02 02 00 02 c0 00 00 00 00 So i mistook the default DVD-ROM drive, which has no source data and thus is empty, for the CD-ROM drive which i expected from -drive if=scsi which would not be empty, but does not show up at all. The question remains, why the CD-ROM drive is missing if i do -drive but not -cdrom. I will repeat my experiments with -drive file=/dev/sg2,if=scsi,media=cdrom -cdrom /dvdbuffer/pseudo_drive Maybe the presence of -cdrom cures the problems i had with passthrough. (The bug in libburn is not to blame for that. The passthrough drive did not deliver a block descriptor.) > Yeah, looks like all the > > case MODE_PAGE_R_W_ERROR: /* error recovery */ > cpu_to_ube16(&buf[0], 16 + 6); > should have "- 2" instead of "+ 6". I came to the same conclusion. The implementation of MODE SENSE(6) in hw/ide/atapi.c:cmd_mode_sense() is wrong. SPC-1, table 239 prescribes only 4 bytes of Mode Parameter Header, with only one byte of Mode Data Length. cmd_mode_sense() prepends 8 bytes unconditionally. Suitable only for MODE SENSE(10). Obviously nobody ever really needed a correct MODE SENSE(6) with the emulated IDE CD-ROM of qemu. MMC-1 allows MODE SENSE(6), MMC-3 implicitely assumes MODE SENSE(10) only, MMC-5 prescribes to use MODE SENSE(10). MMC-2 has a list of required ATAPI commands. MODE SENSE(10) is listed. MODE SENSE(6) is not listed. I compared this with the SCSI counterpart of cmd_mode_sense(): hw/scsi-disk.c:scsi_disk_emulate_mode_sense() It distinguishes between MODE_SENSE, which gets 4 bytes of header, and MODE_SENSE_10, which gets 8. This looks correct. Have a nice day :) Thomas
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi, i repeated my tests with -drive and -cdrom in the same qemu run: ...absolute.path.../x86_64-softmmu/qemu-system-x86_64 \ -enable-kvm \ -L ...absolute.path.../pc-bios \ -nographic \ -m 512 \ -net nic,model=ne2k_pci \ -net user,hostfwd=tcp::5557-:22 \ -hda /dvdbuffer/i386-install.qemu \ -drive file=/dev/sg1,if=scsi,media=cdrom \ -cdrom /dvdbuffer/pseudo_drive xorriso lists two drives 0 -dev '/dev/sr0' rwrw-- : 'QEMU' 'QEMU DVD-ROM' 1 -dev '/dev/sr1' rwrw-- : 'TSSTcorp' 'CDDVDW SH-S223B' Both hold a medium now Drive current: -dev '/dev/sr0' Drive type : vendor 'QEMU' product 'QEMU DVD-ROM' revision '0.15' Media current: CD-ROM Media status : is written , is closed Media summary: 1 session, 109597 data blocks, 214m data, 0 free Drive current: -dev '/dev/sr1' Drive type : vendor 'TSSTcorp' product 'CDDVDW SH-S223B' revision 'SB02' Media current: DVD+RW Media status : is written , is appendable Media summary: 1 session, 16771 data blocks, 32.8m data, 4450m free (The status "appendable" of DVD+RW is an emulation of xorriso, not the result of drive replies.) The other failures remain, i fear: Timeouts with READ DISC STRUCTURE ad 00 00 00 00 00 00 04 00 04 00 00 READ DISC STRUCTURE ad 00 00 00 00 00 00 11 00 04 00 00 but not with READ DISC STRUCTURE ad 00 00 00 00 00 00 00 00 04 00 00 I still get sense code B 00 06 I/O PROCESS TERMINATED with PREVENT/ALLOW MEDIA REMOVAL 1e 00 00 00 01 00 MODE SELECT 55 10 00 00 00 00 00 00 3c 00 SET STREAMING b6 00 00 00 00 00 00 00 00 00 1c 00 SET CD SPEED bb 00 ff ff 06 e4 00 00 00 00 00 00 WRITE(10) 2a 00 00 00 99 0f 00 00 10 00 SYNCHRONIZE CACHE 35 02 00 00 00 00 00 00 00 00 CLOSE TRACK/SESSION 5b 01 02 00 00 00 00 00 00 00 Good news: Other than with qemu-0.12.5, the command 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 does no crash qemu but only throws B 00 06. I am using it with -enable-kvm now, to accelerate booting and login. Do you have a proposal what i should try next ? (Else i will try to find the code which throws B 00 06.) Please give me a note, when there are improvements to test. (Do i get it right, that "git pull" will update my local clone ? In my few encounters with git, "git clone" was all i needed.) --- I have a (weak) argument for making the ATAPI mode page 2A compliant with MMC-1: 'SanDisk' 'Cruzer', an emulated CD-ROM in a memory stick, throws random errors if i ask it for 28 bytes rather than the 30 of MMC-1. Its U3 CD-ROM emulation is not of much importance, as it only serves to store MS-Windows auto-executables. Nevertheless, it serves me as example of a poorly programmed firmware. I now have to bet on the fact that qemu guest operating systems tolerate with ATAPI that i request 30 bytes and the drive delivers only 28. The only occasion, where i am aware of this assumption to fail, is Linux 2.4 with USB attached drives. ATAPI via ide-scsi kernel module did tolerate oversized requests back in 2007. Since then i did not challenge OSes that way. --- Have a nice day :) Thomas
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi,
i could track down the reason for sense code B 00 06 to an ioctl(SG_IO)
which returns -1. errno is 1.
The host system has in /usr/include/asm-generic/errno-base.h
#define EPERM1 /* Operation not permitted */
The user who runs qemu is able to perform e.g.
PREVENT/ALLOW MEDIA REMOVAL
1e 00 00 00 00 00
via ioctl(SG_IO) on /dev/sg1.
So it can hardly be the permissions of the device file:
crw-rw 1 root cdrom 21, 1 Nov 2 12:44 /dev/sg1
The user is member of group cdrom.
For today, i close my shop. Maybe i get an idea tomorrow, how
to further investigate the problem.
-
B 00 06 comes from hw/scsi-generic.c:scsi_command_complete()
static void scsi_command_complete(void *opaque, int ret)
{
...
if (ret != 0) {
switch (ret) {
...
default:
status = CHECK_CONDITION;
scsi_req_build_sense(&r->req, SENSE_CODE(IO_ERROR));
SENSE_CODE is defined in hw/scsi.h
#define SENSE_CODE(x) sense_code_ ## x
so that SENSE_CODE(IO_ERROR) yields this struct from hw/scsi-bus.c
/* Command aborted, I/O process terminated */
const struct SCSISense sense_code_IO_ERROR = {
.key = ABORTED_COMMAND, .asc = 0x00, .ascq = 0x06
};
I tried to activate DPRINTF in hw/scsi-generic.c by removing the "//"
before
#define DEBUG_SCSI
make yields:
.../hw/scsi-generic.c: In function 'scsi_send_command':
.../hw/scsi-generic.c:286: error: 'lun' undeclared (first use in this
function)
.../hw/scsi-generic.c:286: error: 'tag' undeclared (first use in this
function)
So i had to change in scsi_send_command():
- DPRINTF("Command: lun=%d tag=0x%x len %zd data=0x%02x", lun, tag,
+ DPRINTF("Command: len %zd data=0x%02x",
Further i added DPRINTFs to the suspected thrower of B 00 06:
if (ret < 0) {
DPRINTF("scsi_send_command: calling scsi_command_complete(%d)\n",
ret);
scsi_command_complete(r, ret);
return 0;
}
DPRINTF("scsi_send_command: returning 0\n");
This yields with boot-time command
1e 00 00 00 00 00
in the qemu start terminal:
scsi-generic: Command: len 0 data=0x1e 0x00 0x00 0x00 0x00 0x00
scsi-generic: scsi_send_command: returning 0
scsi-generic: scsi_command_complete: ret= -1
I.e. it went through scsi_send_command() and got 0 as return value from
ret = execute_command(s->conf.bs, r, SG_DXFER_NONE, scsi_command_complete);
Nevertheless there happens a call to scsi_command_complete() with ret==-1.
I added more DPRINTF and printf.
It turns out that the offending call comes from
posix-aio-compat.c: posix_aio_process_queue
after the ioctl(SG_IO) failed.
My print points report:
scsi-generic: Command: len 0 data=0x1e 0x00 0x00 0x00 0x00 0x00
block.c: bdrv_aio_ioctl: drv= 0x961f00 , drv->bdrv_aio_ioctl= 0x42bc30
block.c: bdrv_aio_ioctl: drv= 0x9619e0 , drv->bdrv_aio_ioctl= 0x42b2d0
block/raw-posix.c: hdev_aio_ioctl: calling paio_ioctl()
scsi-generic: scsi_send_command: returning 0
posix-aio-compat.c: handle_aiocb_ioctl: ioctl(12, 0x2285, ), ret= -1 , errno=
1
posix-aio-compat.c: qemu_paio_error: ret= -1
posix-aio-compat.c: qemu_paio_error: returning 1
posix-aio-compat.c: posix_aio_process_queue: ret= 1 -> -1
posix-aio-compat.c: posix_aio_process_queue: calling acb->common.cb(,-1)
scsi-generic: scsi_command_complete: ret= -1
scsi-generic: Command complete 0x0x16c0e60 tag=0x0 status=2
ioctl command 0x2285 is defined in /usr/include/scsi/sg.h of host:
#define SG_IO 0x2285
-
Since i inserted the last few of the new printf() calls, i occasionaly
suffer qemu abort by SIGSEGV during guest boot. It happens before the
first DPRINTF happens in scsi_send_command().
But "git diff" reveils no changes towards the original state, which
would be to blame.
The printf format codes and the types match good enough to cause
no warnings at compile time.
Is it a known problem, that adding DPRINTF() or printf() can cause this ?
Or am i just too tired to see my fault ?
+printf("block.c: bdrv_aio_ioctl: drv= 0x%lx , drv->bdrv_aio_ioctl= 0x%lx\n"
,
+ (unsigned long) drv,
+ (unsigned long) (drv ? drv->bdrv_aio_ioctl : NULL));
+printf("block/raw-posix.c: hdev_aio_ioctl: calling paio_ioctl()\n");
+DPRINTF("scsi_command_complete: ret= %d\n", ret);
+DPRINTF("scsi_read_data: calling scsi_command_complete(%d)\n", ret);
+DPRINTF("scsi_write_complete: calling scsi_command_complete(%d)\n", ret);
+DPRINTF("scsi_write_data: calling scsi_command_complete(%d)\n",
+ret);
+DPRINTF("Command: len %zd data=0x%02x",
r->req.cmd.xfer, cmd[0]);
+DPRINTF("scsi_send_command: calling scsi_command_complete(%d)\n",
+ret);
+DPRINTF("scsi_send_command: returning 0\n");
+
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
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 paylo
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi,
i wrote:
> > Paolo:
> > May i ask for the favor that you try to add O_RDWR to the qemu_open()
> > call of passthrough devices ?
Paolo Bonzini wrote:
> I think the problem is that you're passing media=cdrom:
> Just do not do that when using scsi-generic.
The result looks promising, indeed. I disabled my hack but left the
first printf active. Now i see at boot time
block/raw-posix.c: raw_open_common("/dev/sg2", 1000)
block/raw-posix.c: raw_open_common("/dev/sg2", 1002)
and still no failing ioctls or sense code B 00 06.
Burning to an appendable CD-RW in mode TAO still works.
So thanks for this swift fulfilling of my wish. :))
---
Disappointment:
CD-RW burning in mode SAO (on a blank medium) gets stuck at this command
SEND CUE SHEET
5d 00 00 00 00 00 00 00 20 00
To drive: 32b
41 00 00 01 00 00 00 00 41 01 00 10 00 00 00 00 41 01 01 10
00 00 02 00 41 aa 01 01 00 00 35 30
After 200 seconds, the qemu process begins to use 100 % CPU,
and the pacifier messages of xorriso stall. The guest is stuck.
---
When i restart qemu and boot the guest without having rebooted the
host, then after about 20 seconds, qemu is at 100 % CPU and no login
is possible. There is a short time window after boot, where i
can log in.
The problem seems to sit in the host's drive /dev/sr1 which
cannot be ejected or used by any program. They all get stuck.
So it is likely that the ungraceful end of drive usage is to blame.
I will tomorrow attach an USB drive to the machine and see
whether re-powering it spares rebooting. (Linux USB is the best
test bed for dangerous drive experiments.)
---
So there are still two show stoppers.
DVD+RW gets stuck at SET STREAMING.
(I will hack libburn to avoid this command and check whether
writing is possible then. Chances are good, as writing an
already formatted DVD+RW is quite artless.)
CD SAO gets stuck at SEND CUE SHEET.
(SAO is possible with blank CDs only. It is desirable, because its
results do not show the traditional read-ahead bug of Linux, which
is caused by the two non-data sectors at the end of TAO tracks.)
Do you have any hints where i should dig for the special processing
of these commands, which obviously suffer timeout after 200 seconds,
and then drive qemu or the guest into a busily unusable state ?
There must be something about them in qemu. On the host they work
flawlessly.
Both send data, but so do SET CD SPEED, MODE SELECT(10), WRITE(10)
which work fine on the guest.
---
Have a nice day :)
Thomas
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi, i wrote: > > CD SAO gets stuck at SEND CUE SHEET. Paolo Bonzini wrote: > I wouldn't be surprised if they are bugs in either scsi-generic or the LSI > emulation code. They seem to occur when commands return less data than the > guest driver has asked; with master I get a guest oops in the LSI driver, > while the host pads the return data with zeros. Your READ DISC STRUCTURE > work for me with my (out-of-tree) vmw_pvscsi emulation. Please give me instructions for dummies when it is time to update my current slightly altered git clone, and to repeat my tests. (I have the disk space to create a completely new one, if this is desirable.) > Is this okay to send to a blank CD with no prior command? That is, can I > simply change your SEND CUE SHEET dump to "sg_raw -s" to reproduce? You will have to send a mode page 5 at least, which announces write mode SAO. See MMC-3 6.3.5. As usual, there is a 8 byte header, followed by the page. MODE SELECT 55 10 00 00 00 00 00 00 3c 00 To drive: 60b 00 00 00 00 00 00 00 00 05 32 42 c0 00 00 00 00 00 00 00 00 00 00 00 96 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Then it should be ok to send SEND CUE SHEET 5d 00 00 00 00 00 00 00 20 00 To drive: 32b 41 00 00 01 00 00 00 00 41 01 00 10 00 00 00 00 41 01 01 10 00 00 02 00 41 aa 01 01 00 00 35 30 What would have come next: Above cue sheet promises to the drive, that 4023 * 2048 bytes will be written by WRITE(10) commands. It will stubbornly wait for all of them to come. (Maybe you know how to talk the host kernel into resetting it without rebooting.) The first write command would have been WRITE(10) 2a 00 ff ff ff 6a 00 00 10 00 with 32 kiB of payload data. The funny LBA -150 is the start of the pause track before the data track which starts at LBA 0. See the notes at the foot of MMC-3 table 281. >From then on there would be consequtive WRITE(10) commands up to but not including LBA 3873 decimal. Finally libburn would have sent SYNCHRONIZE CACHE 35 02 00 00 00 00 00 00 00 00 and waited for the drive to become ready again. Just for reference: Below this point are only the complete SCSI logs of the real write run and of the drive inquiry which happend before that write attempt. The attempted write run consisted of these commands. The first mode page 5 (with TAO) is a result of libburn architecture. The second one orders SAO. SET CD SPEED bb 00 ff ff 06 e4 00 00 00 00 00 00 1552 ms MODE SELECT 55 10 00 00 00 00 00 00 3c 00 To drive: 60b 00 00 00 00 00 00 00 00 05 32 41 c0 00 00 00 00 00 00 00 00 00 00 00 96 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0 ms READ TRACK INFORMATION 52 01 00 00 00 ff 00 00 14 00 >From drive: 20b 00 1a 01 01 00 00 4f 01 00 00 00 00 00 00 00 00 00 05 7d a7 4 ms MODE SELECT 55 10 00 00 00 00 00 00 3c 00 To drive: 60b 00 00 00 00 00 00 00 00 05 32 42 c0 00 00 00 00 00 00 00 00 00 00 00 96 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4 ms READ TRACK INFORMATION 52 01 00 00 00 ff 00 00 14 00 >From drive: 20b 00 1a 01 01 00 00 4f 01 00 00 00 00 00 00 00 00 00 05 7d a7 0 ms START/STOP UNIT 1b 01 00 00 01 00 64 ms TEST UNIT READY 00 00 00 00 00 00 0 ms START/STOP UNIT 1b 00 00 00 01 00 12 ms SEND CUE SHEET 5d 00 00 00 00 00 00 00 20 00 To drive: 32b 41 00 00 01 00 00 00 00 41 01 00 10 00 00 00 00 41 01 01 10 00 00 02 00 41 aa 01 01 00 00 35 30 This was the last command executed. After the sg_io_hdr.timeout had elapsed, i saw the increase of host CPU from 1 % to 100 %. Before these command there were several commands for drive and media inspection INQUIRY 12 00 00 00 24 00 >From drive: 36b 05 80 05 32 5b 00 00 00 54 53 53 54 63 6f 72 70 43 44 44 56 44 57 20 53 48 2d 53 32 32 33 42 20 53 42 30 32 0 ms MODE SENSE 5a 00 2a 00 00 00 00 00 1e 00 >From drive: 30b 00 4a 20 00 00 00 00 00 2a 42 3f 37 f1 7f 29 23 1b 90 01 00 08 00 16 0d 00 10 06 e4 06 e4 4 ms MODE SENSE 5a 00 2a 00 00 00 00 00 4c 00 >From drive: 76b 00 4a 20 00 00 00 00 00 2a 42 3f 37 f1 7f 29 23 1b 90 01 00 08 00 16 0d 00 10 06 e4 06 e4 00 01 00 00 00 00 06 e4 00 01 00 00 06 e4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4 ms GET CONFIGURATION 46 00 00 00 00 00 00 00 08 00 >From drive: 8b 00 00 01 64 00 00 00 0a 20 ms GET CONFIGURATION 46 00 00 00 00 00 00 01 68 00 >From drive: 360b 00 00 01 64 00 00 00 0a 00 00 03 38 00 15 00 00 00 16 00 00 00 2b 00 00 00 1b 00 00 00 1a 00 00 00 14 00 00 00 13 0
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi, > We're about to release QEMU 1.0(-rc1) and you've just spotted a > compilation issue... Maybe one should consider to obtain the missing information rather than crippling the debug message, like i did. > You've solved this issue 50%! What's missing now is for you to put this > fix into a self-contained patch (without the enabling of DEBUG_SCSI, > etc.) and to submit it using the git-send-email command, so that your > fix can be applied. :) Please bear with me. I'm a git noob, who does everything by try-and-error. It will be better for everybody, if this patch is generated by someone who knows what she or he is doing. I'm still dizzy from drilling a hole into the entrails of qemu and will have to learn about some compiler tricks which are not mentioned in my german copy of K&R. Further, if i learn too much about qemu, then i will lose my naivity skills as unbiased tester. :)) Have a nice day :) Thomas
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi, another showstopper appeared for DVD+RW. After i disabled SET STREAMING, i was able to write a thoroughly formatted DVD+RW. But when i inserted one that was never written up to its end, the attempt failed to (re-)start background formatting (Format Type = 26h): FORMAT UNIT 04 11 00 00 00 00 To drive: 12b 00 02 00 08 ff ff ff ff 98 00 00 01 +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 +++ key=B asc=00h ascq=00h ( 488 ms) I cannot spot an occurence of this sense code in the qemu sources. There are B 00 06 , B 29 07 , B 3E 01. No failed ioctl is reported by my printf. But the failure happened twice. After shutdown of the guest (to get access to the drive), i could format (de-ice) the medium by the host system. Afterwards it was usable on the booted-again guest. Currently i suspect that the sense code stems from the guest kernel. (But caused by some problem with qemu.) This command can be performed without other preparations. But its parameters depend on the media state. The one above is for a partially formatted (i.e. partly written) DVD+RW. With a completely formatted DVD+RW, the attempt to re-format fails, too: FORMAT UNIT 04 11 00 00 00 00 To drive: 12b 00 02 00 08 ff ff ff ff 98 00 00 00 +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 +++ key=B asc=00h ascq=00h ( 488 ms) The same command is appropriate for a new, unformatted DVD+RW. It fails exactly the same way on such a medium. The commands here have the Immed bit set (byte 1, bit1 of payload), so that they should return early. One would watch the drive by TEST UNIT READY for becomming ready again. REQUEST SENSE with DESC bit delivers progress information on some drives. But this is not necessary if FORMAT UNIT already ends with failure indication. Have a nice day :) Thomas
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi, Paolo Bonzini wrote: > Can you retry this running qemu as root or with CAP_SYS_RAWIO? No improvement to see. On a new DVD+RW i do $ xorriso -for_backup -scsi_log on -dev /dev/sr1 -add /usr/include -- and still get FORMAT UNIT 04 11 00 00 00 00 To drive: 12b 00 02 00 08 ff ff ff ff 98 00 00 00 +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 +++ key=B asc=00h ascq=00h ( 484 ms) The same with an attempt to reformat an already formatted DVD+RW. $ xorriso -scsi_log on -dev /dev/sr1 -format full The same with a write run attempt onto a partially formatted DVD+RW. The FORMAT UNIT command is slightly different: FORMAT UNIT 04 11 00 00 00 00 To drive: 12b 00 02 00 08 ff ff ff ff 98 00 00 01 xorriso : UPDATE : Formatting. Working since 2 seconds +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 +++ key=B asc=00h ascq=00h ( 516 ms) The same with the attempt to format a sequential DVD-RW (details will be part of my next report installment about DVD-RW and DVD-R). qemu start command was: .../x86_64-softmmu/qemu-system-x86_64 \ -L .../pc-bios \ -enable-kvm \ -nographic \ -m 512 \ -net nic,model=ne2k_pci \ -net user,hostfwd=tcp::5557-:22 \ -hda /dvdbuffer/i386-install.qemu \ -drive file=/dev/sg2,if=scsi \ -cdrom /dvdbuffer/pseudo_drive - A passthrough device based on /dev/sr would increase superuser safety. Running as superuser appears to be quite dangerous in conjunction with Linux happiness to permutate /dev/sg numbers at boot time. I first started it with the /dev/sg of the hard disk by mistake. qemu was stuck at 100% CPU, and the host system did not react on shutdown -h. Had to press the hardware reset button. To my luck, it still booted afterwards. I now let cdrskin check the /dev/sg file before starting qemu. So hopefully this will not happen again. Nevertheless i would prefer to run qemu as normal user. - Have a nice day :) Thomas
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi, i completed my tests on DVD-RW (next will be DVD+R). Sequential DVD-RW can be written with write type Incremental (aka Packet) and be blanked. The write run commands of this DVD-RW profile 0x14 are the same as the ones for profile 0x11 DVD-R. So i boldly declare write success for both. Thoroughly formatted DVD-RW (profile 0x13) can be written. This state is achieved by formatting and writing data to all blocks (only possible on the host system for now). But i have failures with: - Write type DAO in sequential blank DVD-RW - Formatting sequential DVD-RW to overwritable profile 0x13 - Expanding of formatted area of a partially formatted DVD-RW - Inquiring blanking progress by REQUEST SENSE DVD-RW write type DAO makes the guest go stuck. qemu is on 100 % CPU after: MODE SELECT 55 10 00 00 00 00 00 00 3c 00 To drive: 60b 00 00 00 00 00 00 00 00 05 32 42 05 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0 ms READ TRACK INFORMATION 52 01 00 00 00 01 00 00 14 00 From drive: 20b 00 26 01 01 00 04 41 01 00 00 00 00 00 00 00 00 00 23 12 80 4 ms START/STOP UNIT 1b 01 00 00 01 00 1808 ms TEST UNIT READY 00 00 00 00 00 00 0 ms START/STOP UNIT 1b 00 00 00 01 00 qemu can be killed (no -9 necessary). The drive is accessible by the host system afterwards. qemu can be restarted and the drive can be used, without the need for rebooting the host. So it is not as bad as with CD SAO. The next command after the stuck START/STOP UNIT would have been RESERVE TRACK. I suspect that it happened although i did not see its log message, because the medium is in unhealthy state afterwards. It pretends to be blank with only 195 MB free and refuses on RESERVE TRACK. 195 MiB is about the expected size of the failed session. Writing to the medium in this state on the host system made the drive mad. The drive did not get ready after all data were written. After about 3 minutes it began to make lots of noise. Only reboot did help. After reboot it was possible to blank the medium, and to write a DAO session on the host system. The attempt to format a DVD-RW to profile 0x13 "Restricted Overwrite" fails: FORMAT UNIT 04 11 00 00 00 00 To drive: 12b 00 02 00 08 00 23 10 20 00 00 08 00 +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 +++ key=B asc=00h ascq=00h ( 488 ms) Formatted DVD-RW behave like DVD+RW, except their hard alignment constraints to full 32 kiB ECC blocks (this is the "restriction"). They usually have a longer life than sequential DVD-RW. This FORMAT UNIT command can be performed without special preparations. DVD-RW with profile 0x13 are fully formatted only after they were entirely overwritten with data. In this case, formatting has to be restarted before writing further data onto medium. As the other FORMAT UNIT commands, it fails: FORMAT UNIT 04 11 00 00 00 00 To drive: 12b 00 02 00 08 00 20 71 e0 4c 00 00 10 +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 +++ key=B asc=00h ascq=00h ( 544 ms) REQUEST SENSE does not behave as prescribed for blanking DVD-RW by BLANK a1 10 00 00 00 00 00 00 00 00 00 00 MMC-3 5.2 and MMC-5 6.2.3 state about processing of command BLANK with Immed bit set to one: "In response to the REQUEST SENSE command, unless an error has occurred, the Drive shall return a SK/ASC/ASCQ values set to NOT READY/LOGICAL UNIT NOT READY/OPERATION IN PROGRESS, with the sense key specific bytes set for progress indication." But libburn gets on qemu TEST UNIT READY 00 00 00 00 00 00 +++ sense data = 71 00 02 00 00 00 00 0A 00 00 00 00 04 08 00 80 24 8B +++ key=2 asc=04h ascq=08h ( 0 ms) REQUEST SENSE 03 00 00 00 12 00 From drive: 18b f0 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 00 0 ms It is ok that TEST UNIT READY reports the sense data with 2 04 08 LOGICAL UNIT NOT READY, LONG WRITE IN PROGRESS But it is not ok that REQUEST SENSE does not do the same. On qemu it reports: 0 00 00 NO ADDITIONAL SENSE INFORMATION This causes libburn's progress meter to show no progress, although i can see the two last bytes of the sense data counting upwards. (0= 0 % done , 65335 = 100 % done) On the host system, i see: TEST UNIT READY 00 00 00 00 00 00 +++ sense data = 71 00 02 00 00 00 00 0A 00 00 00 00 04 08 00 80 00 00 +++ key=2 asc=04h ascq=08h ( 4 ms) REQUEST SENSE 03 00 00 00 12 00 From drive: 18b 70 00 02 00 00 00 00 0a 00 00 00 00 04 08 00 80 00 00 0 ms ... REQUEST SENSE 03 00 00 00 12 00 F
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi, > > [REQUEST SENSE while blanking] > > MMC-3 5.2 and MMC-5 6.2.3 > Is this git master or 0.15? It is a git clone obtained on November 2 by git clone git://git.qemu.org/qemu.git I see a file VERSION with date Nov 2 13:41 (+0100) $ cat VERSION 0.15.90 $ git describe fatal: No annotated tags can describe 'e072ea2fd8fdceef64159b9596d3c15ce01bea91'. However, there were unannotated tags: try --tags. $ git describe --tags v1.0-rc0 Should i run git pull git://git.qemu.org/qemu.git ? (My clone is still slightly altered. Will this be a problem ?) > This is because QEMU always emulates REQUEST SENSE and always returns the > sense data from the last request. Is this realistic enough for passthrough ? Shouldn't qemu forward all SCSI commands to the host operating system in this case ? > REQUEST SENSE would be used if > SG_IO reports CHECK CONDITION without SG_ERR_DRIVER_SENSE (but modern OSes > will always emulate autosense even if the HBA does not support it) and > possibly if TEST UNIT READY returns GOOD which is allowed by deprecated in > MMC. Up to now it appeared better to use the explicitely prescribed method with REQUEST SENSE. It is not a showstopper anyway. Just a little beauty flaw. There are also some drives which do not report proper progress. I have this topic on my todo list, together with a more graceful handling if SET STREAMING fails. Currently i am at the item - Test all libburn write models of CD, DVD, and BD. Write a summary of all results. I plan to check DVD+R tonight. BD-R and BD-RE tomorrow. Have a nice day :) Thomas
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi, now for DVD+R burning. It works well if i avoid command RESERVE TRACK. RESERVE TRACK shows similar effects as the failed DVD-RW DAO run, resp. the failed CD SAO run: qemu gets stuck at 100 % CPU. No failed ioctl is indicated by my printfs. Details: As with all DVD types, READ DISC STRUCTURE formats 0x04 and 0x11 block until timeout. I disable them for these tests. Blank DVD+R $ xorriso -for_backup -scsi_log on -dev /dev/sr1 -add /usr/include -- makes the guest system block 11 seconds after RESERVE TRACK 53 00 00 00 00 00 00 0f 30 00 CPU 100 % , no life in SSH sessions. After killing qemu, the drive is usable from the host system. A track is reserved, no data were written. I could write another track to it, by avoiding RESERVE TRACK. But now libburn is lost in the woods. It wanted to close the session, but the first empty track causes this to fail. I will later have to try to write and close the first track. For now the medium is spoiled. New DVD+R. This time no RESERVE TRACK. For that i have to avoid that xorriso learns the size of the session in advance. Thus the cdrtools usage model: $ xorriso -as mkisofs -graft-points /usr/include=/usr/include \ --for_backup \ | xorriso -as cdrecord dev=/dev/sr1 -v -V -waiti -multi - This yields a readable track. I get a credible table-of-content. MD5 sums of files match correctly. Another session can be added cdrtools style. All is well. Table-of-content is readable, MD5 sums match. I add a third session, and order the medium to be closed, by omitting cdrecord option -multi. Works well. Passes all read checks. --- Since BD-R are very similar to DVD+R, but much more expensive, i will tomorrow only test the case without RESERVE TRACK. Have a nice day :) Thomas
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi, i wanted to test Blu-ray burning and attached a BD recorder via USB to the host. Its power was switched on, before i booted the host. The host can operate this drive. But the qemu guest obviously has severe problems with it. There is a 'QEMU DVD-ROM' at /dev/sr0. There is also a /dev/sr1, which does not show up in the udev file /etc/udev/rules.d/70-persistent-cd.rules which usually reacts on new drives. Neither the superuser (nor the normal user after chmod a+rw) can operate /dev/sr1. xorriso gets INQUIRY 12 00 00 00 24 00 +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 06 00 00 00 00 +++ key=B asc=00h ascq=06h ( 30992 ms) and my qemu printf reports posix-aio-compat.c: handle_aiocb_ioctl: ioctl(12, 0x2285, ), ret= -1 , errno= 19 That's ENODEV /* No such device */. Note well, that for having a failing iotcl() i first had to open the device file successfully. So "No such device" is probably related to an unprovoked re-attaching of the drive which i found in the host system log. (See below.) -- When i shutdown the guest system, the host got a kernel Oops. All my SSH sessions on the host are frozen. Except a session which ran top, they all display: Message from syslogd@debian2 at Nov 6 08:47:42 ... kernel:[ 1961.576375] Oops: [#1] SMP Message from syslogd@debian2 at Nov 6 08:47:42 ... kernel:[ 1961.576382] last sysfs file: /sys/devices/pci:00/:00:12.0/usb3/3-3/3-3:1.0/host9/target9:0:0/9:0:0:0/block/sr2/removable Message from syslogd@debian2 at Nov 6 08:47:42 ... kernel:[ 1961.576598] Stack: Message from syslogd@debian2 at Nov 6 08:47:42 ... kernel:[ 1961.576630] Call Trace: Message from syslogd@debian2 at Nov 6 08:47:42 ... kernel:[ 1961.576748] Code: 48 8b 47 18 48 8b 00 48 8b 40 60 48 85 c0 74 06 49 89 c3 41 ff e3 48 c7 86 a0 00 00 00 00 00 00 00 31 c0 c3 48 8b 47 18 48 8b 00 <48> 8b 40 68 48 85 c0 74 09 48 89 f7 49 89 c3 41 ff e3 c3 48 8b Message from syslogd@debian2 at Nov 6 08:47:42 ... kernel:[ 1961.576824] CR2: 0068 Funnily the graphical login screen of the host did still react on the keyboard but froze after i entered the desktop user password. I had to press the hardware reset button. The qemu start command is the same as with the previous successful runs. Only the /dev/sg address differs. I double checked before starting qemu, it is the right /dev/sg for the drive. .../x86_64-softmmu/qemu-system-x86_64 \ -L .../qemu-git/pc-bios \ -enable-kvm \ -nographic \ -m 512 \ -net nic,model=ne2k_pci \ -net user,hostfwd=tcp::5557-:22 \ -hda /dvdbuffer/i386-install.qemu \ -drive file=/dev/sg3,if=scsi \ -cdrom /dvdbuffer/pseudo_drive qemu was started by a normal user, not by the superuser. The drive is an 'Optiarc' 'BD RW BD-5300S' revision '1.04' attached via SATA to an USB box "Delock 5.25 inch enclosure eSATA/USB". Nov 6 08:15:06 debian2 kernel: [1.294442] usb 1-3: Product: JM20336 SATA, USB Combo Nov 6 08:15:06 debian2 kernel: [1.29] usb 1-3: Manufacturer: JMicron Nov 6 08:15:06 debian2 kernel: [1.294445] usb 1-3: SerialNumber: 306663601043 The drive attachment messages first talk of "8:0:0:0" Nov 6 08:15:06 debian2 kernel: [6.301719] scsi 8:0:0:0: CD-ROM Optiarc BD RW BD-5300S 1.04 PQ: 0 ANSI: 0 Nov 6 08:15:06 debian2 kernel: [6.310686] sr2: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray Nov 6 08:15:06 debian2 kernel: [6.310868] sr 8:0:0:0: Attached scsi generic sg3 type 5 and later of "9:0:0:0" after a disconnect which i cannot relate to a physical event on bus or power supply: Nov 6 08:35:31 debian2 kernel: [ 1232.103847] usb 1-3: USB disconnect, address 3 Nov 6 08:35:31 debian2 kernel: [ 1232.111661] sg_rq_end_io: device detached Nov 6 08:35:32 debian2 kernel: [ 1233.480103] usb 1-3: new high speed USB device using ehci_hcd and address 5 Nov 6 08:35:33 debian2 kernel: [ 1233.976106] usb 3-3: new full speed USB device using ohci_hcd and address 3 Nov 6 08:35:33 debian2 kernel: [ 1234.135535] usb 3-3: not running at top speed; connect to a high speed hub Nov 6 08:35:33 debian2 kernel: [ 1234.147516] usb 3-3: New USB device found, idVendor=152d, idProduct=2336 Nov 6 08:35:33 debian2 kernel: [ 1234.147525] usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=5 Nov 6 08:35:33 debian2 kernel: [ 1234.147531] usb 3-3: Product: JM20336 SATA, USB Combo Nov 6 08:35:33 debian2 kernel: [ 1234.147536] usb 3-3: Manufacturer: JMicron Nov 6 08:35:33 debian2 kernel: [ 1234.147540] usb 3-3: SerialNumber: 306663601043 Nov 6 08:35:33 debian2 kernel: [ 1234.147752] usb 3-3: configuration #1 chosen
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi, Paolo Bonzini wrote: > It would be more interesting if you tried again the failure cases with a > virtio drive (if=virtio). It would appear as /dev/vda but you can issue > SG_IO to it. This would isolate the failure to the kernels vs. the SCSI > subsystem. Will do. I am currently fighting with eSATA and may have to give up the planned Blu-ray tests, after USB already failed so dramatically. The external drive does not work properly with 3.0 Gbps. This is a known shortcomming of my test machine's eSATA cabling or of the eSATA box (i only have one of either kind, so i cannot cross-check). Interesting insight: The failure at 3.0 Gbps throws on the host the same sense code as FORMAT UNIT does on the guest with the internal SATA drive, which runs at 1.5 Gbps by miracle. Sense Key B "Command aborted", ASC 00 ASCQ 00 So the sense code with FORMAT UNIT might stem from the host kernel and not from qemu. Other than Debian 5 the newer Debian 6 kernel 2.6.32-5-amd64 does not reset to 1.5 Gps after the first transport failure. Nov 6 10:59:55 debian2 kernel: [ 2025.849176] ata5: hard resetting link Nov 6 10:59:56 debian2 kernel: [ 2026.780105] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300) I dimly remember that i'd need to patch initrd to get the kernel module option into effect at an early boot stage. I haven't done this since two years and this could possibly change the whole test setup. Better would be to know, why the internal SATA drive is started with 1.5 Gbps at boot time Nov 6 10:26:15 debian2 kernel: [1.241546] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Nov 6 10:26:15 debian2 kernel: [1.242406] ata3.00: ATAPI: TSSTcorp CDDVDW SH-S223B, SB02, max UDMA/100 In contrast to the eSATA attached drive Nov 6 10:26:15 debian2 kernel: [1.688050] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Nov 6 10:26:15 debian2 kernel: [1.693623] ata5.00: ATAPI: Optiarc BD RW BD-5300S, 1.04, max UDMA/100 On Debian 5, the internal drive was run with 3.0 Gbps and worked fine. Miracles of system administration ... Have a nice day :) Thomas
[Qemu-devel] Summary of CD, DVD passthrough tests with -drive if=scsi
Hi, since i had to give up the plan to test BD burning, i now post the first summary of passthrough testing on base of if=scsi . Next i will try to follow Paolo Bonzini's proposal to use if=virtio. - List of successes and failures with various CD and DVD use cases on an internal SATA drive at host Debian 6.0.2 Linux ... 2.6.32-5-amd64 #1 SMP Tue Jun 14 09:42:28 UTC 2011 x86_64 with guest Debian 6.0.3 Linux ... 2.6.32-5-686 #1 SMP Mon Oct 3 04:15:24 UTC 2011 i686 qemu source is a git clone obtained on November 2 by git clone git://git.qemu.org/qemu.git File VERSION has date Nov 2 13:41 (+0100) $ cat VERSION 0.15.90 $ git describe fatal: No annotated tags can describe 'e072ea2fd8fdceef64159b9596d3c15ce01bea91'. However, there were unannotated tags: try --tags. $ git describe --tags v1.0-rc0 qemu start: .../x86_64-softmmu/qemu-system-x86_64 \ -L .../pc-bios \ -enable-kvm \ -nographic \ -m 512 \ -net nic,model=ne2k_pci \ -net user,hostfwd=tcp::5557-:22 \ -hda /dvdbuffer/i386-install.qemu \ -drive file=/dev/sg2,if=scsi \ -cdrom /dvdbuffer/pseudo_drive - Successes: All media types Tray loading and ejecting. CD-RW (and most probably CD-R) Writing a session with a single track with write type TAO. As first session and as add-on session. DVD+RW Writing if SET STREAMING is omitted. DVD-RW (and most probably DVD-R) Write type Incremental (aka Packet) if SET STREAMING is omitted. Blanking. Writing to thoroughly formatted DVD-RW if SET STREAMING is omitted. DVD+R Writing sessions without using RESERVE TRACK, if SET STREAMING is omitted. Closing of medium. - Failures: I count and classify them by these poetic category names: 1 HOST CRASHER kernel Oops and crash of the host system 2 DRIVE FREEZER makes the drive unusable on the host until host reboot 4 GUEST KILLER makes guest freeze or qemu abort 1 MEDIUM KILLER makes medium unusable (at least for current libburn) 2 SHOWSTOPPERprevents usage of drive or medium 2 ANNOYING severely hampers usage of medium 1 UGLY deprives user of less important information USB attached drive * HOST CRASHER * SHOWSTOPPER An USB attached drive does not perform any SCSI command, qemu ioctl() gets "No such device", host gets kernel Oops when guest is shut down, host shell sessions are frozen until hardware reset button. CD-RW (and most probably CD-R) * DRIVE FREEZER * GUEST KILLER Writing a first session to blank media with write type SAO. The guest freezes. The drive gets unusable by the host system until host reboot. SEND CUE SHEET 5d 00 00 00 00 00 00 00 20 00 To drive: 32b 41 00 00 01 00 00 00 00 41 01 00 10 00 00 00 00 41 01 01 10 00 00 02 00 41 aa 01 01 00 00 35 30 DVD in general * DRIVE FREEZER * GUEST KILLER Guest freezes, qemu goes to 100% CPU, after 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 drive is unusable by the host afterwards * ANNOYING Guest SG_IO timeout with READ DISC STRUCTURE formats 0x04 , 0x11 , 0x0e , 0x10. READ DISC STRUCTURE ad 00 00 00 00 00 00 04 00 04 00 00 READ DISC STRUCTURE ad 00 00 00 00 00 00 11 00 04 00 00 READ DISC STRUCTURE ad 00 00 00 00 00 00 0e 00 04 00 00 READ DISC STRUCTURE ad 00 00 00 00 00 00 10 00 04 00 00 DVD+RW * SHOWSTOPPER Failure to write to unformatted or partly formatted DVD+RW. FORMAT UNIT 04 11 00 00 00 00 To drive: 12b 00 02 00 08 ff ff ff ff 98 00 00 00 +++ sense data = F0 00 0B 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 +++ key=B asc=00h ascq=00h ( 488 ms) DVD-RW * GUEST KILLER Guest freezes with DVD-RW write type DAO. qemu is on 100 % CPU. Most probably after RESERVE TRACK, although this command is not shown by the SCSI log. But the command before it is shown and the medium has inconsistent knowledge of the desired track size. * ANNOYING Failure to format sequential DVD-RW, and to write to partially formatted DVD-RW. * UGLY Failure to deliver progress of Blanking DVD-RW via REQUEST SENSE. REQUEST SENSE 03 00 00 00 12 00 From drive: 18b f0 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 00 0 ms TEST UNIT READY delivers the desired information. DVD+R * GUEST KILLER * MEDIUM KILLER Guest freezes, medium has unwritten open reserved track after RESERVE TRACK 53 0
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi, i have finished CD and DVD tests with drive file=/dev/sg2,if=virtio -cdrom /dvdbuffer/pseudo_drive There is substantial improvement towards if=scsi. Actually everything works like a charm now. :)) It did not work for libburn out of the box, but i could work around most of the obstacles. Only remaining obstacle for normal usage: How to use the drive as block device for reading ? /dev/vda behaves like /dev/sg, not like /dev/sr. $ cat /dev/vda | wc 0 0 0 (xorriso has no problem to read the media, because it does its entire drive i/o via libburn's MMC capabilities.) I did not retry the USB drive. Will do tomorrow. All SCSI commands, which get used with BD-R and BD-RE, should be already tested now, nevertheless. BD-R are much like DVD+R, BD-RE resemble DVD+RW. Following is a preliminary summary of successes, an observation about SSH reactivity, a proposal to curb file=/dev/sg*,if=scsi, and a report about my workarounds to talk libburn into using /dev/vda. --- Success with formerly successful use cases: All media types Tray loading and ejecting. CD-RW (and most probably CD-R) Writing a session with a single track with write type TAO. As first session and as add-on session. DVD+RW Writing to thoroughly formatted DVD+RW. DVD-RW (and most probably DVD-R) Writing with write type Incremental (aka Packet), multiple sessions. Blanking. Writing to thoroughly formatted DVD-RW. DVD+R Writing sessions without using RESERVE TRACK. Closing of medium. --- Success with formerly failing or partially failing use cases: CD-RW (and most probably CD-R) Burning a CD SAO session Was: * DRIVE FREEZER, GUEST KILLER Writing a first session to blank media with write type SAO. The guest freezes. The drive gets unusable by the host system until host reboot. Offending command: SEND CUE SHEET DVD in general Telling the drive the desired DVD write speed with DVD+RW, DVD-RW (and most probably DVD-R), DVD+R Was: * DRIVE FREEZER, GUEST KILLER Guest freezes, qemu goes to 100% CPU, after SET STREAMING Media inquiry without blocking out any READ DISC STRUCTURE command. Was: * ANNOYING Guest SG_IO timeout with READ DISC STRUCTURE formats 0x04 , 0x11 , 0x0e , 0x10. DVD+RW Writing to partly formatted DVD+RW and new unformatted DVD+RW. Was: SHOWSTOPPER Failure to write to unformatted or partly formatted DVD+RW. Offending command: FORMAT UNIT DVD-RW Writing with write type DAO to blank sequential DVD-RW. Was: * GUEST KILLER Guest freezes with DVD-RW write type DAO. qemu is on 100 % CPU. Most probably after RESERVE TRACK, although this command is not shown by the SCSI log. But the command before it is shown and the medium has inconsistent knowledge of the desired track size. Formatting DVD-RW from sequential profile 0x14 to overwritable profile 0x13. Was: * ANNOYING Failure to format sequential DVD-RW, and to write to partially formatted DVD-RW. libburn shows progress with asynchronous BLANK and FORMAT UNIT. Was: * UGLY Failure to deliver progress of Blanking DVD-RW via REQUEST SENSE. DVD+R Writing a DVD+R session with RESERVE TRACK Was: * GUEST KILLER MEDIUM KILLER Guest freezes, medium has unwritten open reserved track after RESERVE TRACK --- Success with use cases not yet tried with if=scsi : CD-RW Blanking in mode fast. Closing CD-RW after writing a TAO session. DVD-RW (and most probably DVD-R) Closing DVD-RW after an Incremental session. - Observation: Now that everything works so well, i try multi-tasking. It appears that the SSH session is hampered for the time when longer SCSI transactions are waiting for the drive reply. E.g. when TEST UNIT READY needs 1600 milliseconds to tell that the drive is not ready. At the same time, the input line of another SSH session does not swiftly echo my toggling. It is not completely dead, but very slow. E.g. i get two single characters with two feelable delays and then all is normal again. I believe this is also the reason why i did not see the log message of the RESERVE track of the failed DAO run on if=scsi. - Proposal: As long as file=/dev/sg*,if=scsi is such a mine field, one should consider to disable it with CD-ish drives unless a special option is given at qemu start. --- Obstacles and worka
Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Hi, > >drive file=/dev/sg2,if=virtio -cdrom /dvdbuffer/pseudo_drive > > Actually everything works like a charm now. :)) > Cool. So you might have unveiled some kernel bugs too (host crashes are > never desirable!) The USB drive is back at the test machine. I'm running the planned BD-RE tests on the host system to ensure that they work properly without qemu inbetween. Next i will try with if=virtio. Some questions: --- In a thread on linux-hotplug, /dev/sg* is declared to be deprecated in favor of /dev/bsg/* and /dev/sr*. Will this become a problem ? --- I did not succeed with googling for a way to get a block device running on top of file=/dev/sg*,if=virtio. Is this possible at all ? If so, can you give me instructions ? (It would be the cream cap on the cake.) --- The word "passthrough" does not show up in the context of drive emulation in any documentation inside the git clone. I only see statements about: "passthrough" security model. The word "virtio" is mentioned more often, but without much explanation of -drive use cases and pitfalls. (Only docs/qdev-device-use.txt has some more detailed information.) Is there an external documentation emerging ? I would like to read it and contribute my experiences. --- Have a nice day :) Thomas
Re: [Qemu-devel] Summary of CD, DVD passthrough tests with -drive if=scsi
Hi, Markus Armbruster wrote: > Has anyone thought of keeping your tests around for regression testing > purposes? The full tour lasts a whole workday and needs human attention. I still did not come to test the newest proposals of Paolo Bonzini and Zhi Yong Wu, because the last BD-R test was finished just five minutes ago. (I'm not working full-time on it but i have to attend it every half hour or so.) Now i do a last verification read run, to make sure that all went well. It comes to me that i forgot to test DVD-RAM. Thanks heaven that HD DVD-R never made it to the real-life market. For unattended tests i would propose to develop some dry exercises, which perform SCSI commands of all three payload direction classes: from_drive, to_drive, no_payload. The test machine would need a real burner drive with e.g. a blank CD-RW loaded, so that e.g. mode pages can be sent and read. Depending on the individual drive, it might even work with an empty drive. Sending a mode page 5 for write preparation is supposed to be harmless. One could announce to the drive a CD SAO run, read it back, announce a TAO run, read it back, and then just close the file descriptor to the drive. One could try to read from empty medium or drive and watch out for the sense code that should come as protest. This would not detect failures like of if=scsi with FORMAT UNIT or SET STREAMING. But those would need real burn runs to show up. For the next round of burn tests i will make a shorter cross section through the media zoo, with re-usable media only. (The BD-R contains a backup of about all interesting files of the host system and of the guest. It is now closed. 7738 MiB payload, 15 GiB wasted.) I will record the options of all xorriso test runs. But before this can be reproduced by other testers i will have to work on libburn, so that one does not need an udev hack to get the /dev/vda drive accepted as CD device. The next release will hopefully happen in a few weeks and be able to work in the guest system out of the box. GNU/Linux, FreeBSD, Solaris are supported on real systems, currently. (Can FreeBSD and Solaris use virtio drives ?) I am open to proposals of other systems which can make use of the qemu device setup, that works for Linux guests. Mainly i would need info about possible drive addresses and how to perform SCSI transactions from userspace. And help with installing the guest system, of course. Have a nice day :) Thomas
Re: [Qemu-devel] Summary of CD, DVD passthrough tests with -drive if=scsi
Hi, Paolo Bonzini wrote: > Yes, docs/qdev-device-use.txt helps. "qemu -device virtio-blk,?" too. I read it and ran '-device ?'. But both left me clueless. The text i understood mainly as refering to "old ways" and "new way" of defining devices. I stalled when i found no flesh for "HOST-OPTS" and "DEV-OPTS". man ./qemu.1 lists options of -devices, but it did not lead me to "virtio-blk" as driver name. Do i get it right that e.g. virtio-blk-pci.scsi=on/off means there is an option -device virtio-blk,scsi=on But how would i come from there to your proposal ? -device virtio-blk,drive=scsicd,logical_block_size=2048,physical_block_size=2048 Not nagging, just pointing out the problems of a noob. To my luck, you are a very friendly tutor. Else i would have failed early. i wrote: > > Can FreeBSD and Solaris use virtio drives ? Paolo Bonzini wrote: > Perhaps, but probably not with SG_IO so that's a "no" for your use case. You mean SG_IO on the host system ? On the guest, libburn would use CAM resp. uscsi. I tried to learn about the overall concept of virtio but mostly find prescriptions how to use it. How much similarity between host and guest is needed ? Actually i came to qemu because on the long term i want to see GNU xorriso burn a DVD on GNU/Hurd. Just for fulfilling my duty as GNU maintainer. (Not that anybody else would find this to be a reasonable idea ... :)) But i understand that GNU/Hurd will not offer the guest support for virtio. So i will have to resort to -cdrom for development and an old PC for burn testing, if ever an RPC for userspace SCSI transactions gets approved. (Inside gnumach, there sit transaction calls for ATAPI and SCSI. But there is no way to use them directly from Hurd.) Have a nice day :) Thomas
[Qemu-devel] Summary of CD, DVD, BD passthrough tests with -drive if=virtio : Full success
Hi, here are test results from the USB attached BD recorder. It is a SATA drive 'Optiarc' 'BD RW BD-5300S' rev '1.04' at a 'JMicron' 'JM20336 SATA, USB Combo' controller. -- qemu start command is the same as with the internal SATA drive and my previous if=virtio tests x86_64-softmmu/qemu-system-x86_64 \ -L .../pc-bios \ -enable-kvm \ -nographic \ -m 512 \ -net nic,model=ne2k_pci \ -net user,hostfwd=tcp::5557-:22 \ -hda /dvdbuffer/i386-install.qemu \ -drive file=/dev/sg3,if=virtio \ -cdrom /dvdbuffer/pseudo_drive -- BD-RE The drive gets listed by xorriso option -devices (for libburn internal reasons it needs a softlink pointing from /dev/sr1 to /dev/vda). Media inquiry works fine. (Disc is a VERBATIM/IM0/0.) Reading of ISO 9660 filesytem works fine (via READ(10), not via read()). MD5s of content (from host tests) match. Writing with WRITE(10) and Defect Management works fine. Writing with WRITE(12) and Streaming bit (i.e. no Defect Management) works fine and at full nominal medium speed. Listing of available format descriptors works fine. Re-formatting works fine (with progress report by REQUEST SENSE). BD-R Media inquiry of blank medium works fine. (Disc is a VERBATIM/IMw/0, an LTH medium, not suitable for older BD drives.) Formatting works fine. (Drive reports no progress with TEST UNIT READY or REQUEST SENSE. Both commands indicate that the drive is busy. So this is a shortcomming of the drive and not of qemu.) Media inquiry of formatted medium works fine. Writing with WRITE(10) and Defect Management works fine. Writing with WRITE(12) and Streaming bit (i.e. no Defect Management) works fine and at full nominal medium speed. Reading of ISO 9660 filesytem works fine. MD5s match. (I do not test with unformatted BD-R, because there is no difference in the SCSI commands used for writing.) Closing after writing a final session works fine. Now for the most mediocre member of the DVD family: DVD-RAM (I really did find one that still works) Reading of old content works fine. Writing an ISO 9960 session works with WRITE(12) and Streaming bit as good as DVD-RAM can do. One file MD5 sum did not match. (So even this read test was challenged and tested.) Writing an ISO 9960 session works with WRITE(10) and Defect Management. Re-formatting works fine (with progress report by REQUEST SENSE). --- I repeat a consolidated summary of my successful tests with other media types with above qemu start command. DVD recorder was 'TSSTcorp' 'CDDVDW SH-S223B' rev SB02'. No test really failed. Some aspects of qemu virtio drives surprised my libburn and will have to be addressed in the next realeases of libburn and GNU xorriso. --- All media types Tray loading and ejecting. CD-RW (and most probably CD-R) Writing a session with a single track with write type TAO. As first session and as add-on session. Burning a CD SAO session to blank medium. Blanking in mode fast. Closing CD-RW after writing a TAO session. DVD in general Telling the drive the desired DVD write speed by SET STREAMING. DVD+RW Writing to thoroughly formatted DVD+RW. Writing to partly formatted DVD+RW and new unformatted DVD+RW. (With background formatting.) DVD-RW (and most probably DVD-R) Blanking. Writing with write type DAO to blank sequential DVD-RW. Writing with write type Incremental (aka Packet), multiple sessions. Closing sequential DVD-RW after an Incremental session. Formatting DVD-RW from sequential profile 0x14 to overwritable profile 0x13. Writing to partly formatted and to thoroughly formatted DVD-RW. DVD+R Writing sessions without using RESERVE TRACK. Writing sessions with RESERVE TRACK. Closing of medium. Tomorrow i plan to test Paolo Bonzini's proposal -drive file=/dev/sr0,if=none,id=scsicd -device virtio-blk,drive=scsicd,logical_block_size=2048,physical_block_size=2048 with some of the re-usable media types. Have a nice day :) Thomas
[Qemu-devel] Summary of CD, DVD, BD passthrough tests with -drive if=none -device virtio-blk
Hi,
the test results on CD-RW, DVD-RW, DVD+RW, BD-RE are flawless with
Paolo Bonzini's most recent proposal
-drive file=/dev/sr2,if=none,id=scsicd
-device
virtio-blk,drive=scsicd,logical_block_size=2048,physical_block_size=2048
libburn works fine via SG_IO. dd and other unaware readers work fine.
Chances are good that growisofs, cdrecord, and wodim will work fine, too.
--
But i want to strongly suggest to open the host drive with option O_EXCL,
which has a fewly documented meaning as advisory locking mechanism
(at least with /dev/sg and /dev/sr).
It is used to indicate that the device is mounted, burn programs
use it to indicate that the drive is occupied. Both meanings are
not 100 % compatible, but the best we can get to avoid burn
burn coasters or problems with vanishing data on mounted read-only
filesystems.
Symptoms:
xorriso on the host should not list /dev/sr2, but does it.
It would be able to interfere with the guest xorriso.
Not good. Would spoil CD and DVD- burn runs.
My spy printf say in the qemu start terminal:
block/raw-posix.c: cdrom_open("/dev/sr2", 0)
block/raw-posix.c: raw_open_common("/dev/sr2", 1800)
block/raw-posix.c: cdrom_open("/dev/sr2", 2)
block/raw-posix.c: raw_open_common("/dev/sr2", 1802)
/usr/include/bits/fcntl.h has
#define O_EXCL 0200
(What flag is 0x800, btw ?)
--
qemu start command (still the git clone of 2 November 2011) :
.../x86_64-softmmu/qemu-system-x86_64 \
-L .../qemu-git/pc-bios \
-enable-kvm \
-nographic \
-m 512 \
-net nic,model=ne2k_pci \
-net user,hostfwd=tcp::5557-:22 \
-hda /dvdbuffer/i386-install.qemu \
-drive file=/dev/sr2,if=none,id=scsicd \
-device
virtio-blk,drive=scsicd,logical_block_size=2048,physical_block_size=2048 \
-cdrom /dvdbuffer/pseudo_drive
Host system is Debian GNU/Linux 6.0.2 amd64.
--
Preparations on guest system Debian GNU/Linux 6.0.3 i386
In /lib/udev/rules.d/50-udev-default.rules:
KERNEL=="vda", SYMLINK+="sr1"
In /lib/udev/rules.d/91-permissions.rules:
KERNEL=="vda", GROUP="cdrom"
This yields
lrwxrwxrwx 1 root root 3 Nov 8 11:19 /dev/sr1 -> vda
brw-rw 1 root cdrom 254, 0 Nov 8 11:19 /dev/vda
which allows me to run the tests as normal user in group cdrom.
--
During the tests i wrote a description how to set them up and to perform
them.
It turned out that about 25 lines concern qemu, 20 concern the Debian guest,
and 400 lines concern xorriso and its expected behavior.
So it makes more sense to create a qemu related page in the wiki of
the libburnia project, rather than to submit it to qemu.
I will publish that text as soon as a GNU xorriso development tarball
is available which works on qemu without the need for a micro hack
in libbur/sg-linux.c
- static int linux_sg_accept_any_type = 0;
+ static int linux_sg_accept_any_type = 1;
This hacklet is not without dangers. I actually need to tell CD drives
from other device types.
I will post its URL on this list when it is available.
--
Have a nice day :)
Re: [Qemu-devel] Summary of CD, DVD, BD passthrough tests with -drive if=none -device virtio-blk
Hi,
i am now testing a hack that adds O_EXCL to the call of qemu_open()
in block/raw-posix.c. Just as proof-of-concept.
This is Linux-host-specific, of course.
---
As first i learned to distinguish between octal and hex. :))
So my question "(What flag is 0x800, btw ?)" is obsolete.
---
During the O_EXCL test i was bitten by a little pitfall of
the proposed virtual device setup. It happens with the well
tested version of my git clone, too.
If there is no medium inside, then qemu start-up fails with
qemu-system-x86_64: -device
virtio-blk-pci,drive=scsicd,logical_block_size=2048,physical_block_size=2048:
Device needs media, but drive is empty
qemu-system-x86_64: -device
virtio-blk-pci,drive=scsicd,logical_block_size=2048,physical_block_size=2048:
Device 'virtio-blk-pci' could not be initialized
If there is a blank DVD-RW medium loaded. i get:
qemu-system-x86_64: -drive file=/dev/sr2,if=none,id=scsicd: could not open
disk image /dev/sr2: Input/output error
Would it be possible to make qemu more tolerant here ?
(For a better error message, one would would have to inquire the medium.
READ DISC INFORMATION, Disc Status 00b "Empty" means blank medium,
MMC-1 table 131, MMC-3 table 163.
No medium would be indicated by sense code 2 3A xx MEDIUM NOT PRESENT.)
---
I am worrying now about my happy ejecting and changing of media, while
qemu has open the same device descriptor all the time.
Is this sane for the host system resp. for qemu ?
If above initialization of 'virtio-blk-pci' is needed, then wouldn't
it be needed after each media change ?
There are no visible bad effects, though.
---
For O_EXCL tests:
The start terminal now says
block/raw-posix.c: raw_open_common("/dev/sr2", 0x1800)
block/raw-posix.c: raw_open_common("/dev/sr2", 0x1802)
block/raw-posix.c: /dev/sr O_EXCL test : s->open_flags is now 0x1882
I added O_EXCL only to the open call with O_RDWR, because this combination
is known to work on older Linux kernels, where O_RDONLY sometimes ignores
the extra meaning of O_EXCL. (Which is not described in man 2 open.)
In any case one has to avoid to use O_EXCLi on that device, while there
is still another own open O_EXCL file descriptor for the device.
Else self-denial.
One could re-try without O_EXCL after a failure. That would still be
more protection than there is now. libburn and wodim wait a second and
retry with O_EXCL, because there is sometimes a delay with unlocking.
---
On the host system, xorriso now reports as i wish
libburn : SORRY : Cannot open busy device '/dev/sr2' : Device or resource busy
0 -dev '/dev/sr0' rwrw-- : 'TSSTcorp' 'DVD-ROM SH-D162C'
1 -dev '/dev/sr1' rwrw-- : 'TSSTcorp' 'CDDVDW SH-S223B'
I made a quick tour through my emerging qemu test wiki page with DVD-RW.
It all looks as good as before.
If there is a further opening call with O_RDWR, then it does not happen
with my setup, my use cases, and my hack in raw_open_common():
+ if (strncmp(filename, "/dev/sr", 7) == 0 && (s->open_flags & O_RDWR)) {
+ s->open_flags |= O_EXCL;
+ printf("block/raw-posix.c: /dev/sr O_EXCL test : s->open_flags is now
0x%x\n", s->open_flags);
+ }
+
s->fd = -1;
fd = qemu_open(filename, s->open_flags, 0644);
---
Have a nice day :)
Thomas
Re: [Qemu-devel] Summary of CD, DVD passthrough tests with -drive if=scsi
Hi, i reported nastily bahaving SCSI commands SEND CUE SHEET, SET STREAMING, FORMAT UNIT, READ DISC STRUCTURE, REQUEST SENSE , RESERVE TRACK. This was with -drive file=/dev/sg2,if=scsi Paolo Bonzini wrote: > I fixed all of these; [...] > The bugs were simply that QEMU did not compute the length of the command > payload correctly. > [...] will send patches tomorrow. Plus instructions for me, please, when and how to update my git clone. :) I will then test by my new xorriso-on-qemu wiki http://libburnia-project.org/wiki/QemuXorriso The development tarball of GNU xorriso is now supposed to work on a GNU/Linux guest with /dev/vda. The wiki describes guest preparations for Debian GNU/Linux 6. With other distros, one might have to do different things to get a /dev/sr1 and rw-permissions to /dev/vda. Well, -drive if=scsi will produce a /dev/sr automatically. (Note to myself: disable udev hack before if=scsi test.) Have a nice day :) Thomas
[Qemu-devel] [PATCH 0/5] scsi/atapi: MMC fixes
Hi, > I only tested CD-RW DAO burning of an ISO image, plus invoking a bunch > of commands from Thomas's logs). The burning succeeded but reading > the resulting medium failed consistently at 26 MB. However, the same > happened even when doing CD passthrough via virtio, so it may be due to > a different bug. Did you get a sense code from the failure ? My best guess would be that you announced 26 MB by the SEND CUE SHEET command. Proposals for inspection of CD medium structure on real Linux: wodim -v dev=/dev/sr0 -toc cdrecord -v dev=/dev/sr0 -minfo cdrskin -v dev=/dev/sr0 -minfo xorriso -outdev /dev/sr0 -toc SCSI command logs are available by -V resp. -scsi_log on. > Also detect blanking of a disc and reset the maximum LBA. It's possible > that more special casing is necessary, e.g. for track-at-once, since > those do not start with blanking. I did not explore GET EVENT STATUS NOTIFICATION yet, which might address this issue. Some scenarios: Writing CD TAO or Packet, Incremental Streaming on DVD-R[W], or writing on DVD+R and BD-R without RESERVE TRACK, will cause the new readable size to be determined only after CLOSE TRACK SESSION. SEND CUE SHEET resp. RESERVE TRACK determine the size before writing begins. DVD-RAM and BD-RE can change their formatted size by FORMAT UNIT. In this case, the new size is determined as soon as TEST UNIT READY resp. REQUEST SENSE deliver no sense data any more. If the Immed Bit in the Format List Header of FORMAT UNIT is not set, then the size is already determined when FORMAT UNIT returns. I never worked with formatted CD-RW. But i assume that FORMAT UNIT has a similar effect on size as with DVD-RAM. DVD+RW and formatted DVD-RW can grow their formatted size during writing. This is started by FORMAT UNIT but the size is decided only when writing ends. This end is not unambigously to detect. One may at any time continue writing as long as the medium is in the tray. > The FORMAT > UNIT command is still somewhat broken for block devices because its > parameter list length is not in the CDB. However it works for CD/DVD > drives, which mandate the length of the payload. Ouch. One will have to distinguish the interpretation by Peripheral Qualifier and Peripheral Device Type from INQUIRE (SSC = 0x02, MMC = 0x05). > [PATCH 4/5] scsi: remove block descriptors from CDs It was a good stumble stone for my own code. Have a nice day :) Thomas
[Qemu-devel] [PATCH 0/5] scsi/atapi: MMC fixes
Hi,
> The READ TOC/PMA/ATIP at the end of burning gives (reformatted):
> 43 02 02 00 00 00 00 00 51 00
> From drive: 81b
> 00 4f 01 01
> 01 14 00 a0 00 00 00 00 01 00 00
> 01 14 00 a1 00 00 00 00 01 00 00
> 01 14 00 a2 00 00 00 00 18 39 32 <<<
> 01 14 00 01 00 00 00 00 00 02 00
I was not aware you did your tests with libburn. :)
(Regrettably the web site with the wiki is down. Should be up again soon.)
> The data is BCD as far as I remember, so that the marked line would give
> ~25% of the medium taken. That's consistent with the ~200 MB image that
> I was burning.
MSF. Minutes, Seconds, Frames. (M<90): LBA = (M * 60 + S) * 75 + F - 150;
Caused by format code 0010b = RAW TOC. MMC transmits it binary in single
bytes although the media may have it as BCD.
I compute 103325 blocks = 206 MB. So this looks correct.
What were the exact symptoms of the read failure ?
> I also noticed that after burning I sometimes need to eject it and reload
> the medium before its data becomes visible (no matter if from the host or
> the guest). This is true even on the host. Does this strike a bell? I
> might be doing something wrong; perhaps I should be forcing cache=none
> together with scsi-block.
At least Linux is not aware of what i am doing via libburn.
This is not only about size but also about cached content.
Andy Polyakov has addressed this in growisofs by either ejecting and
reloading the tray, or by ioctl(BLKFLSBUF). From growisofs.c:
* - Linux: deploy BLKFLSBUF to avoid media reloads when possible;
Implementation is in dvd+rw-tools-7.1/transport.hxx:
int is_reload_needed (int same_capacity)
{ if (same_capacity && ioctl (fd,0x1261,0) == 0) // try BLKFLSBUF
return 0;
else
return ioctl (fd,CDROM_MEDIA_CHANGED,CDSL_CURRENT) == 0;
}
If i understand this right, then it avoids tray snapping only if size
is not changed, or if the kernel learned about the change by itself.
I oppose the automatic physical tray movement because this might cause
accidents with human or silicone injuries.
BLKFLSBUF did not help for me, when i tried it on SuSE 10.
Maybe i should examine it again on Debian 6.
So for now i advise users to eject the medium after xorriso is done
with it. xorriso resp. libburn itself has no problem with the kernel
ignorance. (It has no problem with reading the end of CD TAO tracks
either.)
> Ok, so that would not work yet with scsi-block; it would return an LBA out
> of range error.
udev on a Debian 6 with Gnome desktop running gets quite reliably the
kernel events from opening and closing file descriptors to the device
node. (With only the graphical login running, there are fewer events.)
But with qemu, the drive is opened from start to end of the virtual
machine life. And the quest system probably does not tell the drive
about a close(2) event. So qemu will not learn from the guest and
cannot go through a close(2)-open(2) cycle on the host.
qemu should try its best to get any change that was noticed by the host
system, e.g. after manual reloading of the drive.
(Maybe by ioctl(CDROM_MEDIA_CHANGED) as growisofs does ?)
Some opportunity to close(2)-and-open(2) the host drive by command
of the qemu user could be helpful.
> I don't have DVD+R media at hand, but I can try writing a
> patch for testing.
CD-RW TAO should have the same effect.
You get TAO from xorriso when writing a second session to appendable CD
(i.e. first session without -close on), or you can get it by hiding
the input size from its cdrecord emulation:
cat my_track_source_file | \
xorriso -as cdrecord blank=fast -v -V dev=/dev/sr0 -
--
A test about host and guest awareness:
On the guest, i burned and checkread a CD-RW SAO session with closing
$ xorriso -md5 on -outdev /dev/sr1 -close on -add /usr/include --
$ xorriso -md5 on -indev /dev/sr1 -check_md5_r sorry / --
xorriso says that all is well. It sees 3710 blocks of ISO 9660 filesystem.
dd on host and guest read 0 bytes without error message.
I eject and reload on the host
$ eject /dev/sr2
$ eject -t /dev/sr2
The host still reads 0 bytes. The guest too.
I shutdown the guest and qemu.
The host knows immediately that there are
3860+0 records in
which matches the session size of 3710 blocks plus 150 blocks of padding.
So it is the close(2) call of qemu which makes the host kernel aware.
(But this is not so with all Linux kernels of the last years.)
I restarted qemu and the guest. Burned a new, larger session to CD-RW.
Host and guest still deliver the old size of 3860 blocks.
Nothing i do can change the hosts idea of size, until i shutdown qemu.
(Tried eject, wodim, cdrskin, ...)
qemu device setup was this new variation:
> As a sidenote, passing a blank CD or unformatted DVD with scsi-block or
> v
[Qemu-devel] Re: [PATCH 1/5] atapi: kill MODE SENSE(6), fix MODE SENSE(10)
Hi, Paolo Bonzini wrote: > > > case MODE_PAGE_R_W_ERROR: /* error recovery */ > > > [...] > > > -buf[15] = 0x00; Kevin Wolf wrote: > > Why did you drop this? It still seems to be part of the buffer. Paolo Bonzini wrote: > Actually, I think it's best if these patches wait until Thomas can give a > shot at testing them. If that means missing 1.0, so be it. libburn does not use mode page 1 "Read/Write Error Recovery Parameters". So can only judge by theory and not by test. MMC-1 says it has 8 bytes (beginning at buf[8] = MODE_PAGE_R_W_ERROR). MMC-2 says it has 12. MMC-6 says it has 12. So buf[15] = 0x00 matches MMC-1 and the announcement made by buf[9] = 16 - 10; (6 is the number of bytes after buf[9]). I would advise to keep buf[15] = 0x00. Have a nice day :) Thomas
