Bug 736012 - guest boot with "-usbdevice tablet" not accepting mouse clicking after resume from suspend to mem [NEEDINFO]
Summary: guest boot with "-usbdevice tablet" not accepting mouse clicking after resume...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xorg-x11-drv-evdev
Version: 5.7
Hardware: All
OS: Linux
medium
high
Target Milestone: rc
: 5.8
Assignee: Peter Hutterer
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On: 557039
Blocks: 753024 756082
TreeView+ depends on / blocked
 
Reported: 2011-09-06 12:22 UTC by Suqin Huang
Modified: 2014-06-03 12:48 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 557039
Environment:
Last Closed: 2014-06-03 12:48:48 UTC
pm-rhel: needinfo? (shuang)


Attachments (Terms of Use)

Comment 1 Suqin Huang 2011-09-06 12:24:10 UTC
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

Comment 5 Gerd Hoffmann 2012-01-05 14:38:52 UTC
[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.

Comment 6 RHEL Product and Program Management 2012-06-12 01:08:10 UTC
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.

Comment 7 RHEL Product and Program Management 2014-03-07 12:38:27 UTC
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.

Comment 8 RHEL Product and Program Management 2014-06-03 12:48:48 UTC
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).


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