I have Scientific Linux 6.5 installed. From the beginning (on this computer) I constantly see this line jump in between all starting commands during the start up of the system (when I press esc
to see the start up log been written):
usbhid: 9-2:1.1: couldn't find an input interrupt endpoint
I had no big problem with that, so I ignored it until now. Recently I am trying to edit my programs in emacs
in a pure terminal environment (by pressing Ctrl+Alt+F2
) and in the middle of my work this line jumps in again! I wanted to see what is causing it and how I can fix this issue.
Here is an example. I wrote this text in emacs:
This is a test to show the problem.
This line was a clean sentance, I kept the cursor
in it to show how the line jumps in.
It is not too common but it jumps in every once and a while.
After waiting a while, the line jumped where the cursor was at that moment (after "how" in the third line.):
The line remains there but only in appearance! When I press backspace on it it deletes the underlying sentance and I can only go over the region that it over laps with the undelying line.
Ultimately, when I save it, I don't see it either, futher proving that it is only there in appearance, not in the actual buffer.
When I run lshw -c input
as root, I get the following output:
[root@mycomputer myid]# lshw -c input
*-usb
description: Mouse
product: Kinzu
vendor: SteelSeries
physical id: 2
bus info: usb@9:2
version: 0.30
capabilities: usb-1.10
configuration: driver=usbhid maxpower=100mA speed=12.0MB/s
*-usb
description: Keyboard
product: USB Keyboard
vendor: Holtek Semiconductor, Inc.
physical id: 2
bus info: usb@3:2
version: 3.90
capabilities: usb-1.10
configuration: driver=usbhid maxpower=100mA speed=1.5MB/s
Best Answer
Debugging the issue
The big clue here is the error message:
The USB HID stands for USB Human Interface Device, which typically means either your keyboard or mouse, assuming they're USB based devices.
Keyboard or mouse?
When the issue pops up you should typically see error messages in the
dmesg
that correspond to the usbhid errors as well. In looking, the OP was able to find that these messages were definitely there, and that they seemed to be pointing to the mouse as being the culprit.Disabling the mouse
To further debug the issue I suggested disabling the mouse, using a method I documented in another U&L Q&A titled: Disable the external keyboard from a script. The method uses
xinput
to set the devices property so that its disabled, for example:After the OP used a command similar to the one above, the issue appeared to go away, essentially confirming the suspicion.
What kind of mouse is it?
Next we determined the type of mouse that was installed using the command
lshw -c input
.This led us to our next clue, the type of mouse was a model called Kinzu.
Issues with Kinzu mice
This last piece of info was pretty critical to determining the underlying issue. Apparently the Kinzu mice are known for having this exact issue. I found several reports about it:
One "workaround" was to use a USB 3 port, if available, for the mouse. The OP tried this but it had no effect on the issues with this mouse.
What to do?
Well given all the above, it looks like either the mouse is defective or just poorly designed, so really the only option is to swap it out for another mouse.