Bug 962749
| Summary: | Guest didn't load the vmmouse driver after 'system-reset' by hmp. | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Qian Guo <qiguo> | ||||||
| Component: | qemu-kvm | Assignee: | Gerd Hoffmann <kraxel> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 7.0 | CC: | areis, chayang, hhuang, juzhang, knoel, michen, pbonzini, qiguo, rbalakri, virt-bugs, virt-maint, zhguo | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2017-03-14 13:42:24 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | 954261, 962733, 1272311, 1272312, 1293233 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
|
Description
Qian Guo
2013-05-14 11:30:42 UTC
Created attachment 747654 [details]
Log after reboot guest
There is a workaround posted in BZ 907016 for Fedora 18: https://bugzilla.redhat.com/show_bug.cgi?id=907016 that causes a rescan of the device after each resume. We should disable vmmouse/vmport, see bug 616187. That was done with RHEL-only patches. The infrastructure to do dynamic probing of devices should now be upstream, but right now removing CONFIG_VMMOUSE/CONFIG_VMPORT gives: $ x86_64-softmmu/qemu-system-x86_64 qemu-system-x86_64: Unknown device 'vmport' for bus 'ISA' Annullato (core dumped) Oops:
commit e451e54c46ead55cc179d37d0410ab6f41b0cc00
Author: Eduardo Habkost <ehabkost>
Date: Tue Feb 15 16:31:34 2011 -0200
reenable CONFIG_VMMOUSE and CONFIG_VMPORT
RH-Author: Eduardo Habkost <ehabkost>
Message-id: <20110215163134.GF29153.raisama.net>
Patchwork-id: 18223
O-Subject: [RHEL6 qemu-kvm PATCH] reenable CONFIG_VMMOUSE and CONFIG_VMPORT
Bugzilla: 677712
So we need them anyway for the 6.x machine types.
Doesn't reproduce, please retest with latest qemu-kvm. (In reply to Gerd Hoffmann from comment #6) > Doesn't reproduce, please retest with latest qemu-kvm. Hi Qiguo, Could you have a test and update the result in the bz? Best Regards, Junyi Reproduced by my side: # uname -r 3.10.0-61.el7.x86_64 # rpm -q qemu-kvm qemu-kvm-1.5.3-21.el7.x86_64 Steps: 1.Boot rhel7 guest: # /usr/libexec/qemu-kvm -M pc -enable-kvm -m 4096 -smp 4,sockets=1,cores=4,threads=1 -name rhel7 -drive file=/home/rhel7/rhel7.qcow3,if=none,id=drive-ide1-1-0,format=qcow2,werror=stop,rerror=stop,aio=threads -device ide-drive,bus=ide.1,drive=drive-ide1-1-0,id=ide1-1-0 -vnc :10 -vga qxl -monitor stdio -nodefaults -nodefconfig -device virtio-balloon-pci,id=balloon1 -netdev tap,id=netdev1,script=/etc/qemu-ifup -device virtio-net-pci,netdev=netdev1,id=vnic1,mac=54:52:1a:23:0b:01 2.Inside guest do netperf UDP_STREAM test, at this time, the guest will hang (refer to bug #962733) 3.During the guest hanging, reboot guest via (qemu)system_reset Result: after guest reboot up, the mouse is out of control, and from guest check the mouse # vmmouse_detect ; echo $? 1 and from hmp: (qemu) info mice * Mouse #0: QEMU PS/2 Mouse so this bug is reproduced. Hi,
> 2.Inside guest do netperf UDP_STREAM test, at this time, the guest will hang
> (refer to bug #962733)
Where does this come from? That isn't in the original report.
Is this needed to trigger the bug?
In the description, I wrote this > Description of problem: > Guest will out of control when test UDP_STREAM w/o vhost=on (bug #962733), > and if try 'system-reset' by hmp, after bootup, the mouse can not used, from > guest, found this info: the bug #962733 reports that the guest hangs. sorry that not make so clear in this bug, hope this helps. Thanks, Can you re-test whenever this still happens with 7.3 guests? guest-side vmmouse handling has changed in 7.3 (uses a kernel driver now), so there is a chance this doesn't happen any more ... (In reply to Gerd Hoffmann from comment #18) > Can you re-test whenever this still happens with 7.3 guests? > > guest-side vmmouse handling has changed in 7.3 (uses a kernel driver now), > so there is a chance this doesn't happen any more ... Hi Zhiyi, Could you handle this issue? Best Regards, Junyi Test against rhel7.3 host with kernel 3.10.0-514.el7.x86_64 and qemu-kvm-1.5.3-126.el7_3.3.x86_64, issue still can be reproduced.
The reproduce rate is 4/10.
Steps:
1. boot guest with cmd:
/usr/libexec/qemu-kvm -m 4096 -smp 4,sockets=1,cores=4,threads=1 -name rhel7 -drive file=/home/rhel7.3-create-user.qcow2,if=none,id=drive-ide1-1-0,format=qcow2,cache=none,werror=stop,rerror=stop,aio=threads -device ide-drive,bus=ide.1,drive=drive-ide1-1-0,id=ide1-1-0 -vnc :0 -vga qxl -monitor stdio -device virtio-balloon-pci,id=balloon1 -netdev tap,id=netdev1,script=/etc/qemu-ifup -device virtio-net-pci,netdev=netdev1,id=vnic1,mac=54:52:1a:23:0b:01 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -serial unix:/tmp/console,server,nowait
2.Query vmmouse device from guest and there are two vmmouse:
I: Bus=0011 Vendor=0002 Product=0012 Version=5868
N: Name="VirtualPS/2 VMware VMMouse"
P: Phys=isa0060/serio1/input1
S: Sysfs=/devices/platform/i8042/serio1/input/input2
U: Uniq=
H: Handlers=mouse0 event2
B: PROP=0
B: EV=b
B: KEY=70000 0 0 0 0
B: ABS=3
I: Bus=0011 Vendor=0002 Product=0012 Version=5868
N: Name="VirtualPS/2 VMware VMMouse"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input3
U: Uniq=
H: Handlers=mouse1 event3
B: PROP=1
B: EV=7
B: KEY=30000 0 0 0 0
B: REL=103
Use a new xorg.conf to configure Xorg to use vmmouse and reboot, content example:
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" "/devices/platform/i8042/serio1/input/input3"
Option "ZAxisMapping" "4 5 6 7"
EndSection
3. Execute "info mice" from hmp:
(qemu) info mice
Mouse #0: QEMU PS/2 Mouse
* Mouse #1: vmmouse (absolute)
4. launch download netperf 2.7 and launch ./netserver from host
5. Do net perf test inside guest to interact with host netserver:
netperf -H host_ip -t UDP_STREAM -l 30
6. system_reset from hmp
7. reconnect to guest
Results:
After step 6, mouse cannot interact with guest.
Execute "info mice" from hmp, only ps/2 mouse there:
(qemu) info mice
* Mouse #0: QEMU PS/2 Mouse
(qemu) info mice
* Mouse #0: QEMU PS/2 Mouse
SSH to guest and recheck vmmouse device list, only one vmmouse left and it become to input2
Hmm, I guess this means we'll go continue waiting for bug 962733 getting fixed. Does this also happen with qemu-kvm-rhev? With the same steps, I really cannot reproduce this issue in 20 trials against qemu-kvm-rhev-2.6.0-28.el7_3.3.x86_64. In vhost on/off, guest always response smooth after "netperf -H host_ip -t UDP_STREAM -l 30", and from my trial vmmouse always work. During yesterday qemu-kvm test, vmmouse always work too without "netperf -H host_ip -t UDP_STREAM -l 30" given that
(a) customers apparently don't hit this (probably due to netperf test being
needed to actually trigger this).
(b) newer qemu versions seem not to be affected
I think we can consider closing this as wontfix.
areis?
(In reply to Gerd Hoffmann from comment #23) > given that > (a) customers apparently don't hit this (probably due to netperf test being > needed to actually trigger this). > (b) newer qemu versions seem not to be affected > I think we can consider closing this as wontfix. > areis? Agree. Also, we don't support HMP. |