Hide Forgot
Description of problem: The usb tablet in rhel7 supports usb 2.0, so we better make sure our usb2 host adapter emulation can handle remote wakeup. The ehci emulation has adaptive wakeup rate, so the effect of missing remote wakeup support isn't as bad as it is with usb 1.1 (uhci), but still ...
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=e489df40caa96d895d9672d77f536f23c9e42f94 http://git.qemu.org/?p=qemu.git;a=commitdiff;h=690af06aebdfd043a6222de96a535dcba2144caf
patches posted.
Hi Gerd, Could you provide a efficiently for QE reproduce and verify this bug? Does this bug need special hardware? Best Regards, Junyi
(In reply to juzhang from comment #3) > Hi Gerd, > > Could you provide a efficiently for QE reproduce and verify this bug? Does > this bug need special hardware? No special hardware needed. The wakeup rate for a idle guest should go down. Boot rhel7 guest, with usb-tablet connected to ehci, let it sit around idle, check the wakeups/second qemu has with powertop.
Thanks Gerd.
Fix included in qemu-kvm-1.5.3-36.el7
Test(In reply to Gerd Hoffmann from comment #4) > (In reply to juzhang from comment #3) > > Hi Gerd, > > > > Could you provide a efficiently for QE reproduce and verify this bug? Does > > this bug need special hardware? > > No special hardware needed. The wakeup rate for a idle guest should go down. > Boot rhel7 guest, with usb-tablet connected to ehci, let it sit around idle, > check the wakeups/second qemu has with powertop. Hi Gerd I test this with kernel-3.10.0-84.el7.x86_64 and qemu-kvm-1.5.3-45.el7.x86_64 Steps: 1.Just start a rhel7 guest (same kernel with host): # /usr/libexec/qemu-kvm -cpu Penryn -m 4G -smp 2,sockets=1,cores=2,threads=1 -M pc -enable-kvm -name test -rtc base=localtime,clock=host,driftfix=slew -drive file=/home/rhel7base.qcow2_v3,if=none,format=qcow2,werror=stop,rerror=stop,media=disk,id=drive-scsi0-disk0 -device virtio-scsi-pci,id=scsi0 -device scsi-hd,scsi-id=0,lun=0,bus=scsi0.0,drive=drive-scsi0-disk0,id=virtio-disk0 -nodefaults -nodefconfig -monitor stdio -netdev tap,id=netdev,script=/etc/qemu-ifup -device virtio-net-pci,netdev=netdev,mac=54:52:1a:46:0b:01,id=vnic1 -vnc :10 -vga std -device usb-ehci,id=ehci -device usb-tablet,bus=ehci.0 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 2.after guest bootup, monitor powertop in host, I am watching it every 2s: # powertop --time=2 But the wakeups/second seams not Stable of the qemu process, most times it was below 1 ms/s (from 30μs to 600μs), and sometime it reach more than 1 ms/s. I am not sure if this is the right result that you want, so could help check and tell me how to test it? Additional info, that I test this with qemu-kvm-1.5.3-30.el7.x86_64 with same guest, the result is close to above.
Second column (Events/s ) is the wakeup rate.
(In reply to Gerd Hoffmann from comment #9) > Second column (Events/s ) is the wakeup rate. Got it, I will retest it. thanks
(In reply to Gerd Hoffmann from comment #9) > Second column (Events/s ) is the wakeup rate. Hi Gerd I retest it with both qemu-kvm-1.5.3-30.el7.x86_64 and qemu-kvm-1.5.3-48.el7.x86_64, steps are same as comment #8, and the followings are reseults: 1.Test with qemu-kvm-1.5.3-30.el7.x86_64, after boot rhel7 guest fro a while, the Events/s go down and stayed as 9 around, : ... PowerTOP 2.3 Overview Idle stats Frequency stats Device stats Tunables Summary: 42.4 wakeups/second, 0.0 GPU ops/seconds, 0.0 VFS ops/sec and 0.4% CPU use Usage Events/s Category Description 625.1 us/s 8.8 Process /usr/libexec/qemu-kvm -cpu Penryn -m 4G -smp 2,sockets=1,cores=2,thread -------------- 2.Test with qemu-kvm-1.5.3-48.el7.x86_64, after boot rhel7 guest fro a while, the Events/s go down and stayed as 9 around, : PowerTOP 2.3 Overview Idle stats Frequency stats Device stats Tunables Summary: 43.6 wakeups/second, 0.0 GPU ops/seconds, 0.0 VFS ops/sec and 0.4% CPU use Usage Events/s Category Description 0.7 ms/s 9.0 Process /usr/libexec/qemu-kvm -cpu Penryn -m 4G -smp 2,sockets=1,cores=2,thread According to above, it seams that there's not so much different between these two builds. Gerd, could you help check it, if this is the expected result, we will set it as verified.
Wakeup rate for the fixed version is fine. I'd expected the wakeup rate for the old version being higher though. Hmm. Can you attach the "lspci -v" output for the usb-tablet for both qemu versions?
(In reply to Gerd Hoffmann from comment #12) > Wakeup rate for the fixed version is fine. I'd expected the wakeup rate for > the old version being higher though. Hmm. > > Can you attach the "lspci -v" output for the usb-tablet for both qemu > versions? Test with qemu-kvm-1.5.3-48.el7.x86_64, in guest, check following infos: # lspci |grep EHCI 00:05.0 USB controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 10) # lspci -vvvv -s 00:05.0 00:05.0 USB controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 10) (prog-if 20 [EHCI]) Subsystem: Red Hat, Inc Device 1100 Physical Slot: 5 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin D routed to IRQ 11 Region 0: Memory at febd3000 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: ehci-pci ---------------------------- Test with qemu-kvm-1.5.3-48.el7.x86_64, in guest, check following infos: # lspci |grep EHCI 00:05.0 USB controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 10) # lspci -vvvv -s 00:05.0 00:05.0 USB controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 10) (prog-if 20 [EHCI]) Subsystem: Red Hat, Inc Device 1100 Physical Slot: 5 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin D routed to IRQ 11 Region 0: Memory at febd3000 (32-bit, non-prefetchable) [size=4K] Kernel driver in use: ehci-pci
Opps, I've meant "ls*usb* -v" output (for the us-tablet). Sorry.
(In reply to Gerd Hoffmann from comment #14) > Opps, I've meant "ls*usb* -v" output (for the us-tablet). Sorry. Ok, I will check it and update here
Created attachment 865886 [details] Test and get the lsusb when qemu-kvm is 30 build
Created attachment 865887 [details] Test and get the lsusb when qemu-kvm is 48 build
Hi, Gerd Have paste the attachments with the infos you want, if anything lost, pls let me know. thanks,
Hmm, strange, remote wakeup is listed in both ... /me wades through git history. Ah, the two patches needed to fix this have been applied to different builds. That explains it. Can you use qemu-kvm-1.5.3-20.el7 instead of qemu-kvm-1.5.3-30.el7 please? Then you should actually see a difference in the wakeup rate.
(In reply to Gerd Hoffmann from comment #19) > Hmm, strange, remote wakeup is listed in both ... > > /me wades through git history. Ah, the two patches needed to fix this have > been applied to different builds. That explains it. Can you use > qemu-kvm-1.5.3-20.el7 instead of qemu-kvm-1.5.3-30.el7 please? Then you > should actually see a difference in the wakeup rate. Hi Gerd Thanks for your help, I just test qemu-kvm-1.5.3-20.el7 , the same cli like comment #8 and same guest, same host, after guest boot up and stays idle, check the status of wakeup rate, it prints like this:: PowerTOP 2.3 Overview Idle stats Frequency stats Device stats Tunables Summary: 63.9 wakeups/second, 0.0 GPU ops/seconds, 0.0 VFS ops/sec and 0.8% CPU use Usage Events/s Category Description 4.8 ms/s 31.2 Process /usr/libexec/qemu-kvm -cpu Penryn -m 4G -smp 2,sockets=1,cores=2,thread the wakeup rate is between 20 and 40 , so this bug is reproduced by qemu-kvm-1.5.3-20.el7. According to above and comment #11, this bug is fixed by qemu-kvm-1.5.3-48.el7.x86_64.
Hi, Gerd Does the result of comment #20 good to you, just double confirm with you : ) thanks,
(In reply to Qian Guo from comment #21) > Hi, Gerd > > Does the result of comment #20 good to you, just double confirm with you : ) > > thanks, Yes, looks good.
This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request.