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.
Description of problem:
keyboard didn't work after deleted keyboard device in qemu interface
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
guest: win10-64
How reproducible:
3/3
Steps to Reproduce:
1.Boot vm with 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 \
-monitor unix:/tmp/monitor-unix,server,nowait \
-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/win10usb.img,if=none,id=ide,media=disk,cache=none,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:4466,server,nowait -serial unix:/tmp/ttym,server,nowait \
-vga qxl \
-spice port=5910,addr=0.0.0.0,disable-ticketing,seamless-migration=on \
-k en-us \
2.used passwd and entered into the win10 system and no output through "info usb" command
3. add keyboard device and also can enter into the system through passwd
(qemu) device_add usb-kbd,id=kbd1
(qemu) info usb
Device 0.1, Port 1, Speed 12 Mb/s, Product QEMU USB Keyboard
4. then deleted the keyboard device
(qemu) device_del kbd1
Actual results:
Didn't enter into the system through password and also didn't enter into the system after reboot the system.
Expected results:
We can enter into the system correctly after deleted the keyboard device
Additional info:
(In reply to Gerd Hoffmann from comment #4)
> Why this has high Severity?
--I marked as high serverity because the keyboard didn't work and will impact the customer
(In reply to jingzhao from comment #5)
> (In reply to Gerd Hoffmann from comment #4)
> > Why this has high Severity?
>
> --I marked as high serverity because the keyboard didn't work
Only when plugging and un-plugging the usb keyboard.
What is the use case for doing this?
> and will
> impact the customer
Any actual customer reports?
(In reply to Gerd Hoffmann from comment #6)
> (In reply to jingzhao from comment #5)
> > (In reply to Gerd Hoffmann from comment #4)
> > > Why this has high Severity?
> >
> > --I marked as high serverity because the keyboard didn't work
>
> Only when plugging and un-plugging the usb keyboard.
> What is the use case for doing this?
---Didn't for special use, just do hot-plug operations.
>
> > and will
> > impact the customer
>
> Any actual customer reports? --No, really describe as impact I use.
(In reply to jingzhao from comment #7)
> (In reply to Gerd Hoffmann from comment #6)
> > (In reply to jingzhao from comment #5)
> > > (In reply to Gerd Hoffmann from comment #4)
> > > > Why this has high Severity?
> > >
> > > --I marked as high serverity because the keyboard didn't work
> >
> > Only when plugging and un-plugging the usb keyboard.
> > What is the use case for doing this?
> ---Didn't for special use, just do hot-plug operations.
Why would a customer hotplug a usb keyboard,
given that there is a ps/2 keyboard anyway?
I still fail to see how this affects customers in practice
and why it is important to backport the fix to RHEL-6 ...