Bug 1449991 - [rhel7.4][usb-hub]usb kdb doesn't work under 2 tier usb hubs with xhci contronnler for win2016 guest
Summary: [rhel7.4][usb-hub]usb kdb doesn't work under 2 tier usb hubs with xhci contro...
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.4
Hardware: x86_64
OS: Windows
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Virtualization Maintenance
QA Contact: Gu Nini
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 1473046
TreeView+ depends on / blocked
 
Reported: 2017-05-11 10:17 UTC by hachen
Modified: 2018-04-11 00:21 UTC (History)
14 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2018-04-11 00:19:31 UTC


Attachments (Terms of Use)
after this point,input devices did not work any more. (73.27 KB, image/png)
2017-05-11 10:17 UTC, hachen
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:1104 None None None 2018-04-11 00:21 UTC

Description hachen 2017-05-11 10:17:41 UTC
Created attachment 1277820 [details]
after this point,input devices did not work any more.

Description of problem:
In win2016 guest,input devices (usb-kbd, usb-tablet,usb-mouse) don't work under one usb hub with xhci contronnler.

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:
win2016

How reproducible:


Steps to Reproduce:
1.start guest with qemu
 /usr/libexec/qemu-kvm \
    -name 'avocado-vt-vm1'  \
    -sandbox off  \
    -machine pc  \
    -nodefaults  \
    -vga std  \
    -device pvpanic,ioport=0x505,id=id4FzGzg  \
    -device nec-usb-xhci,id=controller,bus=pci.0,addr=0x7 \
    -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=0x3 \
    -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:4e:4f:50:51:52,id=idH8iBKj,vectors=4,netdev=iduyb7Wr,bus=pci.0,addr=0x4  \
    -netdev tap,id=iduyb7Wr \
    -m 8192  \
    -smp 4,cores=2,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 :0  \
    -rtc base=localtime,clock=host,driftfix=slew  \
    -boot order=cdn,once=c,menu=off,strict=off \
    -enable-kvm \
    -monitor stdio \
    -qmp tcp:localhost:4444,server,nowait \
    -device usb-hub,id=usbhub,bus=controller.0,port=1\
    -device usb-mouse,id=usbmouse,port=1.1\
    -device usb-kbd,id=usbkbd,port=1.2\
    -device usb-tablet,id=usbtablet,port=1.3\

2. After everything loaded, the input devices did not work.
 

Actual results:
After everything loaded, the input devices did not work
In fact, the mouse was wroking (right and left clicks),but after everthing loead( the attached screen shot), it did not work anymore.
The kbd did not work from every beginning.

Expected results:
After everything loaded, the input devices work

Additional info:
Win7 guest has this problem as well.
Input devices did not work from every beginning.

I had a go with:
rhel guest:kernel-3.10.0-656.el7.x86_64, input devices work well.

Comment 2 hachen 2017-05-11 10:19:39 UTC
How reproducible: 4/4

Comment 3 Ladi Prosek 2017-05-15 08:06:44 UTC
How is this different from bug 1447581?

If you move the mouse and press keys all the way through boot, you should see them work. They stop working only after a few seconds of inactivity. Thanks!

Comment 4 hachen 2017-05-15 09:05:54 UTC
Sorry,my fault.I forgot the bug 1447581.

(In reply to Ladi Prosek from comment #3)
> How is this different from bug 1447581?
> 
> If you move the mouse and press keys all the way through boot, you should
> see them work. They stop working only after a few seconds of inactivity.
> Thanks!

I moved the mouse all the way, it stops working after everything loaded. And it did not work after 10 minutes.

In fact,there was a windows white cursor under the linux's black one during the boot. But,after everything was loaded, the white cursor disappeared.And the mouse did not work from this time.

During the time the mouse was working, I tried to type some letters, but the kbd did not work from the very beginning. 

Today, I run another test case, using qemu:
 /usr/libexec/qemu-kvm \
    -name 'avocado-vt-vm1'  \
    -sandbox off  \
    -machine pc  \
    -nodefaults  \
    -vga std  \
    -device pvpanic,ioport=0x505,id=id4FzGzg  \
    -device nec-usb-xhci,id=controller,bus=pci.0,addr=0x7 \
    -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=0x3 \
    -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:4e:4f:50:51:52,id=idH8iBKj,vectors=4,netdev=iduyb7Wr,bus=pci.0,addr=0x4  \
    -netdev tap,id=iduyb7Wr \
    -m 8192  \
    -smp 4,cores=2,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 \
    -device usb-tablet,id=usb-tablet1,bus=controller.0,port=2  \  <--port2
    -vnc :0  \
    -rtc base=localtime,clock=host,driftfix=slew  \
    -boot order=cdn,once=c,menu=off,strict=off \
    -enable-kvm \
    -monitor stdio \
    -qmp tcp:localhost:4444,server,nowait \
    -device usb-mouse,id=mouse1,bus=controller.0                 <--port1
    -device usb-mouse,id=mouse2,bus=controller.0                 <--port3
    -device usb-mouse,id=mouse3,bus=controller.0                 <--port4.1

qemu automatically adds a hub on port4 and attached the mouse3 onto that hub.
(qemu) info usb
  Device 0.4, Port 2, Speed 480 Mb/s, Product QEMU USB Tablet, ID: usb-tablet1
  Device 0.1, Port 1, Speed 480 Mb/s, Product QEMU USB Mouse, ID: mouse1
  Device 0.3, Port 3, Speed 480 Mb/s, Product QEMU USB Mouse, ID: mouse2
  Device 0.2, Port 4, Speed 12 Mb/s, Product QEMU USB Hub
  Device 0.5, Port 4.1, Speed 12 Mb/s, Product QEMU USB Mouse, ID: mouse3

Then this bug happened again.I am not sure if it is because the the port goes into suspend.But it works fine if I explicitly assign mouse1 mouse2 and mouse3 to port1, port3 and port4 respectively.

Yeah, you are right in bz1447581#c4. It appears 'hung' as I found the timer was working.
You can mark it as a duplicate for the bug 1447581,if they are same.
Thanks.

Comment 6 hachen 2017-05-17 05:53:04 UTC
    -device usb-hub,id=usbhub,bus=controller.0,port=1\
    -device usb-hub,id=usbhub1,port=1.1\
    -device usb-mouse,id=usbmouse,port=1.1.1\
    -device usb-kbd,id=usbkbd,port=1.1.2\

(qemu) info usb
  Device 0.2, Port 2, Speed 480 Mb/s, Product QEMU USB Tablet, ID: usb-tablet1
  Device 0.1, Port 1, Speed 12 Mb/s, Product QEMU USB Hub, ID: usbhub
  Device 0.3, Port 1.1, Speed 12 Mb/s, Product QEMU USB Hub, ID: usbhub1
  Device 0.4, Port 1.1.1, Speed 12 Mb/s, Product QEMU USB Mouse, ID: usbmouse
  Device 0.6, Port 1.1.2, Speed 12 Mb/s, Product QEMU USB Keyboard, ID: usbkbd
  Device 0.5, Port 1.1.3, Speed 12 Mb/s, Product QEMU USB Tablet, ID: usbtablet

If it has one hue under another hub, the mouse works whereas the kbd not.
I will have a try with new build mentioned in the #comment 5.

Comment 7 hachen 2017-05-19 09:48:17 UTC
Sorry Ladi,I did not save the build you provided in comment 5.
Now it is cloesd.
Could you please provide another build that fixed this issue?
Many thanks.
Haotong

Comment 8 Ladi Prosek 2017-05-19 09:55:52 UTC
Hi Haotong, please try this one:
https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=13214695

Thanks,
Ladi

Comment 9 hachen 2017-05-22 02:47:29 UTC
Hi Ladi,

Having tried the build provide in the comment 8, it works fine for the comment 0 and the comment 4.

However, as in the comment 6, under two tier hubs, the usb kdb does not work.


I tired 3 tier hubs,got the same result mentioned in the comment 6.
    ....
    -qmp tcp:localhost:4444,server,nowait 
    -device usb-hub,id=usbhub,bus=controller.0,port=1\
    -device usb-hub,id=usbhub1,port=1.1\
    -device usb-hub,id=usbhub2,port=1.1.1\
    -device usb-mouse,id=usbmouse,port=1.1.1.1\
    -device usb-kbd,id=usbkbd,port=1.1.1.2\

(qemu) info usb
  Device 0.2, Port 2, Speed 480 Mb/s, Product QEMU USB Tablet, ID: usb-tablet1
  Device 0.1, Port 1, Speed 12 Mb/s, Product QEMU USB Hub, ID: usbhub
  Device 0.3, Port 1.1, Speed 12 Mb/s, Product QEMU USB Hub, ID: usbhub1
  Device 0.4, Port 1.1.1, Speed 12 Mb/s, Product QEMU USB Hub, ID: usbhub2
  Device 0.5, Port 1.1.1.1, Speed 12 Mb/s, Product QEMU USB Mouse, ID: usbmouse
  Device 0.6, Port 1.1.1.2, Speed 12 Mb/s, Product QEMU USB Keyboard, ID: usbkbd


So I think this fix works for bz 1447581.
I will change this bug's summary.

Thanks,
Haotong

Comment 10 Ladi Prosek 2017-05-22 08:31:39 UTC
Hi Haotong,

(In reply to hachen from comment #9)
> Hi Ladi,
> 
> Having tried the build provide in the comment 8, it works fine for the
> comment 0 and the comment 4.
> 
> However, as in the comment 6, under two tier hubs, the usb kdb does not work.

Thanks! Yes, this is a different bug indeed. It depends on the timing of wakeups of the hub connected devices and mouse tends to be woken up before keyboard so it usually reproduces with usb kdb.

It looks like we're still missing some operations on the wakeup path. The first device (mouse in your case) is woken up remotely by generating input events. Windows then issues ClearPortFeature(PORT_SUSPEND) for the other port where keyboard is connected. It waits for the PORT_STAT_C_SUSPEND flag to get set for that port and it's not happening in the current implementation.

Comment 11 Ladi Prosek 2017-05-22 13:08:14 UTC
I have posted [PATCH] usb-hub: set PORT_STAT_C_SUSPEND on host-initiated wake-up
to upstream QEMU to fix this. It is not a regression and not a common way to configure USB input devices so I'm not going to push for a RHEL 7.4 backport. Feel free to move the BZ back to 7.4 if you think that it is a blocker. Thanks!

https://lists.nongnu.org/archive/html/qemu-devel/2017-05/msg04897.html

Comment 12 Ladi Prosek 2017-08-31 07:19:06 UTC
The fix has been merged upstream as

  6361bbc usb-hub: set PORT_STAT_C_SUSPEND on host-initiated wake-up

Comment 14 Gu Nini 2017-10-11 08:45:34 UTC
With the usb setup in comment 6 and comment 9:

Reproduced the bug on qemu-kvm-rhev-2.9.0-16.el7_4.9.x86_64, verified the bug on qemu-kvm-rhev-2.10.0-1.el7.x86_64, i.e. guest keyboard turned to work on the newer qemu version under 2 and 3 tiers usb hub connection.

Comment 18 errata-xmlrpc 2018-04-11 00:19:31 UTC
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-2018:1104


Note You need to log in before you can comment on or make changes to this bug.