I am using Debian's unofficial amd64 distribution. I am running the kernel.org 2.6.x kernels. Every once in a while my system becomes unresponsive to USB keyboard/mice. I am using the Microsoft Wireless Desktop Keyboard and Mice. I can still access the machine remotely. I have to reboot it either remotely or by hitting the switch. dmesg is full of the following message. drivers/usb/input/hid-core.c: input irq status -75 received
What specific kernel version does this happen on? Can you try 2.6.12-rc6?
I have faced this problem with all the kernels that I have used till now in the 2.6 series. I am currently running the 2.6.9 kernel. I will test this out with the 2.6.12-rc6 and post what happens.
Tested 2.6.12-rc6 bug still exists. dmesg is still full of the message drivers/usb/input/hid-core.c: input irq status -75 received
I just installed the 2.6.12 kernel. I am still facing the same problems with system becoming unresponsive to input from keyboard or mouse. dmesg is full of the following messages. drivers/usb/input/hid-core.c: input irq status -75 received When I reboot I see the same messages once I load usbhid module. I need to reboot again and then things settle down only till the next freeze. I am using the Microsoft Desktop Pro keyboard.
Im using Fedora Core 4 ( Kernel 2.6.12-1.1398_FC4 ) and i experience the same problem. Im using Microsoft Wireless Keyboad and Mice. The Keyboard still works fine. Sometimes unplug/ replug the connector another usb port helps, most times i have to reboot the machine. Error appears with almost every kernel version i tried since 2.6.8
Looks like an input issue...
I am experiencing the same problem on FC4 with their kernel 2.6.12-1.1398_FC4 (32-bit athlon). Summary: - constant stream of: drivers/usb/input/hid-core.c: input irq status -75 received - keyboard / mouse is Microsoft Wireless Desktop - only on some boots, not all - keyboard works in this state, but mouse does not. Unplugging, waiting 10 seconds, and replugging in the same USB socket does not fix things. I am not a kernel hacker, but here are some observations from the souce code. - -75 is EOVERFLOW - host/uhci-q.c: uhci_map_status maps TD_CTRL_BABBLE to EOVERFLOW - Documentation/usb/error-codes.txt says: EOVERFLOW (*) The amount of data returned by the endpoint was greater than either the max packet size of the endpoint or the remaining buffer size. "Babble". (*) Error codes like -EPROTO, -EILSEQ and -EOVERFLOW normally indicate hardware problems such as bad devices (including firmware) or cables. I am not convinced this is a hardware error, but it might be the case.
My system (see above) got into this state again and I did a little bit of testing. - the messages stop when the keyboard/mouse is unplugged. - they start up again when it is plugged in again. Even if it is to a different USB port. - after a reboot (actually, power cycle) of the computer, all is well To me, this sounds as if the kernel gets into a bad state that won't clear. The original error might be in the device, but its persistance seems to be in the kernel. Just a guess, of course.
Created attachment 5638 [details] lsusb output Ubuntu Linux 2.6.10-5-386 This happens to me aswell, it looks like a key is stuck, unplugging the usb devices solves it. It appears to happen mostly when pressing some of the "multimedia buttons". This device only works if it is connected thru my usb hub, directly on to any of the ports on the pc the keyboard doesnt function at all. Attached is the lsusb output.
Still present on 2.6.13-rc6? If so, please reopen the bug with the new kernel log information.
It is still present in the latest 2.6.15.1 kernel. dmesg is just full of drivers/usb/input/hid-core.c: input irq status -75 received The mouse becomes unresponsive then. Only a power cycle fixes it.
Still an issue on 2.6.15 or 2.6.16-rc5?
Its still a issue with the stable 2.6.15.1 kernel. I havent upgraded after that. I will try the latest rc5 kernel and post if its an issue.
The latest 2.6.16-rc5 has the same problem. Rebooting from Windows to Linux causes the problem on every switch. Power cycle fixes the issue, sometimes more than one power cycle is needed. I havent used the rc5 kernel long enough to see how long it takes for it break just by using Linux.
I have seen a similar problem in 2.6.14 through 2.6.16.5. I do not dual boot, and use a Saitek Eclipse keyboard and Logitech Trackman Wheel... The amount of time required to trigger this seems to vary, from less than a day to several days. It has happened while the box is currently in use, and while the box is idle overnight. I have tried .configs with USB suspend enabled and disabled. This problem only seems present on my VIA MASTER2-FAR dual Opteron board, and I have not seen it on any of my other systems using AMD ATI or Nvidia chipsets.
I noticed another thing that switching from different versions of kernel also seeming to cause the problem. I also do have the MSI K8T Neo-FIS2R motherboard based on VIA chipset.
Just compiled the latest 2.6.18 kernel. The problem is still present. Power cycle helps to stop this problem. Mouse doesnt respond at all while the keyboard works fine.
Oct 4 13:41:02 ophir kernel: drivers/usb/input/hid-core.c: input irq status -75 received On boot I get errors like the one above until I unplug the USB cable. Re-plugging the USB cable helps, in that the errors usually go away. # uname -sr Linux 2.6.17-1.2187_FC5 # dmesg | grep input input: Microsoft Microsoft Wireless Optical Desktop� 1.00 as /class/input/input0 input: USB HID v1.11 Keyboard [Microsoft Microsoft Wireless Optical Desktop� 1.00] on usb-0000:00:10.0-2 input: Microsoft Microsoft Wireless Optical Desktop� 1.00 as /class/input/input1 input: USB HID v1.11 Mouse [Microsoft Microsoft Wireless Optical Desktop� 1.00] on usb-0000:00:10.0-2 # lspci | grep VIA | egrep -v "Multimedia|IDE|ISA" 00:00.0 Host bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333] 00:01.0 PCI bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333 AGP] 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 50) 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 50) 00:10.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51) 00:11.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 23) 00:11.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 23)
This is weird. I just installed vanilla kernel 2.6.18 and the problems seems to have gone away. Maybe it is related to the fact that I have tried to build minimal kernel with as little stuff enabled as possible. Either way so far I was unable to observe this problem in my 2.6.18. Rebooting back to Linux 2.6.17-1.2187_FC5 makes the bug come back with vengeance.
I thought the same when I compiled the kernel. I have a dual boot, booting back from windows made it come back immediately. For now I am running the 2.6.18 kernel After the initial breakage I havent seen it till now. The other thing being I havent rebooted into windows yet since then.
If anyone is still having problems related to this bug, please try using either 2.6.20 or 2.6.21 and follow the instructions in the kernel source file Documentation/usb/usbmon.txt. Attach the usbmon trace you get showing what happens when the -75 errors start to occur.
Please reopen this bug if: - it is still present with kernel 2.6.22 and - you are able to provide the requested information.