5

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
 *-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
makhlaghi
  • 681
  • Could you take a picture of this? – slm Feb 24 '14 at 01: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 '14 at 03:00
  • It seems like an issue with your keyboard. Do you have another keyboard to try? – slm Feb 24 '14 at 03:03
  • Not right now! I will try to find one to try it out. How did you guess it is from the keyboard? – makhlaghi Feb 24 '14 at 03:04
  • usbhid is the USB human interface driver, it would seem tha this driver is getting either bogus input from the keyboard or is losing connectivity w/ it. I would 1/2 expect messages in your dmesg too related to this. Searching for "usbhid: couldn't find an input interrupt endpoint" seems to bear this out. – slm Feb 24 '14 at 03:07
  • In the 1339 lines of dmesg, this error has occurred 4 times, all four times after a few lines about my mouse! My keyboard is mentioned once with usb 3-2: and this error is not close. Might this suggest the problem is with my mouse? It recognizes the brand and type of my mouse, but not my keyboard! – makhlaghi Feb 24 '14 at 03:17
  • 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 '14 at 03:19
  • 1
    See here for details on how to disable: my A shows the steps: http://unix.stackexchange.com/questions/105870/disable-the-external-keyboard-from-a-script/105892#105892 – slm Feb 24 '14 at 03:23
  • I tried the commands and they did disable the mouse. Thanks. So you suggest that the only solution is to replace the mouse? – makhlaghi Feb 24 '14 at 03:40
  • That would be my first thing to try, and see if the issue is gone longer term. This is a very unusual problem though, I've never seen it before. – slm Feb 24 '14 at 03:41
  • Supposing the mouse is really the culprit, isn't there any software solution to this problem? Or do I permanently have to move to a new mouse if I want to avoid this problem? – makhlaghi Feb 24 '14 at 03:42
  • Possibly. I'd need to know more about the mouse. sudo lshw -c input to find out more about this mouse. – slm Feb 24 '14 at 03:45
  • I just put the output of lshw -c input into the question. – makhlaghi Feb 24 '14 at 03:53
  • This looks to be a known issue with that mouse: http://forums.debian.net/viewtopic.php?f=7&t=62907. One "workaround" was to use USB3 ports for the mouse. http://forums.fedoraforum.org/archive/index.php/t-284747.html – slm Feb 24 '14 at 04:01
  • The mouse was already in a USB3 port! I even tried moving it to a USB2 port, but the problem still remains. So the problem is in the hardware. Now I understand. – makhlaghi Feb 24 '14 at 04:27
  • It would appear so. The kinzu mice seem to have a fair amount of issues. – slm Feb 24 '14 at 04:29
  • Thanks for your patience and nice explanations. Could you write this as an answer, so I can accept it and close this issue here. – makhlaghi Feb 24 '14 at 04:42
  • 1
    I wrote up our findings as an A. – slm Feb 24 '14 at 05:05

2 Answers2

6

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.

Community
  • 1
slm
  • 369,824
-1
  1. Go to bios, usb configuration,
  2. USB debugging must be disabled
  3. Save and Exit.

Problem Solved.

Stephen Rauch
  • 4,239
Wilmer
  • 1