From: Paul Bolle <pebolle@tiscali.nl>
To: Stan Behrens <lists.nongnu.org@sbeh.de>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [BUG] -usb makes qemu fight against linux
Date: Fri, 24 Apr 2009 12:05:53 +0200 [thread overview]
Message-ID: <1240567553.24225.11.camel@localhost.localdomain> (raw)
In-Reply-To: <49B0E4C9.70002@sbeh.de>
On Fri, 2009-03-06 at 09:54 +0100, Stan Behrens wrote:
> when you add a bluetooth-dongle, usb-flash-drive or something like that via:
> usb_add host:2.23
> to you're guest-OS, qemu starts to fight against the linux-usb-configuration.
>
> qemu's output looks like this:
> husb: open device 2.32
> husb: config #1 need -1
> husb: 1 interfaces claimed for configuration 1
> husb: grabbed usb device 2.32
> husb: config #1 need 1
> husb: 1 interfaces claimed for configuration 1
> husb: config #1 need 1
> husb: 1 interfaces claimed for configuration 1
> husb: config #1 need 1
> husb: 1 interfaces claimed for configuration 1
> husb: config #1 need 1
> husb: 1 interfaces claimed for configuration 1
>
> And '# dmesg' says:
> [12929.001037] usb 2-3: reset high speed USB device using ehci_hcd and address 32
> [12929.782032] usb 2-3: reset high speed USB device using ehci_hcd and address 32
> [12930.176041] usb 2-3: reset high speed USB device using ehci_hcd and address 32
> [12930.726032] usb 2-3: reset high speed USB device using ehci_hcd and address 32
This seems related to this discussion:
http://lists.gnu.org/archive/html/qemu-devel/2008-10/msg01320.html (in a
thread regarding a preliminary patch to implement ehci).
Could you try the following patch? It was created after finally
discovering the discussion mentioned above (which I hardly understand,
which in turn leads to an impressive, but possibly nonsensical commit
message for this patch). It seems to fix a similar issue I ran into
(while trying some advanced feature of a USB memory stick I happen to
have.)
Paul Bolle
---
[PATCH] usb-linux: use USB_RET_STALL on -EPIPE URB status
If ioctl([...], USBDEVFS_REAPURBNDELAY, [...]) sets the URB status to
-EPIPE use USB_RET_STALL (and not USB_RET_NAK). USB_RET_NAK can confuse
guests and seems to trigger some guests to repeatedly request port
resets, which slows down (or even blocks) USB operations.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
usb-linux.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/usb-linux.c b/usb-linux.c
index 70d7a1c..80ef6fc 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -277,7 +277,7 @@ static void async_complete(void *opaque)
set_halt(s, p->devep);
/* fall through */
default:
- p->len = USB_RET_NAK;
+ p->len = USB_RET_STALL;
break;
}
--
1.6.2.2
next prev parent reply other threads:[~2009-04-24 10:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-06 8:54 [Qemu-devel] [BUG] -usb makes qemu fight against linux Stan Behrens
2009-04-24 10:05 ` Paul Bolle [this message]
2009-04-24 10:44 ` Paul Bolle
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=1240567553.24225.11.camel@localhost.localdomain \
--to=pebolle@tiscali.nl \
--cc=lists.nongnu.org@sbeh.de \
--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.