Description of problem: When attach multiple usb devices eg. 6 or more usb-mouses under a usb hub, one of usb devices under is not recognized by win2016 guest Version-Release number of selected component (if applicable): Host kernel : kernel-3.10.0-693.el7.x86_64 qemu: qemu-kvm-rhev-2.9.0-16.el7_4.9.x86_64 (it seems not 100% reproducible) qemu-kvm-rhev-2.9.0-16.el7_4.5.x86_64 (100% reproducible) How reproducible: Steps to Reproduce: 1. boot guest with /usr/libexec/qemu-kvm \ -name 'avocado-vt-vm1' \ -sandbox off \ -machine pc \ -nodefaults \ -vga std \ -device pvpanic,ioport=0x505,id=idAZN8Ia \ -device nec-usb-xhci,id=usbtest,bus=pci.0,addr=0x3 \ -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=0x4 \ -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:e4:e5:e6:e7:e8,id=idOCesHt,vectors=4,netdev=id4lq6hH,bus=pci.0,addr=0x5 \ -netdev tap,id=id4lq6hH,vhost=on \ -m 8192 \ -smp 4,cores=2,threads=1,sockets=2 \ -cpu 'Westmere',+kvm_pv_unhalt,hv_relaxed,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 \ -device usb-hub,id=usb-d0,bus=usbtest.0,port=1 \ -device usb-mouse,id=usb-d1,bus=usbtest.0,port=1.1 \ -device usb-mouse,id=usb-d2,bus=usbtest.0,port=1.2 \ -device usb-mouse,id=usb-d3,bus=usbtest.0,port=1.3 \ -device usb-mouse,id=usb-d4,bus=usbtest.0,port=1.4 \ -device usb-mouse,id=usb-d5,bus=usbtest.0,port=1.5 \ -device usb-mouse,id=usb-d6,bus=usbtest.0,port=1.6 \ -device usb-mouse,id=usb-d7,bus=usbtest.0,port=1.7 \ -device usb-mouse,id=usb-d8,bus=usbtest.0,port=1.8 \ -vnc :0 \ -rtc base=localtime,clock=host,driftfix=slew \ -boot menu=off,strict=off,order=cdn,once=c \ -enable-kvm \ -monitor stdio \ 2. info usb QEMU 2.9.0 monitor - type 'help' for more information (qemu) info usb Device 0.1, Port 1, Speed 12 Mb/s, Product QEMU USB Hub, ID: usb-d0 Device 0.2, Port 1.1, Speed 12 Mb/s, Product QEMU USB Mouse, ID: usb-d1 Device 0.9, Port 1.2, Speed 12 Mb/s, Product QEMU USB Mouse, ID: usb-d2 Device 0.8, Port 1.3, Speed 12 Mb/s, Product QEMU USB Mouse, ID: usb-d3 Device 0.7, Port 1.4, Speed 12 Mb/s, Product QEMU USB Mouse, ID: usb-d4 Device 0.6, Port 1.5, Speed 12 Mb/s, Product QEMU USB Mouse, ID: usb-d5 Device 0.5, Port 1.6, Speed 12 Mb/s, Product QEMU USB Mouse, ID: usb-d6 Device 0.4, Port 1.7, Speed 12 Mb/s, Product QEMU USB Mouse, ID: usb-d7 Device 0.3, Port 1.8, Speed 12 Mb/s, Product QEMU USB Mouse, ID: usb-d8 3. login to win2016 guest, run cmd: wmic path Win32_USBControllerDevice get Dependent | find "USB" C:\>wmic path Win32_USBControllerDevice get Dependent | find "USB" \\WIN-VGMLPPUT9E5\root\cimv2:Win32_PnPEntity.DeviceID="USB\ROOT_HUB30\4&8703BE7&0&0" \\WIN-VGMLPPUT9E5\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0409&PID_55AA\MSFT20314159-0000:00:03.0-1" \\WIN-VGMLPPUT9E5\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0000&PID_0000\6&15E6C34A&0&3" <-------- not recognized \\WIN-VGMLPPUT9E5\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0627&PID_0001\42" \\WIN-VGMLPPUT9E5\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0627&PID_0001\6&15E6C34A&0&2" \\WIN-VGMLPPUT9E5\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0627&PID_0001\6&15E6C34A&0&4" \\WIN-VGMLPPUT9E5\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0627&PID_0001\6&15E6C34A&0&1" \\WIN-VGMLPPUT9E5\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0627&PID_0001\6&15E6C34A&0&8" \\WIN-VGMLPPUT9E5\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0627&PID_0001\6&15E6C34A&0&6" \\WIN-VGMLPPUT9E5\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0627&PID_0001\6&15E6C34A&0&5" If you check the 'Device manager' or 'control panel', there was only 7 usb mouses. Actual results: Expected results: All devices are recognized Additional info: Tried 3 times on: kernel-3.10.0-749.el7.x86_64 qemu-kvm-rhev-2.10.0-3.el7.x86_64 It did not happen
> Additional info: > Tried 3 times on: > kernel-3.10.0-749.el7.x86_64 > qemu-kvm-rhev-2.10.0-3.el7.x86_64 > It did not happen So we can close it as it is already fixed for 7.5, right? (I don't think we need a 7.4.z backport)
Created attachment 1346393 [details] Boot_up_with_tablet.png (In reply to Gerd Hoffmann from comment #2) > > So we can close it as it is already fixed for 7.5, right? > (I don't think we need a 7.4.z backport) Met the issue on RHEL7.5 with the same steps in bug Description but add a tablet '-device usb-tablet,id=usb-tablet,port=2': qemu-kvm-rhev-2.10.0-3.el7.x86_64 Host kernel 3.10.0-748.el7.x86_64 Besides the bug issue, there is following problems: 1. More than one usb input device might be not recognized in the control panel 2. The usb tablet takes no effect here Please check the attached screenshots for more details.
Created attachment 1346394 [details] After_hotunplug_tablet.png
(In reply to Gu Nini from comment #3) > > > Besides the bug issue, there is following problems: > 1. More than one usb input device might be not recognized in the control > panel > 2. The usb tablet takes no effect here Please note with a tablet, it's easy to reproduce the bug. And for the tablet takes no effect issue, should we report another bug? > > Please check the attached screenshots for more details.
https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=14547812 can you try if that build improves things?
(In reply to Gerd Hoffmann from comment #6) > https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=14547812 > can you try if that build improves things? Yes, it turns well, i.e. all usb device could be found under 'Hardware' of 'Control Panel' and in cmd wmic output. However, the usb tablet taking no effect issue still exists; and it's found if boot up guest with 2 or more mouses besides the tablet, there would be the issue. (qemu) info usb Device 0.1, Port 1, Speed 480 Mb/s, Product QEMU USB Tablet, ID: usb-e1 Device 0.2, Port 2, Speed 480 Mb/s, Product QEMU USB Mouse, ID: usb-d2 Device 0.3, Port 3, Speed 480 Mb/s, Product QEMU USB Mouse, ID: usb-d3
> However, the usb tablet taking no effect issue still exists; and it's found > if boot up guest with 2 or more mouses besides the tablet, there would be > the issue. What does "info mice" print then?
(In reply to Gerd Hoffmann from comment #8) > > However, the usb tablet taking no effect issue still exists; and it's found > > if boot up guest with 2 or more mouses besides the tablet, there would be > > the issue. > > What does "info mice" print then? I have reported new bz1513861 to track the issue. The bug also occurred on linux guest, following is the 'info mice' output for a linux guest. (qemu) info mice Mouse #2: QEMU PS/2 Mouse Mouse #4: QEMU HID Mouse Mouse #5: vmmouse (absolute) Mouse #3: QEMU HID Tablet (absolute) * Mouse #6: QEMU HID Mouse
> (qemu) info mice > Mouse #2: QEMU PS/2 Mouse > Mouse #4: QEMU HID Mouse > Mouse #5: vmmouse (absolute) > Mouse #3: QEMU HID Tablet (absolute) > * Mouse #6: QEMU HID Mouse As expected. The tablet isn't the active pointer device. If you switch to the tablet ("mouse_set 3" in monitor) it starts working I guess?
(In reply to Gerd Hoffmann from comment #10) > > (qemu) info mice > > Mouse #2: QEMU PS/2 Mouse > > Mouse #4: QEMU HID Mouse > > Mouse #5: vmmouse (absolute) > > Mouse #3: QEMU HID Tablet (absolute) > > * Mouse #6: QEMU HID Mouse > > As expected. The tablet isn't the active pointer device. > > If you switch to the tablet ("mouse_set 3" in monitor) it starts working I > guess? Yes, it works. Should we use the 'mouse_set' cmd in the test scenario? But it seems there is no corresponding qmp cmd.
(In reply to Gu Nini from comment #11) > (In reply to Gerd Hoffmann from comment #10) > > > (qemu) info mice > > > Mouse #2: QEMU PS/2 Mouse > > > Mouse #4: QEMU HID Mouse > > > Mouse #5: vmmouse (absolute) > > > Mouse #3: QEMU HID Tablet (absolute) > > > * Mouse #6: QEMU HID Mouse > > > > As expected. The tablet isn't the active pointer device. > > > > If you switch to the tablet ("mouse_set 3" in monitor) it starts working I > > guess? > > > Yes, it works. Should we use the 'mouse_set' cmd in the test scenario? But > it seems there is no corresponding qmp cmd. Depends on what you want to test ... If you want test the usb-tablet, then attach it as the only usb input device. If you want test whenever many usb devices work correctly you can use a bunch of usb input devices for that. They should all be visible in the guest (lspci), the guest driver should load and initialize, you can verify that. But you can't expect that mouse events are routed to a specific device. It depends on the order the guest initializes the devices which of them receives the events.
> > Yes, it works. Should we use the 'mouse_set' cmd in the test scenario? But > > it seems there is no corresponding qmp cmd. > > Depends on what you want to test ... > > If you want test the usb-tablet, then attach it as the only usb input device. > > If you want test whenever many usb devices work correctly you can use a > bunch of usb input devices for that. They should all be visible in the > guest (lspci), the guest driver should load and initialize, you can verify > that. But you can't expect that mouse events are routed to a specific > device. It depends on the order the guest initializes the devices which of > them receives the events. Closing as notabug now. If you see behavior not matching what I described above feel free to reopen the bug with additional information.
upstream commit b63e10508bee7169cfc7022805638c7358feefb5 HID devices get unique serial numbers, which should fix this one. Needs new machine type, so something to pick up by the next rebase.
Hi All: I am verifying this Bug. The original bug happened on RHEL7 and the fix version is on RHEL8. Thus, I would not to reproduce the original bug. Just verify the fix version on RHEL8. Test Version: [1]4.18.0-139.el8.x86_64 [2]qemu-kvm-4.1.0-5.module+el8.1.0+4076+b5e41ebc.x86_64 Follow those steps verify this Bug: [1] Boot Windows 2016 guest. Add one usb hub and attach 8 usb-mouse on the hub. /usr/libexec/qemu-kvm -M q35 -cpu EPYC -enable-kvm -m 7G -smp 4 -nodefaults \ ... ... -device qemu-xhci,id=xhci1,bus=pcie.0-root-port-4,addr=0x0 \ -device usb-hub,id=usb-d0,bus=xhci1.0,port=1 \ -device usb-mouse,id=usb-d1,bus=xhci1.0,port=1.1 \ -device usb-mouse,id=usb-d2,bus=xhci1.0,port=1.2 \ -device usb-mouse,id=usb-d3,bus=xhci1.0,port=1.3 \ -device usb-mouse,id=usb-d4,bus=xhci1.0,port=1.4 \ -device usb-mouse,id=usb-d5,bus=xhci1.0,port=1.5 \ -device usb-mouse,id=usb-d6,bus=xhci1.0,port=1.6 \ -device usb-mouse,id=usb-d7,bus=xhci1.0,port=1.7 \ -device usb-mouse,id=usb-d8,bus=xhci1.0,port=1.8 \ [2] Verify usb mouse inside the windows. "device manager" and "control panel" have 8 usb mouse. run cmd: wmic path Win32_USBControllerDevice get Dependent | find "USB" \\WIN-2BGVQIBLM0S\root\cimv2:Win32_PnPEntity.DeviceID="USB\ROOT_HUB30\S&38584F00&0&0" \\WIN-2BGVQIBLM0S\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0409&PID_SSAA\MSFT20314159-0000:00:04.0:00.0-1" \\WIN-2BGVQIBLM0S\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0409&PID_0001\89126-0000:00:04.0:00.0-1.2" \\WIN-2BGVQIBLM0S\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0409&PID_0001\89126-0000:00:04.0:00.0-1.3" \\WIN-2BGVQIBLM0S\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0409&PID_0001\89126-0000:00:04.0:00.0-1.4" \\WIN-2BGVQIBLM0S\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0409&PID_0001\89126-0000:00:04.0:00.0-1.5" \\WIN-2BGVQIBLM0S\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0409&PID_0001\89126-0000:00:04.0:00.0-1.6" \\WIN-2BGVQIBLM0S\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0409&PID_0001\89126-0000:00:04.0:00.0-1.7" \\WIN-2BGVQIBLM0S\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0409&PID_0001\89126-0000:00:04.0:00.0-1.8" \\WIN-2BGVQIBLM0S\root\cimv2:Win32_PnPEntity.DeviceID="USB\VID_0409&PID_0001\89126-0000:00:04.0:00.0-1.1" Every device were recognized. Every thing looks fine. Mark this Bug as Verified. Thanks
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/RHBA-2019:3723