USB device messages flooding dmesg (and console)

Question

When USB mouse is plugged into my laptop, dmesg is flooded with following messages:

usb 3-1: USB disconnect, device number 28
usb 3-1: new low-speed USB device number 29 using xhci_hcd
usb 3-1: New USB device found, idVendor=045e, idProduct=00cb
usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 3-1: Product: Microsoft USB Optical Mouse
usb 3-1: Manufacturer: PixArt
usb 3-1: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes
input: PixArt Microsoft USB Optical Mouse as /devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.0/input/input39
hid-generic 0003:045E:00CB.001C: input: USB HID v1.11 Mouse [PixArt Microsoft USB Optical Mouse] on usb-0000:00:14.0-1/input0
usb 3-1: USB disconnect, device number 29
usb 3-1: new low-speed USB device number 30 using xhci_hcd
usb 3-1: New USB device found, idVendor=045e, idProduct=00cb
usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 3-1: Product: Microsoft USB Optical Mouse
usb 3-1: Manufacturer: PixArt
usb 3-1: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes
input: PixArt Microsoft USB Optical Mouse as /devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.0/input/input40
hid-generic 0003:045E:00CB.001D: input: USB HID v1.11 Mouse [PixArt Microsoft USB Optical Mouse] on usb-0000:00:14.0-1/input0

It looks as if the mouse was constantly being removed and then re-discovered.

When I am logged in console (i.e CTRL+ALT+F1) these messages flood my console as well. Is there a way to fix this problem, so that these messages don't bother me?

Answer 1

PixArt OEM mice are known to disconnect/reconnect every minute in runlevel 1 or 3 if they are not always polled on Linux. An internal buffer overflows, FW crashes, and they reconnect. The default behavior of the usbhid driver is just to wait for interrupts.

Basics: https://github.com/sriemer/fix-linux-mouse

I've submitted the patch for this mouse to the linux-usb mailing list now:

https://marc.info/?l=linux-usb&m=154159427814212&w=2

The kernel boot option usbhid.quirks=0x045e:0x00cb:0x00000400 would also enable HID_QUIRK_ALWAYS_POLL for you.

Another alternative is to activate the gpm service. Then gpm is polling the mouse and you can actually use it on the virtual terminal.

Answer 2

A temporary solution (will reset after reboot):

(as root)

sysctl -w kernel.printk="3 4 1 7"

A permanent version of the above:

• Create a file in /etc/sysctl.d/, perhaps no_msgs.conf (must end in .conf)

• contents of file:

  kernel.printk = 3 4 1 7
  

• as root, execute: (use whatever filename you used above) This will put this into effect immediately, and will be set again on each reboot.

  sysctl -p /etc/sysctl.d/no_msgs.conf
  

The parameters to kernel.printk are: (in order, left to right)

• console_loglevel: messages with a higher priority (lower number!) than this will be printed to the console
• default_message_loglevel: messages without an explicit priority will be printed with this priority
• minimum_console_loglevel: minimum (highest) value to which console_loglevel can be set
• default_console_loglevel: default value for console_loglevel

These values influence printk() behavior when printing or logging error messages. See 'man 2' syslog' for more info on the different loglevels.

Essentially, we're lowering the value from the default of 4, to 3, thus refusing to print 'warn (4)' type messages, only worse type messages will be allowed to print to the console. (3=err, 2=crit, 1=alert, 0=emergency (uh oh!))

If you find that 3 doesn't stop the messages, try 2 4 1 7, but really, you should look into what is making your mouse continually reconnect. Perhaps it's not getting enough power? Try plugging it into a different port on your computer, or better, plug it into a self-powered hub. Devices should not oscillate like that.