From: Erik Rull <906221@bugs.launchpad.net>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Bug 906221] Re: USBDEVFS_CLEAR_HALT stall with USB-CDROM qemu-1.0
Date: Fri, 16 Dec 2016 19:15:58 -0000 [thread overview]
Message-ID: <58543D6E.506@rdsoftware.de> (raw)
In-Reply-To: 20161215174024.29048.32926.malone@wampee.canonical.com
Meanwhile it works.
Thomas Huth wrote:
> Triaging old bug tickets ... Can you still reproduce this problem with
> the latest version of QEMU and the latest version of libusb? If so,
> could you please also provide the command line options that you used to
> start QEMU?
>
> ** Changed in: qemu
> Status: New => Incomplete
>
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/906221
Title:
USBDEVFS_CLEAR_HALT stall with USB-CDROM qemu-1.0
Status in QEMU:
Incomplete
Bug description:
When connecting a USB DVD/CDROM drive to the linux host, it works fine and I can mount the inserted DVD properly and work with it. After unmounting the DVD and routing the USB drive to the linux guest (same kernel version), both host and guest become unresponsive and on the QEMU console I get the QEMU console flodded with the message:
USBDEVFS_CLEAR_HALT: Connection timed out
again and again, approx. each 10-20 seconds.
When I unplug the device from the host, the message
USBDEVFS_CLEAR_HALT: No such device
comes up in one block at least 100 times (my scrollback history of the display is limited, so I cannot say how often it actually appreared)
On the guest side linux, I see the following dmesg after having it routed from the host to the guest:
[ 160.292231] usb 1-2.1: new full speed USB device using uhci_hcd and address 5
[ 160.475762] usb 1-2.1: configuration #1 chosen from 1 choice
[ 160.478553] scsi3 : SCSI emulation for USB Mass Storage devices
[ 160.479689] usb-storage: device found at 5
[ 160.480121] usb-storage: waiting for device to settle before scanning
[ 165.494016] scsi 3:0:0:0: CD-ROM slimtype eTDU108 1 SL03 PQ: 0 ANSI: 0
then, the guest stalls and on the host side the USBDEVFS_CLEAR_HALT
appears until I unplug the hardware from the host - pay also attention
on the stalled dmesg timestamp! The "real" timegap between the last
line above and the first line below is more than 20 seconds!
[ 165.645735] usb 1-2.1: USB disconnect, address 5
[ 165.663770] sr0: scsi3-mmc drive: 24x/24x cd/rw xa/form2 cdda pop-up
[ 165.664416] sr 3:0:0:0: Attached scsi CD-ROM sr0
[ 165.664623] sr 3:0:0:0: Attached scsi generic sg1 type 5
[ 165.665565] usb-storage: device scan complete
The drive used is a self-powered LITEON External Slim DVD-ROM Drive (Model number eTDU108-02 1)
The power is not a problem, because the drive works fine on the host directly.
Best regards,
Erik
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/906221/+subscriptions
next prev parent reply other threads:[~2016-12-16 19:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-19 10:19 [Qemu-devel] [Bug 906221] [NEW] USBDEVFS_CLEAR_HALT stall with USB-CDROM qemu-1.0 Erik Rull
2016-12-15 17:40 ` [Qemu-devel] [Bug 906221] " Thomas Huth
2016-12-16 19:15 ` Erik Rull [this message]
2017-02-15 4:17 ` Launchpad Bug Tracker
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=58543D6E.506@rdsoftware.de \
--to=906221@bugs.launchpad.net \
--cc=qemu-devel@nongnu.org \
/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.