On Mon, Feb 03, 2014 at 11:50:21AM -0500, Gabriel L. Somlo wrote:
Hi Kevin,
I'm running into an intermittent (roughly 50% of the time) USB keyboard freeze, using the following command line:
bin/qemu-system-x86_64 -enable-kvm -m 2048 -cpu core2duo -M q35 \ -usb -device usb-kbd -device usb-mouse \ -device ide-drive,bus=ide.2,drive=HDD \ -drive id=HDD,if=none,snapshot=on,file=./Fedora-Live-Desktop-x86_64-20-1.iso \ -bios bios-test.bin
Hi Gerd,
You're familiar with the QEMU USB code. Any idea what could be causing these intermittent failures? I can reproduce the above issue as well. It's not related to xhci at all - it seems related to this change:
--- a/src/hw/usb.c +++ b/src/hw/usb.c @@ -263,6 +263,8 @@ usb_set_address(struct usbdevice_s *usbdev) if (cntl->maxaddr >= USB_MAXADDR) return -1;
+ msleep(USB_TIME_RSTRCY); + // Create a pipe for the default address. struct usb_endpoint_descriptor epdesc = { .wMaxPacketSize = 8, @@ -272,8 +274,6 @@ usb_set_address(struct usbdevice_s *usbdev) if (!usbdev->defpipe) return -1;
- msleep(USB_TIME_RSTRCY); - // Send set_address command. struct usb_ctrlrequest req; req.bRequestType = USB_DIR_OUT | USB_TYPE_STANDARD | USB_RECIP_DEVICE;
It seems like the QEMU UHCI code wants the RSTRCY sleep to be after the pipe is created. But, I can't see why that should be required or why QEMU would even care about a RSTRCY sleep at all.
The failure doesn't depend on kvm, the failure goes away when the above change is reverted, and the failure does not occur if there is only a usb keyboard (and not a usb mouse). When comparing the seabios debug output (level 8) of a successful run to a failed run, the output is basically identical (all the way down to thread timings and the memory positions returned by malloc). With debug level 8, I see the failure more often then not.
Any thoughts?
-Kevin