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?