From: BALATON Zoltan <balaton@eik.bme.hu>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: USB pass-through problems
Date: Thu, 28 May 2020 11:29:53 +0200 (CEST) [thread overview]
Message-ID: <alpine.BSF.2.22.395.2005281128460.96126@zero.eik.bme.hu> (raw)
In-Reply-To: <20200528064039.yw5in3whgjvlni4z@sirius.home.kraxel.org>
On Thu, 28 May 2020, Gerd Hoffmann wrote:
> On Wed, May 27, 2020 at 09:44:54PM +0200, BALATON Zoltan wrote:
>> Hello,
>>
>> I've seen a case when QEMU hangs with a passed through USB device. This is
>> with -device usb-ehci and pass through with usb-host. This works until the
>> attached USB device reboots (so likely it disconnects and reconnects) at
>> which point QEMU hangs and need to be SIGKILL-ed to end (that's a bit hard
>> to do with mouse and keyboard grabbed). I've got this stack trace:
>>
>> #0 0x00007f23e7bd4949 in poll () at /lib64/libc.so.6
>> #1 0x00007f23e8bfa9a5 in () at /lib64/libusb-1.0.so.0
>> #2 0x00007f23e8bfbb13 in libusb_handle_events_timeout_completed () at /lib64/libusb-1.0.so.0
>> #3 0x000055e09854b7da in usb_host_abort_xfers (s=0x55e09b036dd0) at hw/usb/host-libusb.c:963
>> #4 0x000055e09854b87a in usb_host_close (s=0x55e09b036dd0) at hw/usb/host-libusb.c:977
>> #5 0x000055e09854b92e in usb_host_nodev_bh (opaque=0x55e09b036dd0) at hw/usb/host-libusb.c:998
>> #6 0x000055e098757500 in aio_bh_call (bh=0x55e099ad9cc0) at util/async.c:136
>> #7 0x000055e09875760a in aio_bh_poll (ctx=0x55e0996c2620) at util/async.c:164
>> #8 0x000055e09875cb2a in aio_dispatch (ctx=0x55e0996c2620) at util/aio-posix.c:380
>> #9 0x000055e098757a3d in aio_ctx_dispatch (source=0x55e0996c2620, callback=0x0, user_data=0x0) at util/async.c:306
>> #10 0x00007f23e8c59665 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
>> #11 0x000055e09875b0a9 in glib_pollfds_poll () at util/main-loop.c:219
>> #12 0x000055e09875b123 in os_host_main_loop_wait (timeout=0) at util/main-loop.c:242
>> #13 0x000055e09875b228 in main_loop_wait (nonblocking=0) at util/main-loop.c:518
>> #14 0x000055e0982c91f8 in qemu_main_loop () at softmmu/vl.c:1664
>> #15 0x000055e098162e7e in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at softmmu/main.c:49
>>
>> so the problem may be in libusb but QEMU should not hang completely. The
>> host is Linux with libusb 1.0.22.
>
> Hmm, does reverting 76d0a9362c6a6a7d88aa18c84c4186c9107ecaef change
> behavior?
Yes it does. Reverting that patch fixes the problem, no hang and device
reconnects without problem.
Thanks,
BALATON Zoltan
next prev parent reply other threads:[~2020-05-28 9:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-27 19:44 USB pass-through problems BALATON Zoltan
2020-05-28 6:40 ` Gerd Hoffmann
2020-05-28 9:29 ` BALATON Zoltan [this message]
2020-05-28 13:28 ` Gerd Hoffmann
2020-05-28 20:41 ` BALATON Zoltan
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=alpine.BSF.2.22.395.2005281128460.96126@zero.eik.bme.hu \
--to=balaton@eik.bme.hu \
--cc=kraxel@redhat.com \
--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.