Bug 1293234 - Key event queue full when input through keyboard after boot vm
Key event queue full when input through keyboard after boot vm
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
6.8
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Gerd Hoffmann
Virtualization Bugs
:
Depends On:
Blocks: 1359965 1301830
  Show dependency treegraph
 
Reported: 2015-12-21 02:28 EST by jingzhao
Modified: 2017-12-06 06:28 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1301830 (view as bug list)
Environment:
Last Closed: 2017-12-06 06:28:39 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description jingzhao 2015-12-21 02:28:45 EST
Description of problem:
Key event queue full when input through keyboard after boot vm, and there no input when input charaters through keyboard

Version-Release number of selected component (if applicable):
kernel version: 2.6.32-592.el6.x86_64
qemu-kvm-0.12.1.2-2.481.el6.x86_64

How reproducible:
3/3

Steps to Reproduce:
1. Boot vm through following cli:

/usr/libexec/qemu-kvm \
-name rhel6 \
-machine rhel6.6.0,accel=kvm \
-realtime mlock=off \
-cpu SandyBridge \
-m 6G   \
-smp 4,cores=2,threads=1,sockets=2  \
-uuid 49a3438a-70a3-4ba8-92ce-3a05e0934608 \
-nodefaults \
-rtc base=utc,driftfix=slew \
-global kvm-pit.lost_tick_policy=discard \
-global PIIX4_PM.disable_s3=1 \
-global PIIX4_PM.disable_s4=1 \
-boot order=c,menu=on,strict=on \
-device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 \
-device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 \
-device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 \
-device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 \
-drive file=/home/usb/usb-storage.qcow2,if=none,id=storage0,media=disk,cache=none,format=qcow2 \
-device usb-storage,drive=storage0,removable=on,bus=usb.0,id=storage0,bootindex=1 \
-device usb-hub \
-device usb-host \
-device usb-kbd \
-device usb-mouse \
-device usb-tablet \
-device usb-ccid \
-drive file=/home/usb/win10.img,if=none,id=ide,format=raw \
-device ide-drive,drive=ide,id=ide0,bootindex=0 \
-cdrom /usr/share/virtio-win/virtio-win.iso \
-netdev tap,id=hostnet1  \
-device e1000,netdev=hostnet1,id=virtio-net-pci1,mac=b6:2f:a8:85:72:6c,bus=pci.0,multifunction=off \
-monitor stdio \
-qmp tcp:0:4467,server,nowait -serial unix:/tmp/ttym,server,nowait \
-vga qxl \
-spice port=5911,addr=0.0.0.0,disable-ticketing,seamless-migration=on \
-k en-us \

2. Input charaters after guest boot up


Actual results:
usb-kbd: warning: key event queue full  in qemu infterface and there have no input in the guest

Expected results:
No warnings and we can input charaters through keyboard

Additional info:
Comment 2 Gerd Hoffmann 2016-01-12 03:04:17 EST
Can you attach lsusb output and /proc/bus/input/devices content (both from guest) please?
Comment 3 juzhang 2016-01-17 09:38:27 EST
Hi Jing,

Could you reply comment2?

Best Regards,
Junyi
Comment 4 jingzhao 2016-01-17 19:57:10 EST
(In reply to Gerd Hoffmann from comment #2)
> Can you attach lsusb output and /proc/bus/input/devices content (both from
> guest) please?

Hi gerd

the output of lsusb:

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 46f4:0001  
Bus 002 Device 002: ID 0409:55aa NEC Corp. Hub
Bus 003 Device 002: ID 0557:2213 ATEN International Co., Ltd CS682 2-Port USB 2.0 DVI KVM Switch
Bus 003 Device 003: ID 0627:0001 Adomax Technology Co., Ltd 
Bus 004 Device 002: ID 0627:0001 Adomax Technology Co., Ltd 
Bus 004 Device 003: ID 0627:0001 Adomax Technology Co., Ltd 
Bus 002 Device 003: ID 08e6:4433 Gemalto (was Gemplus) GemPC433-Swap

the content of /proc/bus/input/devices

[root@localhost ~]# cat /proc/bus/input/devices 
I: Bus=0019 Vendor=0000 Product=0001 Version=0000
N: Name="Power Button"
P: Phys=LNXPWRBN/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
U: Uniq=
H: Handlers=kbd event0 
B: PROP=0
B: EV=3
B: KEY=10000000000000 0

I: Bus=0017 Vendor=0001 Product=0001 Version=0100
N: Name="Macintosh mouse button emulation"
P: Phys=
S: Sysfs=/devices/virtual/input/input1
U: Uniq=
H: Handlers=mouse0 event1 
B: PROP=0
B: EV=7
B: KEY=70000 0 0 0 0
B: REL=3

I: Bus=0011 Vendor=0001 Product=0001 Version=ab41
N: Name="AT Translated Set 2 keyboard"
P: Phys=isa0060/serio0/input0
S: Sysfs=/devices/platform/i8042/serio0/input/input2
U: Uniq=
H: Handlers=kbd event2 
B: PROP=0
B: EV=120013
B: KEY=402000000 3803078f800d001 feffffdfffefffff fffffffffffffffe
B: MSC=10
B: LED=7

I: Bus=0011 Vendor=0002 Product=0006 Version=0000
N: Name="ImExPS/2 Generic Explorer Mouse"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input3
U: Uniq=
H: Handlers=mouse1 event3 
B: PROP=0
B: EV=7
B: KEY=1f0000 0 0 0 0
B: REL=143

I: Bus=0003 Vendor=0557 Product=2213 Version=0100
N: Name="CS-̊ATEN V4. CS-1734A V4.2.418"
P: Phys=usb-0000:00:05.1-1/input0
S: Sysfs=/devices/pci0000:00/0000:00:05.1/usb3/3-1/3-1:1.0/input/input4
U: Uniq=
H: Handlers=kbd event4 
B: PROP=0
B: EV=120013
B: KEY=1000000000007 ff9f207ac14057ff febeffdfffefffff fffffffffffffffe
B: MSC=10
B: LED=1f

I: Bus=0003 Vendor=0557 Product=2213 Version=0100
N: Name="CS-̊ATEN V4. CS-1734A V4.2.418"
P: Phys=usb-0000:00:05.1-1/input1
S: Sysfs=/devices/pci0000:00/0000:00:05.1/usb3/3-1/3-1:1.1/input/input5
U: Uniq=
H: Handlers=mouse2 event5 
B: PROP=0
B: EV=17
B: KEY=1f0000 0 0 0 0
B: REL=103
B: MSC=10

I: Bus=0003 Vendor=0627 Product=0001 Version=0111
N: Name="QEMU 0.12.1 QEMU USB Keyboard"
P: Phys=usb-0000:00:05.1-2/input0
S: Sysfs=/devices/pci0000:00/0000:00:05.1/usb3/3-2/3-2:1.0/input/input6
U: Uniq=42
H: Handlers=kbd event6 
B: PROP=0
B: EV=120013
B: KEY=1000000000007 ff9f207ac14057ff febeffdfffefffff fffffffffffffffe
B: MSC=10
B: LED=1f

I: Bus=0003 Vendor=0627 Product=0001 Version=0001
N: Name="QEMU 0.12.1 QEMU USB Mouse"
P: Phys=usb-0000:00:05.2-1/input0
S: Sysfs=/devices/pci0000:00/0000:00:05.2/usb4/4-1/4-1:1.0/input/input7
U: Uniq=42
H: Handlers=mouse3 event7 
B: PROP=0
B: EV=17
B: KEY=70000 0 0 0 0
B: REL=103
B: MSC=10

I: Bus=0003 Vendor=0627 Product=0001 Version=0001
N: Name="QEMU 0.12.1 QEMU USB Tablet"
P: Phys=usb-0000:00:05.2-2/input0
S: Sysfs=/devices/pci0000:00/0000:00:05.2/usb4/4-2/4-2:1.0/input/input8
U: Uniq=42
H: Handlers=mouse4 event8 js0 
B: PROP=0
B: EV=1f
B: KEY=70000 0 0 0 0
B: REL=100
B: ABS=3
B: MSC=10

Sorry for late.
Comment 5 Gerd Hoffmann 2016-01-18 04:31:05 EST
What guest is this?  You don't mention it in the original comment, but looking at the command line the disk image name suggests it is windows not linux ...

In case it is windows:  What happens if you remove mouse and tablet?  Does the usb keyboard start working correctly then?
Comment 6 jingzhao 2016-01-18 04:42:32 EST
(In reply to Gerd Hoffmann from comment #5)
> What guest is this?  You don't mention it in the original comment, but
> looking at the command line the disk image name suggests it is windows not
> linux ...


> 
> In case it is windows:  What happens if you remove mouse and tablet?  Does
> the usb keyboard start working correctly then?

-- sorry for the mistake, I will tried it with your scenario on linux and windows guest and reply later.

Thanks
Jing
Comment 7 jingzhao 2016-01-19 00:42:30 EST
(In reply to jingzhao from comment #6)
> (In reply to Gerd Hoffmann from comment #5)
> > What guest is this?  You don't mention it in the original comment, but
> > looking at the command line the disk image name suggests it is windows not
> > linux ...
> 
> 
> > 
> > In case it is windows:  What happens if you remove mouse and tablet?  Does
> > the usb keyboard start working correctly then?
> 
> -- sorry for the mistake, I will tried it with your scenario on linux and
> windows guest and reply later.
> 
> Thanks
> Jing

Gerd, I tried with your scenario and there have no effect and usb-keyboard didn't used when we removed mouse and tablet. But, usb keyboard can work correctly after re-add the usb-kbd device. 

Thanks
Jing
Comment 8 Gerd Hoffmann 2016-01-19 07:17:27 EST
Ok, then it is probably the serial number clash issue.

Workaround: use "-device usb-kbd,serial=1234", and use a different serial for each hid device.

Can you confirm this works for you?
Comment 9 jingzhao 2016-01-19 23:19:07 EST
(In reply to Gerd Hoffmann from comment #8)
> Ok, then it is probably the serial number clash issue.
> 
> Workaround: use "-device usb-kbd,serial=1234", and use a different serial
> for each hid device.
> 
> Can you confirm this works for you?

Gerd
  1. first the device didn't support serial parameter, checked it and it supported "create_unique_serial", so I used the "create_unique_serial" parameter
[root@localhost rng]# /usr/libexec/qemu-kvm -device usb-kbd,?
usb-kbd.migrate=uint32
usb-kbd.port=string
usb-kbd.create_unique_serial=uint32
usb-kbd.msos-desc=on/off
  2. I used the parameter "create_unique_serial" and also can reproduce the issue, and we must deleted the kbd device and re-add it, we can use the keyboard corretly.
Comment 10 Gerd Hoffmann 2016-01-20 02:04:37 EST
> Gerd
>   1. first the device didn't support serial parameter, checked it and it

Oops.  Can you try RHEL-7 then?
Comment 11 jingzhao 2016-01-20 02:41:36 EST
(In reply to Gerd Hoffmann from comment #10)
> > Gerd
> >   1. first the device didn't support serial parameter, checked it and it
> 
> Oops.  Can you try RHEL-7 then?

Gerd, reproduced on RHEL-7 on kernel-3.10.0-327.5.1.el7.x86_64 and qemu-kvm-rhev-2.3.0-31.el7_2.5.x86_64, tried with the same senario and keyboard can work correctly after re-add the usb-keyboard device.
Comment 12 Gerd Hoffmann 2016-01-20 06:31:45 EST
> Gerd, reproduced on RHEL-7 on kernel-3.10.0-327.5.1.el7.x86_64 and
> qemu-kvm-rhev-2.3.0-31.el7_2.5.x86_64, tried with the same senario and
> keyboard can work correctly after re-add the usb-keyboard device.

What happens when you assign unique serial numbers to the devices (see comment 8) on RHEL-7?  Things are working then?
Comment 13 jingzhao 2016-01-20 20:09:35 EST
(In reply to Gerd Hoffmann from comment #12)
> > Gerd, reproduced on RHEL-7 on kernel-3.10.0-327.5.1.el7.x86_64 and
> > qemu-kvm-rhev-2.3.0-31.el7_2.5.x86_64, tried with the same senario and
> > keyboard can work correctly after re-add the usb-keyboard device.
> 
> What happens when you assign unique serial numbers to the devices (see
> comment 8) on RHEL-7?  Things are working then?

usb-keyboard also didn't work after assign unique serial numbers to the devices, after then, you should re-add the keyboard device and then keyboard can working correctly, following is the reproduced steps

1. boot guest with following cli:

/usr/libexec/qemu-kvm \
-name pc \
-machine pc,accel=kvm \
-realtime mlock=off \
-cpu SandyBridge \
-m 6G   \
-smp 4,cores=2,threads=1,sockets=2  \
-uuid 49a3438a-70a3-4ba8-92ce-3a05e0934608 \
-nodefaults \
-rtc base=utc,driftfix=slew \
-global kvm-pit.lost_tick_policy=discard \
-global PIIX4_PM.disable_s3=1 \
-global PIIX4_PM.disable_s4=1 \
-boot order=c,menu=on,strict=on \
-readconfig ich9-ehci-uhci.cfg \
-drive file=/home/usb/usb-storage.qcow2,if=none,id=storage0,media=disk,cache=none,format=qcow2 \
-device usb-storage,drive=storage0,removable=on,bus=ehci.0,id=storage0 \
-device usb-hub,id=hub1,serial=111 \
-device usb-host,id=host1,serial=112 \
-device usb-kbd,id=kbd1,serial=113 \
-device usb-mouse,id=mouse1,serial=114 \
-device usb-tablet,id=tablet1,serial=115 \
-device usb-ccid,id=ccid1,serial=116 \
-drive file=/media/win10blk.raw,if=none,id=ide,format=raw \
-device ide-drive,drive=ide,id=ide0,bootindex=0 \
-cdrom /usr/share/virtio-win/virtio-win.iso \
-netdev tap,id=hostnet1  \
-device e1000,netdev=hostnet1,id=virtio-net-pci1,mac=b6:2f:a8:85:72:6c,bus=pci.0,multifunction=off \
-monitor stdio \
-qmp tcp:0:4467,server,nowait -serial unix:/tmp/ttym,server,nowait \
-vga qxl \
-spice port=5911,addr=0.0.0.0,disable-ticketing,seamless-migration=on \
-k en-us \

2. Used the keyboard device after the guest booted up
3. "usb-kbd: warning: key event queue full" and keyboard device didn't work
4. "device_del kbd1" and "device_add usb-kbd,serial=1111,id=kbd1"
5.  keyboard working correctly
Comment 14 jingzhao 2016-01-26 02:42:40 EST
(In reply to jingzhao from comment #9)
> (In reply to Gerd Hoffmann from comment #8)
> > Ok, then it is probably the serial number clash issue.
> > 
> > Workaround: use "-device usb-kbd,serial=1234", and use a different serial
> > for each hid device.
> > 
> > Can you confirm this works for you?
> 
> Gerd
>   1. first the device didn't support serial parameter, checked it and it
> supported "create_unique_serial", so I used the "create_unique_serial"
> parameter
> [root@localhost rng]# /usr/libexec/qemu-kvm -device usb-kbd,?
> usb-kbd.migrate=uint32
> usb-kbd.port=string
> usb-kbd.create_unique_serial=uint32
> usb-kbd.msos-desc=on/off
>   2. I used the parameter "create_unique_serial" and also can reproduce the
> issue, and we must deleted the kbd device and re-add it, we can use the
> keyboard corretly.

Following is the information of usb from hmp:

(qemu) info usb
  Device 0.1, Port 1, Speed 480 Mb/s, Product QEMU USB MSD
  Device 0.1, Port 2, Speed 12 Mb/s, Product QEMU USB Hub
  Device 0.1, Port 3, Speed 1.5 Mb/s, Product CS-1734A V4.2.418
  Device 0.1, Port 5, Speed 12 Mb/s, Product QEMU USB Mouse
  Device 0.2, Port 6, Speed 12 Mb/s, Product QEMU USB Tablet
  Device 0.2, Port 2.1, Speed 12 Mb/s, Product QEMU USB CCID
  Device 0.3, Port 2.2, Speed 12 Mb/s, Product QEMU USB Keyboard
(qemu) 
(qemu) usb-kbd: warning: key event queue full
usb-kbd: warning: key event queue full
usb-kbd: warning: key event queue full
usb-kbd: warning: key event queue full
usb-kbd: warning: key event queue full
usb-kbd: warning: key event queue full
usb-kbd: warning: key event queue full
usb-kbd: warning: key event queue full
usb-kbd: warning: key event queue full
usb-kbd: warning: key event queue full

(qemu) devi
device_add  device_del  
(qemu) device_del kbd1
(qemu) info usb
  Device 0.1, Port 1, Speed 480 Mb/s, Product QEMU USB MSD
  Device 0.1, Port 2, Speed 12 Mb/s, Product QEMU USB Hub
  Device 0.1, Port 3, Speed 1.5 Mb/s, Product CS-1734A V4.2.418
  Device 0.1, Port 5, Speed 12 Mb/s, Product QEMU USB Mouse
  Device 0.2, Port 6, Speed 12 Mb/s, Product QEMU USB Tablet
  Device 0.2, Port 2.1, Speed 12 Mb/s, Product QEMU USB CCID
(qemu) dev
device_add  device_del  
(qemu) device_add usb-kbd,id=kbd1
(qemu) info usb
  Device 0.1, Port 1, Speed 480 Mb/s, Product QEMU USB MSD
  Device 0.1, Port 2, Speed 12 Mb/s, Product QEMU USB Hub
  Device 0.1, Port 3, Speed 1.5 Mb/s, Product CS-1734A V4.2.418
  Device 0.1, Port 5, Speed 12 Mb/s, Product QEMU USB Mouse
  Device 0.2, Port 6, Speed 12 Mb/s, Product QEMU USB Tablet
  Device 0.2, Port 2.1, Speed 12 Mb/s, Product QEMU USB CCID
  Device 0.4, Port 2.3, Speed 12 Mb/s, Product QEMU USB Keyboard
Comment 15 Gerd Hoffmann 2016-01-26 04:12:03 EST
> 4. "device_del kbd1" and "device_add usb-kbd,serial=1111,id=kbd1"
> 5.  keyboard working correctly

Hmm, strange.  Can you re-try with a fresh windows image?

Windows stores all kinds of stuff about usb devices it has seen in the registry, possibly that fools us here.
Comment 16 jingzhao 2016-01-27 02:53:42 EST
(In reply to Gerd Hoffmann from comment #15)
> > 4. "device_del kbd1" and "device_add usb-kbd,serial=1111,id=kbd1"
> > 5.  keyboard working correctly
> 
> Hmm, strange.  Can you re-try with a fresh windows image?
> 
> Windows stores all kinds of stuff about usb devices it has seen in the
> registry, possibly that fools us here.

--Also reproduced with a fresh windows image.  I tried it with the reproduced steps on rhel guest, and really didn't reproduced this issue (tried 10 times and didn't hit).

Thanks
Jing
Comment 19 Jan Kurik 2017-12-06 06:28:39 EST
Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:

http://redhat.com/rhel/lifecycle

This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com/

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