On Thu, Nov 3, 2011 at 2:05 AM, Thomas Schmitt <scdbac...@gmx.net> wrote:
> 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':
Yeah, i also met this same issue. The summary is very correct for me.
BTW: if the transfer mode is changed from DMA to PIO, it will fail.
/dev/sr0:
multcount = 0 (off)
IO_support = 1 (32-bit)
readonly = 0 (off)
readahead = 256 (on)
HDIO_GETGEO failed: Inappropriate ioctl for device
Model=QEMU DVD-ROM, FwRev=0.15.90, SerialNo=QM00003
Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=DualPortCache, BuffSize=256kB, MaxMultSect=0
CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
IORDY=no, tPIO={min:300,w/IORDY:180}, tDMA={min:180,rec:180}
PIO modes: pio0 pio3 pio4
DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 *mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5
AdvancedPM=no
Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4
* signifies the current active mode
If its transfer mode is changed:
/dev/sr0:
setting xfermode to 8 (PIO flow control mode0)
HDIO_DRIVE_CMD(setxfermode) failed: Invalid exchange
>
> 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
>
>
>
--
Regards,
Zhi Yong Wu
