From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43866) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLdao-0000Mn-NK for qemu-devel@nongnu.org; Wed, 02 Nov 2011 12:23:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RLdam-0007WC-M5 for qemu-devel@nongnu.org; Wed, 02 Nov 2011 12:23:10 -0400 Received: from mail-qy0-f173.google.com ([209.85.216.173]:55836) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLdam-0007Vx-I1 for qemu-devel@nongnu.org; Wed, 02 Nov 2011 12:23:08 -0400 Received: by qyk30 with SMTP id 30so2798967qyk.4 for ; Wed, 02 Nov 2011 09:23:08 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <4EB16E5C.1020102@redhat.com> Date: Wed, 02 Nov 2011 17:22:52 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <97441936919356@192.168.2.69> In-Reply-To: <97441936919356@192.168.2.69> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel , scdbackup@gmx.net, Kevin Wolf , Stefan Hajnoczi On 11/02/2011 04:15 PM, Thomas Schmitt wrote: > 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.) This is a packaging bug, I think. Will look at it tomorrow. > Drive list as detected by xorriso: > 0 -dev '/dev/sr0' rwrw-- : 'TSSTcorp' 'CDDVDW SH-S223B' > 1 -dev '/dev/sr1' rwrw-- : 'QEMU ' 'QEMU DVD-ROM' > > 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 Is it good or bad? :) I see it even in the very first command. > 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 What do these give on the host? Sounds like another LSI emulation bug. > 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. > About the non-passthrough QEMU DVD-ROM : > > i wrote: >>> -drive file=/dev/sg2,if=scsi,bus=4,unit=0,media=cdrom >>> Now i have two drives by one option [...] >>> 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 ?) > > Stefan Hajnoczi wrote: >> Off the top of my head I'd say this is an empty IDE CD-ROM drive which >> is added by default. Would need to check the code to be sure though. > > Actually i meant: > 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, only empty because you didn't specify any medium. You can open the tray, close the tray, change the medium with the monitor. > The fact that 'QEMU DVD-ROM' from file=/dev/sg2,if=scsi behaves like > the drives from the other file=...,if=scsi makes me think that it is > an emulated SCSI drive. It is not, 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. Paolo