Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Fixing bug summary as this is not a true hang. The devices just don't work behind a hub so it's not possible to interact with the guest and it appears 'hung'.
And one more update because this is not xhci specific. I can reproduce with uhci also.
-device piix4-usb-uhci,id=usb1 \
-device usb-hub,id=usbhub,bus=usb1.0,port=1 \
-device usb-mouse,id=usbmouse,bus=usb1.0,port=1.1 \
As long as the input device is sending data (mouse is moving), all is good. The device stops working a few seconds after the last input event when the port goes into suspend and then never properly wakes up. Disabling and re-enabling the USB Hub device in Device manager fixes it. But only until the next few seconds of inactivity when it stalls again.
The following patch fixes it for xhci:
@@ -208,6 +208,7 @@ static void usb_hub_wakeup(USBPort *port1)
USBHubPort *port = &s->ports[port1->index];
if (port->wPortStatus & PORT_STAT_SUSPEND) {
+ port->wPortStatus &= ~PORT_STAT_SUSPEND;
port->wPortChange |= PORT_STAT_C_SUSPEND;
usb_wakeup(s->intr, 0);
}
uhci needs one additional tweak in uhci_wakeup.
I'll look at the spec to try to understand what's going on here and if this is the right fix. Adding Gerd.
And I'm putting the "with xhci" back because these are two different issues.
I have convinced myself that the patch in comment #5 is correct and posted it to qemu-devel. It fixes the bug observed with xhci on Windows.
https://lists.nongnu.org/archive/html/qemu-devel/2017-05/msg02694.html
Now the uhci issue manifests in the same way, i.e. remote wakeup doesn't work for suspended devices. But it doesn't need a hub to reproduce. The problem is that Windows doesn't set the UHCI_PORT_SUSPEND flag, despite correctly arming the port for remote wakeup. Thus uhci_wakeup is a no-op and the VM doesn't get any kind of notification that the device has woken up, leading to the issue described in comment #5.
Weirdly, Windows does the right thing with piix3-usb-uhci (Intel 82371SB) and is broken only with piix4-usb-uhci (Intel 82371AB). As far as I can tell, the two chips have identical implementation in QEMU and differ only in the PCI device ID. Windows drives both with usbuhci.sys so the driver must internally modify its behavior based on the device ID for some odd reason. I am going to treat this with lower priority because it requires time-consuming reverse engineering and piix3-usb-uhci is libvirt's default uhci controller anyway.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHSA-2017:2392
Description of problem: when put input devices under one usb hub ,win2016 guest hangs after everything loaded for xhci. Version-Release number of selected component (if applicable): HOST: kernel-3.10.0-656.el7.x86_64 qemu-kvm-rhev-2.9.0-2.el7.x86_64 GUEST: kernel-3.10.0-656.el7.x86_64 How reproducible:3/3 Steps to Reproduce: 1.start guest /usr/libexec/qemu-kvm \ -name 'avocado-vt-vm1' \ -sandbox off \ -machine pc \ -nodefaults \ -vga std \ -device nec-usb-xhci,id=usb1,bus=pci.0 \ -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0 \ -drive id=drive_image1,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/win2016-64-virtio-scsi.qcow2 \ -device scsi-hd,id=image1,drive=drive_image1 \ -device virtio-net-pci,mac=9a:61:62:63:64:65,id=idyscRss,vectors=4,netdev=idFoNLxt,bus=pci.0 \ -netdev tap,id=idFoNLxt \ -m 8192 \ -smp 8,cores=4,threads=1,sockets=2 \ -cpu 'SandyBridge',+kvm_pv_unhalt,hv_spinlocks=0x1fff,hv_vapic,hv_time \ -drive id=drive_cd1,if=none,snapshot=off,aio=native,cache=none,media=cdrom,file=/home/kvm_autotest_root/iso/windows/winutils.iso \ -device scsi-cd,id=cd1,drive=drive_cd1 \ -vnc :1 \ -rtc base=localtime,clock=host,driftfix=slew \ -boot order=cdn,once=c,menu=off,strict=off \ -enable-kvm \ -monitor stdio \ -device usb-hub,id=usbhub,bus=usb1.0,port=1\ -device usb-mouse,id=usbmouse,bus=usb1.0,port=1.1\ -device usb-kbd,id=usbkbd,bus=usb1.0,port=1.2\ -device usb-tablet,id=usbtablet,bus=usb1.0,port=1.3\ Actual results: win2016 guest hangs after everything loaded Expected results: win2016 guest works well Additional info: