From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35436) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RMI08-0000Y3-Fp for qemu-devel@nongnu.org; Fri, 04 Nov 2011 07:32:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RMI07-0008Dh-Fr for qemu-devel@nongnu.org; Fri, 04 Nov 2011 07:32:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34285) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RMI07-0008Dd-5x for qemu-devel@nongnu.org; Fri, 04 Nov 2011 07:31:59 -0400 Message-ID: <4EB3CD25.3030100@redhat.com> Date: Fri, 04 Nov 2011 12:31:49 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <4EB3B295.7080102@redhat.com> <97457849023542@192.168.2.69> In-Reply-To: <97457849023542@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: Thomas Schmitt Cc: kwolf@redhat.com, stefanha@gmail.com, qemu-devel@nongnu.org On 11/04/2011 12:09 PM, Thomas Schmitt wrote: > 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.) 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? > 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. 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. Paolo