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
_______________________________________________
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
