Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?

[Zhi Yong Wu]

On Thu, Nov 3, 2011 at 2:05 AM, Thomas Schmitt <address@hidden> 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
> address@hidden:~> 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