[SeaBIOS] Intermittent USB keyboard freeze

Kevin O'Connor kevin at koconnor.net
Mon Feb 3 18:46:50 CET 2014

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

--- 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;

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?


More information about the SeaBIOS mailing list