Sys-usb kernel 'control queue full' when using USB keyboard / mouse

User Support General
1

When I use an external USB keyboard and/or mouse, my laptop fans eventually start spinning loudly and the input from those peripherals is delayed.

user@sys-usb $ sudo journalctl -xe
... kernel: hid-generic 0003:3297:1969.0004: control queue full
... kernel: hid-generic 0003:3297:1969.0004: control queue full
... kernel: hid-generic 0003:3297:1969.0004: control queue full
... kernel: hid-generic 0003:3297:1969.0004: control queue full
... kernel: hid-generic 0003:3297:1969.0004: control queue full
... kernel: hid-generic 0003:3297:1969.0004: control queue full
... kernel: hid-generic 0003:3297:1969.0004: control queue full
... kernel: hid-generic 0003:3297:1969.0004: control queue full
# and so on like this

Restarting sys-usb stops this problem, but it happens again even within minutes. Updating the template (fedora-34) doesn’t help. My sys-usb is disposable, but I don’t see why that should matter.

I followed the fix recommened here gentoo wiki:
$ echo 'on' > /sys/devices/pci0000:00/0000:00:06.0/usb2/2-2/2-2:1.1/usbmisc/hiddev0/power/control
where that path seems to be the equivalent to the path mentioned in the gentoo wiki, /sys/class/usbmisc/hiddev*/device/../power/control, but that didn’t help.

Do others have this issue? Is this a Fedora issue? If so, where can I look to fix it in the VM’s virtual environment? Where can I find out what my specific log error message means?

EDIT: I should specify that this wasn’t a problem for me on 4.1 rc1, but when I re-installed rc4.3, this started.

1 Like
2

After the 4.1 upgrade, I was had minor and then worse problems with sys-usb. I renamed it and rebooted and eventually deleted sys-usb thinking it should be in the templates (community-testing ?). Turns out after rebooting, my USB mouse no longer needed sys-usb to work.

3

mybad…

4

@rjt I would also like to know your answer to this.

5

And I’d also like pointers on my issue…

6

https://bugzilla.redhat.com/show_bug.cgi?id=1517053

and the bug is old!

https://bugzilla.redhat.com/show_bug.cgi?id=904151

unfortunately everyone is trying to resolve a problem with a particular device rather than change the stupid kernel behavior at once.

1 Like
7

@TechExplorer @qubes-kernel-5.8 Probably did not have this exact same control queue full issue as it has been a while. I noticed that after restarting sys-usb, my keyboard and mice would work again. Usually, had to do this once or twice after booting the host.
I remember deleting sys-usb and recreating sys-usb with the following command.

sudo qubesctl state.sls qvm.sys-usb 
echo "The following will prepend sys-usb dom0 allow to the beginning "
echo "and create /etc/qubes-rpc/policy/qubes.InputKeyboard.bak "
sed -i.bak '1isys-usb dom0 allow' /etc/qubes-rpc/policy/qubes.InputKeyboard
sed -i.bak '1isys-usb dom0 allow' /etc/qubes-rpc/policy/qubes.InputMouse
8

(made the title more explicit – easier to find)

9

In case anyone else in running into this issue: it was causing some trouble for me and the source of the problem was apparently my KVM switch (with its emulated keyboard mouse).

Disabling those devices in sys-usb made the message and the resulting lags go away:
qvm-prefs --set sys-usb kernelopts 'usbhid.quirks=0xdead:0xbeef:0x4'
(make sure to retain pre-existing kernelopts and replace dead:beef with your actual device id - and only do this if you are 100% certain you don’t need the device in question in sys-usb - this is a perfect opportunity to lock yourself out of the system, having to boot with qubes.skip_autostart to recover)

10

I wish I would not need to track “the source of the problem” in hardware, I would prefer to change the way the kernel handles it :confused: For me YES I NEED all “problematic” devices.