reproduce on qemu-kvm-0.12.1.2-2.185.el6.x86_64 kernel: 2.6.32-193.el6.x86_64 cmd: /usr/libexec/qemu-kvm -monitor stdio -drive file=/root/rhel5.qcow2,index=0,if=none,id=drive-virtio-disk1,media=disk,cache=none,format=qcow2,aio=native -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk1,id=virtio-disk1 -device virtio-net-pci,netdev=idmkKeNp,mac=9a:04:b2:64:d8:00,id=ndev00idmkKeNp,bus=pci.0,addr=0x3 -netdev tap,id=idmkKeNp,vhost=on,script='/home/Auto/autotest-devel/client/tests/kvm/scripts/qemu-ifup-switch',downscript='no' -m 2048 -smp 4,cores=2,threads=1,sockets=2 -cpu cpu64-rhel6,+sse2,+x2apic -vnc :0 -rtc base=utc,clock=host,driftfix=none -M rhel6.1.0 -boot c -usbdevice tablet -no-kvm-pit-reinjection -enable-kvm
[root@rhel5 ~]# dmesg | egrep '(usb|input)' usbcore: registered new driver usbfs usbcore: registered new driver hub usbcore: registered new driver hiddev usbcore: registered new driver usbhid drivers/usb/input/hid-core.c: v2.6:USB HID core driver input: AT Translated Set 2 keyboard as /class/input/input0 input: ImExPS/2 Generic Explorer Mouse as /class/input/input1 usb usb1: configuration #1 chosen from 1 choice usb 1-1: new full speed USB device using uhci_hcd and address 2 usb 1-1: configuration #1 chosen from 1 choice input: QEMU 0.12.1 QEMU USB Tablet as /class/input/input2 input: USB HID v0.01 Pointer [QEMU 0.12.1 QEMU USB Tablet] on usb-0000:00:01.2-1 SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts input: PC Speaker as /class/input/input3 [ suspend / resume cycle here ] usb usb1: root hub lost power or was reset Restarting tasks...<6>usb 1-1: USB disconnect, address 2 usb 1-1: new full speed USB device using uhci_hcd and address 3 usb 1-1: configuration #1 chosen from 1 choice input: QEMU 0.12.1 QEMU USB Tablet as /class/input/input4 input: USB HID v0.01 Pointer [QEMU 0.12.1 QEMU USB Tablet] on usb-0000:00:01.2-1 [ suspend / resume again here ] usb usb1: root hub lost power or was reset Restarting tasks...<6>usb 1-1: USB disconnect, address 3 usb 1-1: new full speed USB device using uhci_hcd and address 4 usb 1-1: configuration #1 chosen from 1 choice input: QEMU 0.12.1 QEMU USB Tablet as /class/input/input5 input: USB HID v0.01 Pointer [QEMU 0.12.1 QEMU USB Tablet] on usb-0000:00:01.2-1 Pretty clear what is going on here. UHCI controller was reset during S3 (normal, qemu does that for all devices). The linux kernel reinitializes the host controller and all usb devices connected. The tablet gets another evdev device in the process while /dev/input/event2 which is specified in the config file goes away. The good news is that this is limited to RHEL-5 guests. The bad news is that the fundamental issue is pretty hard to fix. It is the old xorg version in RHEL-5 which is not able to handle hotplug. For mice the kernel is able to masquerade that by routing all events to /dev/input/mice, no matter where they come from. But that device speaks the ps/2 protocol and thus supports relative coordinates only, so this trick doesn't work for the tablet. There is nothing we can do about it in qemu-kvm. Reassigning to evdev for further investigation. I suspect this is a hot WONTFIX candidate though.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
This bug/component is not included in scope for RHEL-5.11.0 which is the last RHEL5 minor release. This Bugzilla will soon be CLOSED as WONTFIX (at the end of RHEL5.11 development phase (Apr 22, 2014)). Please contact your account manager or support representative in case you need to escalate this bug.
Thank you for submitting this request for inclusion in Red Hat Enterprise Linux 5. We've carefully evaluated the request, but are unable to include it in RHEL5 stream. If the issue is critical for your business, please provide additional business justification through the appropriate support channels (https://access.redhat.com/site/support).
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days