Strange USB device connection messages on /var/log/messages on Centos 7.5
I am seeing some strange USB device connect and disconnect messages in a dedicated server running CentOS 7.5. These messages appear almost every day, but they do not appear at the same time every day. The time of the messages is random. I have contacted my dedicated hosting provider and they say they do not know the reason for this message. They have confirmed that no USB devices are physically attached to the server. They think it is OS related bug or USB driver issue. Should I be worried about this? Should I ignore these messages? Any help is appreciated. Thank you!
My operating system details are below:
[root@myserver ~]# uname -a
Linux myserver 3.10.0-862.14.4.el7.x86_64 #1 SMP Wed Sep 26 15:12:11 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[root@myserver ~]# cat /etc/centos-release
CentOS Linux release 7.5.1804 (Core)
My server specs are below:
Intel Xeon E5 1650 V3
256GB SSD on RAID 1
2TB HD on RAID 1
My RAID card details are below:
[root@myserver ~]# lspci -knn | grep 'RAID bus controller'
04:00.0 RAID bus controller [0104]: LSI Logic / Symbios Logic MegaRAID SAS 2108 [Liberator] [1000:0079] (rev 05)
Below is a sample of the messages I am seeing in /var/log/messages:
Nov 2 04:41:29 myserver kernel: usb 3-12: USB disconnect, device number 31
Nov 2 04:41:29 myserver kernel: usb 3-12.1: USB disconnect, device number 33
Nov 2 04:41:29 myserver kernel: hid-generic 0003:0557:2419.0029: usb_submit_urb(ctrl) failed: -19
Nov 2 04:41:59 myserver kernel: usb 3-12: new high-speed USB device number 34 using xhci_hcd
Nov 2 04:41:59 myserver kernel: usb 3-12: New USB device found, idVendor=0557, idProduct=7000
Nov 2 04:41:59 myserver kernel: usb 3-12: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Nov 2 04:41:59 myserver kernel: hub 3-12:1.0: USB hub found
Nov 2 04:41:59 myserver kernel: hub 3-12:1.0: 4 ports detected
Nov 2 04:42:00 myserver kernel: usb 3-12.1: new low-speed USB device number 35 using xhci_hcd
Nov 2 04:42:00 myserver kernel: usb 3-12.1: New USB device found, idVendor=0557, idProduct=2419
Nov 2 04:42:00 myserver kernel: usb 3-12.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Nov 2 04:42:00 myserver kernel: input: HID 0557:2419 as /devices/pci0000:00/0000:00:14.0/usb3/3-12/3-12.1/3-12.1:1.0/input/input45
Nov 2 04:42:00 myserver kernel: hid-generic 0003:0557:2419.002B: input,hidraw0: USB HID v1.00 Keyboard [HID 0557:2419] on usb-0000:00:14.0-12.1/input0
Nov 2 04:42:00 myserver kernel: input: HID 0557:2419 as /devices/pci0000:00/0000:00:14.0/usb3/3-12/3-12.1/3-12.1:1.1/input/input46
Nov 2 04:42:00 myserver kernel: hid-generic 0003:0557:2419.002C: input,hidraw1: USB HID v1.00 Mouse [HID 0557:2419] on usb-0000:00:14.0-12.1/input1
Nov 2 04:42:14 myserver kernel: usb 3-12.1: USB disconnect, device number 35
Nov 2 04:42:14 myserver kernel: hid-generic 0003:0557:2419.002B: usb_submit_urb(ctrl) failed: -19
Nov 2 04:42:16 myserver kernel: usb 3-12.1: new low-speed USB device number 36 using xhci_hcd
Nov 2 04:42:16 myserver kernel: usb 3-12.1: New USB device found, idVendor=0557, idProduct=2419
Nov 2 04:42:16 myserver kernel: usb 3-12.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Nov 2 04:42:16 myserver kernel: input: HID 0557:2419 as /devices/pci0000:00/0000:00:14.0/usb3/3-12/3-12.1/3-12.1:1.0/input/input47
Nov 2 04:42:16 myserver kernel: hid-generic 0003:0557:2419.002D: input,hidraw0: USB HID v1.00 Keyboard [HID 0557:2419] on usb-0000:00:14.0-12.1/input0
Nov 2 04:42:16 myserver kernel: input: HID 0557:2419 as /devices/pci0000:00/0000:00:14.0/usb3/3-12/3-12.1/3-12.1:1.1/input/input48
Nov 2 04:42:16 myserver kernel: hid-generic 0003:0557:2419.002E: input,hidraw1: USB HID v1.00 Mouse [HID 0557:2419] on usb-0000:00:14.0-12.1/input1
Solution 1:
Those devices are the USB hub/ports provided by the Supermicro (and other server brands) server's built-in IPMI to connect virtual USB devices via the IPMI web interface or Java console. Which means something is wrong with the motherboard. It should be replaced. You don't want to have an unreliable IPMI when the worst happens.