Bug 1449991

How reproducible: 4/4

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!

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.

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

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

Hi Haotong, please try this one:
https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=13214695

Thanks,
Ladi

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

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.

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

The fix has been merged upstream as

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

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.

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