From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45207) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLtix-0006QK-AE for qemu-devel@nongnu.org; Thu, 03 Nov 2011 05:36:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RLtiw-0000em-3y for qemu-devel@nongnu.org; Thu, 03 Nov 2011 05:36:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31422) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RLtiv-0000ee-S6 for qemu-devel@nongnu.org; Thu, 03 Nov 2011 05:36:38 -0400 Message-ID: <4EB2609F.7000601@redhat.com> Date: Thu, 03 Nov 2011 10:36:31 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <4EB24790.7000102@redhat.com> <97461468821810@192.168.2.69> In-Reply-To: <97461468821810@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/03/2011 10:15 AM, Thomas Schmitt wrote: > Which gives me something to work on. libburn does not take into > respect the Block Descriptor of 8 bytes which sits between > Mode Data Header and mode page. > So it misinterpets the result and demands the wrong Allocation > Length. > > This error is explainable by my reading of MMC-5 which prescribes > in table 653: > "Block Descriptor Length = 0" > MMC-1 on the other hand has in Annex B.4.1 : > "The Mode Parameter Block Descriptor does not apply to ATAPI > devices, and the Block Descriptor Length in the Mode > Parameter Header shall be set to 0." > > My thanks to qemu and the developers of its SCSI CD-ROM for showing > me this misconception in libburn. MMC-3 also has some text saying that for compatibility you can have block descriptors. > ------------------------------------------------------------------------ > > If i do only -drive file=/dev/sr0,if=scsi,medium=cdrom i get > one empty drive, obviously from hw/ide/atapi.c:cmd_mode_sense(): > > 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 3b 00 71 60 29 00 02 c0 00 02 > 02 00 02 c0 00 00 00 00 > > So i mistook the default DVD-ROM drive, which has no source data and > thus is empty, for the CD-ROM drive which i expected from -drive if=scsi > which would not be empty, but does not show up at all. > > The question remains, why the CD-ROM drive is missing if i do -drive > but not -cdrom. Ok, so we have something to test now. :) > I will repeat my experiments with > -drive file=/dev/sg2,if=scsi,media=cdrom -cdrom /dvdbuffer/pseudo_drive > > Maybe the presence of -cdrom cures the problems i had with passthrough. > (The bug in libburn is not to blame for that. The passthrough drive did not > deliver a block descriptor.) Yes, otherwise it wouldn't be passthrough. :) > ------------------------------------------------------------------------ > >> Yeah, looks like all the >> >> case MODE_PAGE_R_W_ERROR: /* error recovery */ >> cpu_to_ube16(&buf[0], 16 + 6); >> should have "- 2" instead of "+ 6". > > I came to the same conclusion. Good. > MMC-1 allows MODE SENSE(6), MMC-3 implicitely assumes MODE SENSE(10) only, > MMC-5 prescribes to use MODE SENSE(10). > > MMC-2 has a list of required ATAPI commands. MODE SENSE(10) is listed. > MODE SENSE(6) is not listed. > > > I compared this with the SCSI counterpart of cmd_mode_sense(): > hw/scsi-disk.c:scsi_disk_emulate_mode_sense() > > It distinguishes between MODE_SENSE, which gets 4 bytes of header, > and MODE_SENSE_10, which gets 8. This looks correct. Yep. Seems easiest to just drop MODE SENSE(6) from ATAPI. Paolo