From: "Thomas Schmitt" <scdbackup@gmx.net>
To: qemu-devel@nongnu.org
Cc: kwolf@redhat.com, stefanha@gmail.com, pbonzini@redhat.com
Subject: Re: [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ?
Date: Fri, 04 Nov 2011 12:09:58 +0100 [thread overview]
Message-ID: <97457849023542@192.168.2.69> (raw)
In-Reply-To: <4EB3B295.7080102@redhat.com>
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 disabled my hack but left the
first printf active. Now i see at boot time
block/raw-posix.c: raw_open_common("/dev/sg2", 1000)
block/raw-posix.c: raw_open_common("/dev/sg2", 1002)
and still no failing ioctls or sense code B 00 06.
Burning to an appendable CD-RW in mode TAO still works.
So thanks for this swift fulfilling of my wish. :))
-----------------------------------------------------------------------
Disappointment:
CD-RW burning in mode SAO (on a blank medium) gets stuck at this command
SEND CUE SHEET
5d 00 00 00 00 00 00 00 20 00
To drive: 32b
41 00 00 01 00 00 00 00 41 01 00 10 00 00 00 00 41 01 01 10
00 00 02 00 41 aa 01 01 00 00 35 30
After 200 seconds, the qemu process begins to use 100 % CPU,
and the pacifier messages of xorriso stall. The guest is stuck.
-----------------------------------------------------------------------
When i restart qemu and boot the guest without having rebooted the
host, then after about 20 seconds, qemu is at 100 % CPU and no login
is possible. There is a short time window after boot, where i
can log in.
The problem seems to sit in the host's drive /dev/sr1 which
cannot be ejected or used by any program. They all get stuck.
So it is likely that the ungraceful end of drive usage is to blame.
I will tomorrow attach an USB drive to the machine and see
whether re-powering it spares rebooting. (Linux USB is the best
test bed for dangerous drive experiments.)
-----------------------------------------------------------------------
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.)
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.
-----------------------------------------------------------------------
Have a nice day :)
Thomas
next prev parent reply other threads:[~2011-11-04 11:10 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-01 17:27 [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ? Thomas Schmitt
2011-11-01 21:03 ` Thomas Schmitt
2011-11-02 11:25 ` Stefan Hajnoczi
2011-11-02 12:08 ` Paolo Bonzini
2011-11-02 16:26 ` Thomas Schmitt
2011-11-02 16:34 ` Paolo Bonzini
2011-11-02 18:05 ` Thomas Schmitt
2011-11-02 19:50 ` Paolo Bonzini
2011-11-02 21:22 ` Thomas Schmitt
2011-11-02 22:08 ` Thomas Schmitt
2011-11-02 22:16 ` [Qemu-devel] Compile error Frans de Boer
2011-11-02 22:19 ` Anthony Liguori
2011-11-02 22:31 ` Frans de Boer
2011-11-03 7:49 ` [Qemu-devel] Do you have a use for a tester of virtio-scsi with CD drives ? Paolo Bonzini
2011-11-03 9:15 ` Thomas Schmitt
2011-11-03 9:36 ` Paolo Bonzini
2011-11-03 13:10 ` Thomas Schmitt
2011-11-03 22:30 ` Thomas Schmitt
2011-11-04 9:18 ` Thomas Schmitt
2011-11-04 9:38 ` Paolo Bonzini
2011-11-04 11:09 ` Thomas Schmitt [this message]
2011-11-04 11:31 ` Paolo Bonzini
2011-11-04 13:03 ` Thomas Schmitt
2011-11-04 20:28 ` Thomas Schmitt
2011-11-05 8:33 ` Paolo Bonzini
2011-11-05 13:00 ` Thomas Schmitt
2011-11-05 14:37 ` Thomas Schmitt
2011-11-05 15:53 ` Paolo Bonzini
2011-11-05 16:38 ` Thomas Schmitt
2011-11-05 20:47 ` Thomas Schmitt
2011-11-06 8:17 ` Paolo Bonzini
2011-11-06 10:35 ` Thomas Schmitt
2011-11-06 20:14 ` Thomas Schmitt
2011-11-07 8:02 ` Paolo Bonzini
2011-11-07 10:04 ` Thomas Schmitt
2011-11-07 11:13 ` Paolo Bonzini
2011-11-07 11:24 ` Zhi Yong Wu
2011-11-07 11:29 ` Paolo Bonzini
2011-11-07 11:40 ` Zhi Yong Wu
2011-11-06 9:31 ` Thomas Schmitt
2011-11-04 13:26 ` Andreas Färber
2011-11-04 14:46 ` Thomas Schmitt
2011-11-07 8:48 ` Zhi Yong Wu
2011-11-02 15:15 ` Thomas Schmitt
2011-11-02 16:22 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=97457849023542@192.168.2.69 \
--to=scdbackup@gmx.net \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.