From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050302 Firefox/1.0.1 Fedora/1.0.1-1.3.2 Description of problem: I am experiencing some frustration using a KVM and a USB mouse, which I am finding is not unusual. I have searched the archives and bugzilla and I haven't found any mention of my particular issue. What happens is that, under normal use, the mouse will freeze intermittently, but often enough to make it unusable. After reboot, the mouse will work well for several minutes, but after the first freeze they will recur very frequently. What appears in dmesg when the freeze occurs is dozens of the following line: drivers/usb/input/hid-core.c: input irq status -84 received The red light in the mouse turns off. The mouse will light up and unfreeze when I switch the KVM to the other PC and back to this one. The following lines are recorded in dmesg when I do this: usb 3-1.1: USB disconnect, address 18 usb 3-1.1.1: USB disconnect, address 19 usb 3-1.1: new full speed USB device using uhci_hcd and address 20 hub 3-1.1:1.0: USB hub found hub 3-1.1:1.0: 4 ports detected usb 3-1.1.1: new low speed USB device using uhci_hcd and address 21 input: USB HID v1.10 Mouse [Microsoft Microsoft 3-Button Mouse with IntelliEye(TM)] on usb-0000:00:1d.1-1.1.1 As I said, once I do this the mouse will work for a very short time, usually less than a minute, before freezing again. I tried disabling hyperthreading and running the non-smp kernel, but the freezing occurs either way. Is there a patch, fix, workaround, etc. for this? I have attached my startup dmesg output. The system is a Dell Dimension 8400 running FC3, up to date. The KVM switch is a Belkin OmniView SOHO Series 2-Port KVM Switch with Audio (F1DD102U). The mouse is a USB MS Optical Mouse. The Windows system on the other end of this KVM does not exhibit this problem. P.S. As an aside, if anyone can recommend a KVM for DVI, USB or PS/2, that actually works at 1600x1200, 60Hz on a 20" LCD display, I'd love to hear about it. This unit has one other serious flaw, but it's not FC-related. I have tried two other KVMs which were actually worse. Jan Version-Release number of selected component (if applicable): kernel-smp-2.6.10-1.770_FC3 How reproducible: Always Steps to Reproduce: 1. Connect USB mouse to KVM to PC 2. Boot Fedora and login 3. Do normal work Actual Results: What happens is that, under normal use, the mouse will freeze intermittently, but often enough to make it unusable. After reboot, the mouse will work well for several minutes, but after the first freeze they will recur very frequently. What appears in dmesg when the freeze occurs is dozens of the following line: drivers/usb/input/hid-core.c: input irq status -84 received The red light in the mouse turns off. The mouse will light up and unfreeze when I switch the KVM to the other PC and back to this one. Expected Results: The mouse should have worked normally. Additional info:
Created attachment 111840 [details] Kernel startup dmesg output
I'm seeing a slight variation on this: Running the latest few rawhide kernels (approx. .1226-.1253), my KVM-mouse is not recognized during boot up. If I remove/insert USB connector, the mouse starts working. Keyboard works fine. My setup: PS/2 mouse/keyboard -> Belkin KVM -> "Y-mouse PS/2->USB adapter" -> laptop The messages in /var/log/messages appear normal.... [This worked reliabily before about .1226 or so.]
I noticed that the last kernel that did not have this problem was 2.6.10-1.770_FC3. Perhaps something was changed in the kernel that affects the USB Mouse. I upgraded to FC4 hoping that the problem was resolved but it is not.
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
This bug has been automatically closed as part of a mass update. It had been in NEEDINFO state since July 2005. If this bug still exists in current errata kernels, please reopen this bug. There are a large number of inactive bugs in the database, and this is the only way to purge them. Thank you.