Hi,
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
I was not aware you did your
Hi,
Paolo Bonzini wrote:
case MODE_PAGE_R_W_ERROR: /* error recovery */
[...]
-buf[15] = 0x00;
Kevin Wolf wrote:
Why did you drop this? It still seems to be part of the buffer.
Paolo Bonzini wrote:
Actually, I think it's best if these patches wait until Thomas
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
Hi,
i reported nastily bahaving SCSI commands SEND CUE SHEET, SET STREAMING,
FORMAT UNIT, READ DISC STRUCTURE, REQUEST SENSE , RESERVE TRACK.
This was with
-drive file=/dev/sg2,if=scsi
Paolo Bonzini wrote:
I fixed all of these; [...]
The bugs were simply that QEMU did not compute the length
Hi,
the test results on CD-RW, DVD-RW, DVD+RW, BD-RE are flawless with
Paolo Bonzini's most recent proposal
-drive file=/dev/sr2,if=none,id=scsicd
-device
virtio-blk,drive=scsicd,logical_block_size=2048,physical_block_size=2048
libburn works fine via SG_IO. dd and other unaware readers work
Hi,
i am now testing a hack that adds O_EXCL to the call of qemu_open()
in block/raw-posix.c. Just as proof-of-concept.
This is Linux-host-specific, of course.
---
As first i learned to distinguish between octal and hex. :))
Hi,
drive file=/dev/sg2,if=virtio -cdrom /dvdbuffer/pseudo_drive
Actually everything works like a charm now. :))
Cool. So you might have unveiled some kernel bugs too (host crashes are
never desirable!)
The USB drive is back at the test machine.
I'm running the planned BD-RE tests on
Hi,
Markus Armbruster wrote:
Has anyone thought of keeping your tests around for regression testing
purposes?
The full tour lasts a whole workday and needs human attention.
I still did not come to test the newest proposals of Paolo Bonzini
and Zhi Yong Wu, because the last BD-R test was
Hi,
Paolo Bonzini wrote:
Yes, docs/qdev-device-use.txt helps. qemu -device virtio-blk,? too.
I read it and ran '-device ?'. But both left me clueless.
The text i understood mainly as refering to old ways and new way
of defining devices. I stalled when i found no flesh for HOST-OPTS
and
Hi,
here are test results from the USB attached BD recorder.
It is a SATA drive 'Optiarc' 'BD RW BD-5300S' rev '1.04' at
a 'JMicron' 'JM20336 SATA, USB Combo' controller.
--
qemu start command is the same as with the
Hi,
i wanted to test Blu-ray burning and attached a BD recorder via USB
to the host. Its power was switched on, before i booted the host.
The host can operate this drive.
But the qemu guest obviously has severe problems with it.
There is a 'QEMU DVD-ROM' at /dev/sr0.
There is also a /dev/sr1,
Hi,
Paolo Bonzini wrote:
It would be more interesting if you tried again the failure cases with a
virtio drive (if=virtio). It would appear as /dev/vda but you can issue
SG_IO to it. This would isolate the failure to the kernels vs. the SCSI
subsystem.
Will do. I am currently fighting with
Hi,
since i had to give up the plan to test BD burning, i now post the
first summary of passthrough testing on base of if=scsi .
Next i will try to follow Paolo Bonzini's proposal to use if=virtio.
-
List of successes and
Hi,
i have finished CD and DVD tests with
drive file=/dev/sg2,if=virtio -cdrom /dvdbuffer/pseudo_drive
There is substantial improvement towards if=scsi.
Actually everything works like a charm now. :))
It did not work for libburn out of the box, but i could work around
most of the obstacles.
Hi,
Paolo Bonzini wrote:
Can you retry this running qemu as root or with CAP_SYS_RAWIO?
No improvement to see.
On a new DVD+RW i do
$ xorriso -for_backup -scsi_log on -dev /dev/sr1 -add /usr/include --
and still get
FORMAT UNIT
04 11 00 00 00 00
To drive: 12b
00 02 00 08 ff ff ff
Hi,
i completed my tests on DVD-RW (next will be DVD+R).
Sequential DVD-RW can be written with write type Incremental (aka Packet)
and be blanked.
The write run commands of this DVD-RW profile 0x14 are the same as the
ones for profile 0x11 DVD-R. So i boldly declare write success for both.
Hi,
[REQUEST SENSE while blanking]
MMC-3 5.2 and MMC-5 6.2.3
Is this git master or 0.15?
It is a git clone obtained on November 2 by
git clone git://git.qemu.org/qemu.git
I see a file VERSION with date Nov 2 13:41 (+0100)
$ cat VERSION
0.15.90
$ git describe
fatal: No
Hi,
now for DVD+R burning.
It works well if i avoid command RESERVE TRACK.
RESERVE TRACK shows similar effects as the failed DVD-RW DAO run,
resp. the failed CD SAO run: qemu gets stuck at 100 % CPU.
No failed ioctl is indicated by my printfs.
Details:
Hi
i can prevent the EPERM failures of ioctl(SG_IO) by opening the
device file /dev/sg1 with O_RDWR rather than O_RDONLY.
In block/raw-posix.c:raw_open_common i implemented this hack:
printf(block/raw-posix.c: raw_open_common(\%s\, %x)\n,
filename, s-open_flags);
if
Hi,
i wrote:
Paolo:
May i ask for the favor that you try to add O_RDWR to the qemu_open()
call of passthrough devices ?
Paolo Bonzini wrote:
I think the problem is that you're passing media=cdrom:
Just do not do that when using scsi-generic.
The result looks promising, indeed. I
Hi,
i wrote:
CD SAO gets stuck at SEND CUE SHEET.
Paolo Bonzini wrote:
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
Hi,
We're about to release QEMU 1.0(-rc1) and you've just spotted a
compilation issue...
Maybe one should consider to obtain the missing information
rather than crippling the debug message, like i did.
You've solved this issue 50%! What's missing now is for you to put this
fix into a
Hi,
another showstopper appeared for DVD+RW.
After i disabled SET STREAMING, i was able to write a thoroughly formatted
DVD+RW. But when i inserted one that was never written up to its end, the
attempt failed to (re-)start background formatting (Format Type = 26h):
FORMAT UNIT
04 11 00 00
Hi,
first i want to thank Paolo for his patience.
So if you specified -drive if=scsi *and* -cdrom, you'd get two non-empty
drives.
Indeed. With
-drive file=/dev/sr0,if=scsi,media=cdrom -cdrom /dvdbuffer/pseudo_drive
i get two drives with media:
0 -dev '/dev/sr0' rwrw-- : 'QEMU'
Hi,
i repeated my tests with -drive and -cdrom in the same qemu run:
...absolute.path.../x86_64-softmmu/qemu-system-x86_64 \
-enable-kvm \
-L ...absolute.path.../pc-bios \
-nographic \
-m 512 \
-net nic,model=ne2k_pci \
-net user,hostfwd=tcp::5557-:22 \
-hda
Hi,
i could track down the reason for sense code B 00 06 to an ioctl(SG_IO)
which returns -1. errno is 1.
The host system has in /usr/include/asm-generic/errno-base.h
#define EPERM1 /* Operation not permitted */
The user who runs qemu is able to perform e.g.
PREVENT/ALLOW
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
Hi,
Paolo Bonzini wrote:
I suggest trying with 1.0-rc (origin/master).
Am i on the right track with git clone git://git.qemu.org/qemu.git ?
scsi-block uses
read+write for READ/WRITE CDBs and SG_IO for everything else.
That sounds scary to me. On real Linux systems it is not advisable to
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
Hi,
i wrote:
So how is this altered to 0x12 in the further course of processing ?
Paolo Bonzini wrote:
Because you're using an *IDE* (ATAPI) CD-ROM, not SCSI. See hw/ide/atapi.c.
You convinced me.
But this does not explain yet the difference in behavior of
both groups of IDE DVD-ROMs. Why
Hi,
i forgot to address this concern:
Paolo Bonzini wrote:
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.
The SCSI client is supposed
Hi,
i sent the following to Paolo Bonzini and Stefan Hajnoczi.
Stefan advised
In the future I think it's appropriate to CC qemu-devel since others
in the community may be interested in virtio-scsi discussions too.
So i forward my mail to this list.
I am subscribed now.
A first test report of
Hi,
Stefan Hajnoczi wrote:
In the future I think it's appropriate to CC qemu-devel since others
in the community may be interested in virtio-scsi discussions too.
Ok. I'll forward my original mail and this reply to qemu-devel.
The current state is that CD-ROM passthrough with virtio-scsi
33 matches
Mail list logo
