On 11/06/2011 09:14 PM, Thomas Schmitt wrote:
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. :))
Cool. So you might have unveiled some
On Thu, Nov 3, 2011 at 2:05 AM, Thomas Schmitt scdbac...@gmx.net wrote:
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
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
On 11/07/2011 11:04 AM, Thomas Schmitt wrote:
In a thread on linux-hotplug, /dev/sg* is declared to be deprecated
in favor of/dev/bsg/* and /dev/sr*.
Will this become a problem ?
I think /dev/bsg is backwards-compatible more or less, but it would help
if it had decent documentation in the
On Mon, Nov 7, 2011 at 7:13 PM, Paolo Bonzini pbonz...@redhat.com wrote:
On 11/07/2011 11:04 AM, Thomas Schmitt wrote:
In a thread on linux-hotplug, /dev/sg* is declared to be deprecated
in favor of/dev/bsg/* and /dev/sr*.
Will this become a problem ?
I think /dev/bsg is backwards-compatible
On 11/07/2011 12:24 PM, Zhi Yong Wu wrote:
It didn't work for me
I started up one os=rh6.1 guest with above options.
On guest:
[root@localhost ~]# mount /dev/sr0 /tmp/1
mount: you must specify the filesystem type
[root@localhost ~]#
You asked for a virtio disk, not a SCSI disk. The CD-ROM
On Mon, Nov 7, 2011 at 7:29 PM, Paolo Bonzini pbonz...@redhat.com wrote:
On 11/07/2011 12:24 PM, Zhi Yong Wu wrote:
It didn't work for me
I started up one os=rh6.1 guest with above options.
On guest:
[root@localhost ~]# mount /dev/sr0 /tmp/1
mount: you must specify the filesystem type
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,
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.
On 11/04/2011 09:28 PM, Thomas Schmitt wrote:
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
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.
On 11/05/2011 03:37 PM, Thomas Schmitt wrote:
MMC-3 5.2 and MMC-5 6.2.3 state about processing of command BLANK with
Immed bit set to one:
In response to the REQUEST SENSE command, unless an error has occurred,
the Drive shall return a SK/ASC/ASCQ values set to
NOT READY/LOGICAL UNIT NOT
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
On 11/04/2011 10:18 AM, Thomas Schmitt wrote:
Paolo:
May i ask for the favor that you try to add O_RDWR to the qemu_open()
call of passthrough devices ?
I think the problem is that you're passing media=cdrom:
if (media == MEDIA_CDROM) {
/* CDROM is fine for any interface, don't
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
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
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 Thomas,
Am 03.11.2011 23:30, schrieb Thomas Schmitt:
I tried to activate DPRINTF in hw/scsi-generic.c by removing the //
before
#define DEBUG_SCSI
make yields:
.../hw/scsi-generic.c: In function 'scsi_send_command':
.../hw/scsi-generic.c:286: error: 'lun' undeclared (first use in
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
On 11/02/2011 10:22 PM, Thomas Schmitt wrote:
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
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'
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
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
On Tue, Nov 1, 2011 at 9:03 PM, Thomas Schmitt scdbac...@gmx.net wrote:
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
On 11/02/2011 12:25 PM, Stefan Hajnoczi wrote:
Now i have two drives by one option.
xorriso -devices reports
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 ?)
Off the
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
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
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
On 11/02/2011 05:26 PM, Thomas Schmitt wrote:
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 ?
Yes.
scsi-block uses
read+write for READ/WRITE CDBs and SG_IO for everything else.
That sounds
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
On 11/02/2011 07:05 PM, Thomas Schmitt 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.
This riddles me.
In
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
41 matches
Mail list logo
