From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45057) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROpuS-0002UC-5W for qemu-devel@nongnu.org; Fri, 11 Nov 2011 07:08:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ROpuP-00010u-UX for qemu-devel@nongnu.org; Fri, 11 Nov 2011 07:08:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46762) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROpuP-00010H-Mw for qemu-devel@nongnu.org; Fri, 11 Nov 2011 07:08:37 -0500 Message-ID: <4EBD103E.60804@redhat.com> Date: Fri, 11 Nov 2011 13:08:30 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1320940872-4940-1-git-send-email-pbonzini@redhat.com> <9747328106283@192.168.2.69> In-Reply-To: <9747328106283@192.168.2.69> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/5] scsi/atapi: MMC fixes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thomas Schmitt Cc: kwolf@redhat.com, qemu-devel@nongnu.org, kraxel@redhat.com On 11/10/2011 07:17 PM, Thomas Schmitt wrote: > Hi, > >> I only tested CD-RW DAO burning of an ISO image, plus invoking a bunch >> of commands from Thomas's logs). The burning succeeded but reading >> the resulting medium failed consistently at 26 MB. However, the same >> happened even when doing CD passthrough via virtio, so it may be due to >> a different bug. > > Did you get a sense code from the failure ? > > My best guess would be that you announced 26 MB by the SEND CUE SHEET > command. > Proposals for inspection of CD medium structure on real Linux: > > wodim -v dev=/dev/sr0 -toc > cdrecord -v dev=/dev/sr0 -minfo > cdrskin -v dev=/dev/sr0 -minfo > xorriso -outdev /dev/sr0 -toc > > SCSI command logs are available by -V resp. -scsi_log on. The READ TOC/PMA/ATIP at the end of burning gives (reformatted): 43 02 02 00 00 00 00 00 51 00 From drive: 81b 00 4f 01 01 01 14 00 a0 00 00 00 00 01 00 00 01 14 00 a1 00 00 00 00 01 00 00 01 14 00 a2 00 00 00 00 18 39 32 <<< 01 14 00 01 00 00 00 00 00 02 00 01 54 00 b0 ff ff ff 03 4f 3b 4a 01 54 00 c0 2c 00 ae 00 61 22 18 01 54 00 c1 cc 94 32 00 00 00 00 The data is BCD as far as I remember, so that the marked line would give ~25% of the medium taken. That's consistent with the ~200 MB image that I was burning. I also noticed that after burning I sometimes need to eject it and reload the medium before its data becomes visible (no matter if from the host or the guest). This is true even on the host. Does this strike a bell? I might be doing something wrong; perhaps I should be forcing cache=none together with scsi-block. > Writing CD TAO or Packet, Incremental Streaming on DVD-R[W], or writing > on DVD+R and BD-R without RESERVE TRACK, will cause the new readable > size to be determined only after CLOSE TRACK SESSION. > SEND CUE SHEET resp. RESERVE TRACK determine the size before writing > begins. Ok, so that would not work yet with scsi-block; it would return an LBA out of range error. I don't have DVD+R media at hand, but I can try writing a patch for testing. As a sidenote, passing a blank CD or unformatted DVD with scsi-block or virtio-blk-pci requires adding ",format=raw" to the -drive option. > DVD-RAM and BD-RE can change their formatted size by FORMAT UNIT. > In this case, the new size is determined as soon as TEST UNIT READY > resp. REQUEST SENSE deliver no sense data any more. On the other hand, they have no lead-in so they do not use negative LBA. Formatting still has the problem of REQUEST SENSE returning bogus data, so it works but libburn might start the burning process while the disc is still being formatted. Not surprisingly, the results are interesting. I have a patch for that too. > DVD+RW and formatted DVD-RW can grow their formatted size during > writing. This is started by FORMAT UNIT but the size is decided only > when writing ends. This end is not unambigously to detect. One may > at any time continue writing as long as the medium is in the tray. On the other hand, READ CAPACITY is updated as soon as formatting finishes (I think) and that's what matters for QEMU. libburn sends READ CAPACITY and that's enough for QEMU to learn about the size of the disc. >> The FORMAT UNIT command is still somewhat broken for block devices >> because its parameter list length is not in the CDB. However it >> works for CD/DVD drives, which mandate the length of the payload. > > Ouch. One will have to distinguish the interpretation by Peripheral > Qualifier and Peripheral Device Type from INQUIRE (SSC = 0x02, MMC = > 0x05). Yes, that's what I did already. Luckily the peripheral device type is already available in SCSIDevice. Paolo