Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 733028

Summary:

Failed to reboot guest due to "key event queue full"

Product:

Red Hat Enterprise Linux 6

Reporter:

Chao Yang <chayang>

Component:

seabios

Assignee:

Gerd Hoffmann <kraxel>

Status:

CLOSED ERRATA

QA Contact:

Virtualization Bugs <virt-bugs>

Severity:

medium

Docs Contact:

Priority:

medium

Version:

6.2

CC:

chayang, ehabkost, juzhang, michen, mkenneth, qzhou, shuang, shu, tburke, virt-maint

Target Milestone:

Target Release:

---

Hardware:

Unspecified

OS:

Unspecified

Whiteboard:

Fixed In Version:

seabios-0.6.1.2-6.el6

Doc Type:

Bug Fix

Doc Text:

Cause; on reboot, reinitialization of the USB hid devices was not done before seabios was setting up timers. Consequence: the USB keyboard polling (called from the timer IRQ) processed bogus data after reboot, causing "usb-kbd: warning: key event queue full" qemu-kvm error messages, and guest failed to reboot. Fix: Moved initialization of USB HID devices earlier in the boot process. Result: no "usb-kbd: warning: key event queue full" error messages, and guest reboots properly.

Story Points:

---

Clone Of:

Environment:

Last Closed:

2011-12-06 17:01:05 UTC

Type:

---

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
serial output of bootup and reboot	none
guest device message with usb kbd assigned	none
seabios fix	none

Description Chao Yang 2011-08-24 14:08:59 UTC

Created attachment 519647 [details]
serial output of bootup and reboot

Description of problem:
Issue "shutdown -r now" in guest, what I got is a black screen, guest got no response on system_reset, then hit any key, monitor reports:
(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


Version-Release number of selected component (if applicable):
# rpm -q qemu-kvm
qemu-kvm-0.12.1.2-2.184.el6.x86_64
# uname -r
2.6.32-191.el6.x86_64


How reproducible:
100%

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
During guest first boot, I see:
hub 1-0:1.0: Cannot enable port 2.  Maybe the USB cable is bad?
hub 1-0:1.0: Cannot enable port 2.  Maybe the USB cable is bad?
hub 1-0:1.0: Cannot enable port 2.  Maybe the USB cable is bad?
hub 1-0:1.0: Cannot enable port 2.  Maybe the USB cable is bad?
hub 1-0:1.0: unable to enumerate USB device on port 2
hub 1-0:1.0: Cannot enable port 3.  Maybe the USB cable is bad?
hub 1-0:1.0: Cannot enable port 3.  Maybe the USB cable is bad?
hub 1-0:1.0: Cannot enable port 3.  Maybe the USB cable is bad?
hub 1-0:1.0: Cannot enable port 3.  Maybe the USB cable is bad?
hub 1-0:1.0: unable to enumerate USB device on port 3
...
 
CLI:
# /usr/libexec/qemu-kvm -M rhel6.2.0 -enable-kvm -m 4096 -smp 4,sockets=1,cores=4,threads=1 -name RHEL6.1_32 -uuid 24b39949-f2a3-4fed-8b3d-528ba6439cc6 -rtc base=utc,clock=host,driftfix=slew -boot order=dc,menu=on -drive file=/home/RHEL6.1-32-copy.qcow2,if=none,id=drive-virtio-0-0,media=disk,format=qcow2,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-virtio-0-0,id=virt0-0-0,bootindex=1 -netdev tap,id=hostnet1,vhost=on -device virtio-net-pci,netdev=hostnet1,id=net1,mac=64:31:50:41:e1:c3 -usb -device usb-tablet,id=input1,bus=usb.0,port=1 -spice port=9000,disable-ticketing -vga qxl -global qxl-vga.vram_size=67108864 -monitor stdio -balloon none  -device usb-ehci,id=ehci  -device usb-hub,bus=usb.0,port=2,id=hub -device usb-storage,bus=usb.0,port=2.4,drive=drive-usb-2-0,id=usb-2-0,removable=on -drive file=/home/image/usb-storage-2.qcow2,if=none,id=drive-usb-2-0,media=disk,format=qcow2,cache=none,werror=stop,rerror=stop,aio=threads -device usb-storage,drive=drive-usb-0-0,id=usb-0-0,removable=on,bus=ehci.0,port=1  -device usb-ccid,id=ccid -drive file=/home/image/usb-storage.qcow2,if=none,id=drive-usb-0-0,media=disk,format=qcow2,cache=none,werror=stop,rerror=stop,aio=native -device usb-mouse,bus=ehci.0,port=3,id=mouse -device usb-kbd,bus=usb.0,port=2.3,id=kbd -serial unix:/tmp/socket,server,nowait

Comment 2 Gerd Hoffmann 2011-09-12 08:34:11 UTC

"key event queue full" most likely isn't the root cause.  I think the guest hangs for some reason, thus doesn't process keyboard events any more, which in turn leads to those messages.

Can you please remove the connected usb devices one by one to figure which one causes the trouble?

Comment 3 Chao Yang 2011-09-14 03:22:28 UTC

Reproduced with "-usb -device usb-tablet,id=input1,port=1 -device usb-hub,bus=usb.0,port=2,id=hub -device usb-kbd,port=2.3", tried 5 times, for two times I got:
kvm: unhandled exit 80000021
kvm_run returned -22
handle_dev_input: stop
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

Comment 4 Chao Yang 2011-09-14 03:23:49 UTC

Created attachment 523046 [details]
guest device message with usb kbd assigned

Comment 5 Chao Yang 2011-09-14 03:27:31 UTC

If remove "-device usb-kbd,port=2.3" option, guest rebooted successfully.

Comment 6 Gerd Hoffmann 2011-09-14 07:49:07 UTC

What happens if you remove the tablet too and leave just the hub and the keyboard, do you still see the hangs?  If yes:  Do you see the hangs too if you plug the keyboard into a root port (port=1) instead of the hub (port=2.3)?

Comment 7 Chao Yang 2011-09-14 08:57:00 UTC

(In reply to comment #6)
> What happens if you remove the tablet too and leave just the hub and the
> keyboard, do you still see the hangs? 
Yes, still can see the hangs with errors:
kvm: unhandled exit 80000021
kvm_run returned -22
handle_dev_input: stop

>If yes:  Do you see the hangs too if you
> plug the keyboard into a root port (port=1) instead of the hub (port=2.3)?
Yes, still can see the hangs if I plug the keyboard into root port, and without hub，tablet in cli:
... -usb -device usb-kbd,port=1 
kvm: unhandled exit 80000021
kvm_run returned -22
handle_dev_input: stop

Comment 8 Gerd Hoffmann 2011-09-14 11:50:13 UTC

Created attachment 523131 [details]
seabios fix

Comment 9 Gerd Hoffmann 2011-09-14 11:55:37 UTC

Patch posted to rhvirt

Comment 13 Shaolong Hu 2011-10-13 10:26:54 UTC

Reproduce on:
---------------
qemu-kvm-0.12.1.2-2.195.el6.x86_64
seabios-0.6.1.2-5.el6.x86_64

Steps:
-----------
1. boot guest with -usb -device usb-kbd,id=kbd1
2. in guest: #shutdown -r now

Actual result:
---------------
after step 2:
(qemu) kvm: unhandled exit 80000021
kvm_run returned -22
(qemu) info status
VM status: paused



Verify on:
--------------
qemu-kvm-0.12.1.2-2.195.el6.x86_64
seabios-0.6.1.2-6.el6.x86_64

After step 2, guest shut down correctly, qemu-kvm exits correctly, verified.

Comment 15 Eduardo Habkost 2011-11-17 15:51:59 UTC

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause; on reboot, reinitialization of the USB hid devices was not done before seabios was setting up timers.

Consequence: the USB keyboard polling (called from the timer IRQ) processed bogus data after reboot, causing "usb-kbd: warning: key event queue full" qemu-kvm error messages, and guest failed to reboot.

Fix: Moved initialization of USB HID devices earlier in the boot process.

Result: no "usb-kbd: warning: key event queue full" error messages, and guest reboots properly.

Comment 16 errata-xmlrpc 2011-12-06 17:01:05 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1680.html