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? cheers, Gerd