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.):

enter image description here

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
   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
   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
  • Could you take a picture of this?
    – slm
    Feb 24, 2014 at 1:58
  • I just took a picture of the problem with my phone on a few lines of text in emacs in the terminal mode (Ctrl+Alt+F2). I also added some more explanations.
    – makhlaghi
    Feb 24, 2014 at 3:00
  • 1
    Yes I assumed keyboard since you were typing but it very well could be any USB HID device, which a mouse qualifies as. You could disable the mouse temporarily to see if it's the culprit. You can use xinput to disable devices such as mice.
    – slm
    Feb 24, 2014 at 3:19
  • 1
    See here for details on how to disable: my A shows the steps: unix.stackexchange.com/questions/105870/…
    – slm
    Feb 24, 2014 at 3:23
  • 1
    I wrote up our findings as an A.
    – slm
    Feb 24, 2014 at 5:05

2 Answers 2


Debugging the issue

The big clue here is the error message:

usbhid: 9-2:1.1: couldn't find an input interrupt endpoint

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:

$ xinput set-int-prop 2 "Device Enabled" 8 0

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.

$ sudo 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.

  1. Go to bios, usb configuration,
  2. USB debugging must be disabled
  3. Save and Exit.

Problem Solved.

  • Are you talking about an Android, or a pc?
    – Xen2050
    Oct 30, 2018 at 18:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .