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_QM00001 scsi-SATA_QEMU_HARDDISK_QM00001
ata-QEMU_HARDDISK_QM00001-part1 scsi-SATA_QEMU_HARDDISK_QM00001-part1
ata-QEMU_HARDDISK_QM00001-part2 scsi-SATA_QEMU_HARDDISK_QM00001-part2
ata-QEMU_HARDDISK_QM00001-part5 scsi-SATA_QEMU_HARDDISK_QM00001-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/pci0000:00/0000:00:01.1/host0/target0:0:0/0:0:0:0
lrwxrwxrwx 1 root root 0 Nov 2 18:30 1:0:0:0 ->
../../../devices/pci0000:00/0000:00:01.1/host1/target1:0:0/1:0:0:0
lrwxrwxrwx 1 root root 0 Nov 2 18:35 2:0:0:0 ->
../../../devices/pci0000:00/0000:00:04.0/host2/target2:0:0/2:0:0:0
lrwxrwxrwx 1 root root 0 Nov 2 18:30 host0 ->
../../../devices/pci0000:00/0000:00:01.1/host0
lrwxrwxrwx 1 root root 0 Nov 2 18:30 host1 ->
../../../devices/pci0000:00/0000:00:01.1/host1
lrwxrwxrwx 1 root root 0 Nov 2 18:30 host2 ->
../../../devices/pci0000:00/0000:00:04.0/host2
lrwxrwxrwx 1 root root 0 Nov 2 18:30 target0:0:0 ->
../../../devices/pci0000:00/0000:00:01.1/host0/target0:0:0
lrwxrwxrwx 1 root root 0 Nov 2 18:30 target1:0:0 ->
../../../devices/pci0000:00/0000:00:01.1/host1/target1:0:0
lrwxrwxrwx 1 root root 0 Nov 2 18:35 target2:0:0 ->
../../../devices/pci0000:00/0000:00:04.0/host2/target2:0:0
$ cat /proc/scsi/sg/device_hdr /proc/scsi/sg/devices
host chan id lun type opens qdepth busy online
0 0 0 0 0 1 1 0 1
1 0 0 0 5 1 1 0 1
2 0 0 0 5 1 1 0 1
thomas@i386:~> cat /proc/scsi/sg/device_strs
ATA QEMU HARDDISK 0.15
QEMU QEMU DVD-ROM 0.15
TSSTcorp CDDVDW SH-S223B SB02
This is inconclusive, as it lists the hard disk too.
Whatever the reason, there is a problem with -drive if=scsi,medium=cdrom.
Have a nice day :)
Thomas
