From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Firefox/1.0.2 Fedora/1.0.2-1.3.1 Description of problem: Since upgrading to kernel 2.6.11-1.14 this morning, my keyboard has started to randomly stop responding. It works fine for a while (5-10mins), then will all of a sudden not respond to anything even pressing Num or Caps lock will not make the lights come on or off. When I remove the USB connector and re-insert it is good for another few minutes but then the problem repeats. On removal of the USB connector I get the following in my log: - hal.hotplug[5531]: DEVPATH is not set hal.hotplug[5567]: DEVPATH is not set kernel: usb 3-2: USB disconnect, address 4 And upon re-insertion I get: - kernel: usb 3-2: new low speed USB device using uhci_hcd and address 5 hal.hotplug[5637]: DEVPATH is not set kernel: input: USB HID v1.10 Keyboard [Logitech Logitech USB Keyboard] on usb-0000:00:11.2-2 hal.hotplug[5694]: DEVPATH is not set kernel: input: USB HID v1.10 Mouse [Logitech Logitech USB Keyboard] on usb-0000:00:11.2-2 The keyboard is a Logitech Internet Navigator Keyboard, and I can confirm that it was working fine with the previous kernel release. On a separate note which *could* be related, this kernel seems to have fixed bug 134443 which I was experiencing right up until upgrading the kernel this morning. Version-Release number of selected component (if applicable): kernel-2.6.11-1.14_FC3 How reproducible: Always Steps to Reproduce: 1.Type a for a few minutes. Actual Results: Keyboard stops responding. Need to re-insert USB connector to make it work again. Then problem repeats. Expected Results: Keyboard should work as normal. Additional info:
I switched back to kernel-2.6.10-1.770_FC3 and the keyboard problem went away again, so it seems pretty likely that the problem was introduced in kernel-2.6.11-1.14_FC3. Something I forgot to mention is that kernel-2.6.11-1.14_FC3 also seemed to fix Bug 143924. Switching back to kernel-2.6.10-1.770_FC3 re-introduced Bug 143924 and Bug 134443. Not that it is necessary, but for information only, removing the keyboard on kernel-2.6.10-1.770_FC3 gives: - kernel: usb 3-2: USB disconnect, address 4 hal.hotplug[6450]: DEVPATH is not set hal.hotplug[6501]: DEVPATH is not set Re-connecting the keyboard on kernel-2.6.10-1.770_FC3 gives: - kernel: usb 3-2: new low speed USB device using uhci_hcd and address 5 hal.hotplug[6555]: DEVPATH is not set kernel: input: USB HID v1.10 Keyboard [Logitech Logitech USB Keyboard] on usb-0000:00:11.2-2 hal.hotplug[6635]: DEVPATH is not set kernel: input: USB HID v1.10 Mouse [Logitech Logitech USB Keyboard] on usb-0000:00:11.2-2
I have been having similar problems with my USB mouse after upgrading to 2.6.11-1.14_FC3. After a couple of minutes, it stops working. Unplugging it and plugging it in again makes it work again. Bus 003 Device 009: ID 046d:c001 Logitech, Inc. N48/M-BB48 [FirstMouse Plus] The computer is an IBM Thinkpad R40. The mouse worked flawlessly with earlier kernels.
I have the same problem with Logitech USB mouse (MousMan Wheel). hal.hotplug[9431]: DEVPATH is not set kernel: usb 3-2: USB disconnect, address 15 kernel: usb 3-2: new low speed USB device using uhci_hcd and address 16 hal.hotplug[9493]: DEVPATH is not set kernel: input: USB HID v1.10 Mouse [Logitech USB Mouse] on usb-0000:00:1d.1-2 The computer is an IBM Thinkpad T42p with FC3, kernel 2.6.11-1.14_FC3.
I've just upgraded to kernel-2.6.11-1.27_FC3 and I am still having the same problem.
I just started having this problem ( USB Mouse constantly locking up ) after updating to kernel-2.6.11-1.27_FC3. Reverting back to 2.6.11-1.14_FC3 lets me use the mouse without problem. Bus 001 Device 003: ID 046d:c001 Logitech, Inc. N48/M-BB48 [FirstMouse Plus]
do you have legacy usb emulation enabled in your bios ?
I just checked it and it was set to âAutoâ. I tried disabling it, but got a âNo keyboardâ error from the bios, so couldn't proceed any further. I tried enabling it, it booted fine with no errors, but the same problem occurred after only a few minutes of use.
Dave Jones: "do you have legacy usb emulation enabled in your bios ?" There are no provisions for USB types in the BIOS on this laptop. It's a Sony VAIO PCG-R505TEK with the following USB hub hardware: 00:1f.2 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #1) (rev 03) 00:1f.4 USB Controller: Intel Corp. 82801BA/BAM USB (Hub #2) (rev 03) I typically run both a USB mouse, indicated previously, and a USB keboard: Bus 001 Device 004: ID 046d:c303 Logitech, Inc. (Logitech Y-BC9) The problem shows up mostly at home where I use the keyboard shown and only occasionally at work with a different Logitech Keyboard. In both locations I use the same mouse. Both keyboards have their own USB Bus connections but it doesn't seem to make any difference whether I use the laptop, docking station, or the keyboard bus connections. The mouse still locks up every few seconds. I can reset it by unplugging the mouse and re-inserting it into the USB port.
When I disabled legacy USB and got the comical bios error: - âNo keyboard present, press F1 to continue or ESC to enter BIOS setupâ I never tried pressing F1 to continue. I've just tried it, I don't get keyboard support in grub, but the keyboard works again once the kernel has loaded. I was just in the process of typing this report saying disabling legacy USB seems to have fixed the problem when guess what... the keyboard froze again and needed pulling out and putting in again. Disabling legacy USB certainly causes the intervals between having to unplug/plug greater, so it must be doing some good, but it doesn't fix the problem, just reduces it a bit. Throughout this problem my Logitech USB mouse has worked flawlessly, unlike the other posters. I've dug out a USB -> ps2 converter for my keyboard so I can test out kernel-2.6.11-1.27_FC3 for an extended period to see if anything happens to the mouse.
Hi, I experience similar problems. When using FC3 with kernel 2.6.9, my Logitech 2-butten + wheel USB mouse worked fine. All subsequent kernel updates caused the mouse to malfunction after a few minutes. It would even stop my internet connection and only a reboot would help. Tried a different (PS/2) mouse and the problem was gone. Now I installed FC4 (with kernel 2.6.11) yesterday, and the same problem applies. It must be something in kernel 2.5.10+.
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.
Yes, the update seems to have done the trick. Iâve been using the computer for a few hours now without any problems, both mouse and keyboard seem fine. However, Iâm using FC4 now so I canât say for sure that the bug is fixed in FC3 so if any of the other guys still using FC3 could confirm this then Iâll be happy to close the bug down.
Sorry guys, I spoke to soon. USB keyboard froze up again just like before, it just took a long time to happen.
>An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) >Please report whether or not it fixes your problem. After updating late last week to this kernel on FC3 I have had no further problems with the USB mouse locking up. ( Reference comments 5 and 8 above. )
As an update to this bug I have to sadly report that the problem has not gone away completely. It is much, much, better in that the symptom only occurs occasionally now. I'd say once every couple of days. When it does occur, it seems to just go through a bit of an ornery spell. I have to unplug the mouse and replug it in several times during the course of an hour or so, but it straightens out and works fine again until the next ornery spell. (Reference comments 5, 8, and 14 above.)
I'm having exactly the same behaviour as initally reported with the following setup: FC4 x86_64 kernel-smp-2.6.12-1.1398_FC4 AMD Athlon X2 USB mouse works without any problems at all. USB keyboard works only occasionally and with the normal kernel I've not noticed any issues. In one occasion I was able to login to X (namely entering username and passwd), then keyboard froze. However, I was able to ctrl+alt-f1 to shell and keyboard worked as usual. When I switched back to X session, keyboard froze again. Most of the time keyboard doesn't work at all. When I type in something I'm able to see cursor flash (like it flashes when you enter a passwd on login) on a gnome-terminal every time when keyboard freezes. Keyboard failure seems similar to the behaviour that I encountered when I installed evdev-driver on a different FC4 i386 box and tried to make mouse horizontal scroll buttons work. (For those who care, horizontal scroll didn't work and keyboard stopped responding).
I concur with the last post of Kare Nuorteva: the USB keyboard works a few minutes only with the SMP-kernel. Even if I switch to using PS2, after considerably longer (say 20 minutes in stead of 5 minutes) the keyboard stops working. In my case what happens after 5 (or 20) minutes is, that the key that I happen to use when the failure occurs is the one that gets repeated "infinitely" fast, rendering the keyboard unusable. I have a logitech cordless keyboard and mouse (MX3100), an ASUS A8N-SLI de Luxe motherboard and a AMD Athlon 64 X2 processor. And I am running an updated FC4 kernel (2.6.12-1.1398). I can only work normally in the UP-kernel, as the SMP-kernel goes berserk on the keyboard.
The following messages appear in /var/log/messages: Aug 20 13:07:52 triton kernel: Unable to handle kernel NULL pointer dereference at 0000000000000024 RIP: Aug 20 13:07:52 triton kernel: <ffffffff8011dae1>{query_current_values_with_pending_wait+65} Aug 20 13:07:52 triton kernel: PGD 2e128067 PUD 2e129067 PMD 0 Aug 20 13:07:52 triton kernel: Oops: 0002 [1] SMP Aug 20 13:07:52 triton kernel: CPU 1 Aug 20 13:07:52 triton kernel: Modules linked in: vfat fat udf parport_pc lp parport autofs4 rfcomm l2cap bluetooth sunrpc ipt_REJECT ipt_state ip_conntrack iptable_filter ip_tables md5 ipv6 dm_mod raid1 video button battery ac usb_storage ohci1394 ieee1394 ohci_hcd ehci_hcd i2c_nforce2 i2c_core shpchp snd_intel8x0 snd_ac97_codec snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc forcedeth sk98lin floppy ext3 jbd sata_nv libata sd_mod scsi_mod Aug 20 13:07:52 triton kernel: Pid: 7, comm: events/1 Not tainted 2.6.12-1.1398_FC4smp Aug 20 13:07:52 triton kernel: RIP: 0010:[<ffffffff8011dae1>] <ffffffff8011dae1>{query_current_values_with_pending_wait+65} Aug 20 13:07:52 triton kernel: RSP: 0000:ffff8100023f1dc8 EFLAGS: 00010206 Aug 20 13:07:52 triton kernel: RAX: 000000000000000e RBX: 0000000000000000 RCX: 00000000c0010042 Aug 20 13:07:52 triton kernel: RDX: 000000000000000a RSI: 0000000000000001 RDI: 0000000000000000 Aug 20 13:07:52 triton kernel: RBP: 0000000000000000 R08: ffff8100023f0000 R09: 0000000000000003 Aug 20 13:07:52 triton kernel: R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000002 Aug 20 13:07:52 triton kernel: R13: 0000000000000000 R14: 0000000000000292 R15: ffffffff80112950 Aug 20 13:07:52 triton kernel: FS: 00002aaaaaad55a0(0000) GS:ffffffff8050d800(0000) knlGS:0000000000000000 Aug 20 13:07:52 triton kernel: CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b Aug 20 13:07:52 triton kernel: CR2: 0000000000000024 CR3: 000000002e0a1000 CR4: 00000000000006e0 Aug 20 13:07:52 triton kernel: Process events/1 (pid: 7, threadinfo ffff8100023f0000, task ffff8100023940f0) Aug 20 13:07:52 triton kernel: Stack: 0000000000000000 ffffffff8011e0b1 0000000000000001 ffff81003ebf1e00 Aug 20 13:07:52 triton kernel: ffff81003ebf1e30 ffffffff802e68a3 0000000000000000 0000000000000003 Aug 20 13:07:52 triton kernel: 0000000000000001 0000000000000020 Aug 20 13:07:52 triton kernel: Call Trace:<ffffffff8011e0b1>{powernowk8_get+129} <ffffffff802e68a3>{cpufreq_get+115} Aug 20 13:07:52 triton kernel: <ffffffff8011298a>{handle_cpufreq_delayed_get+58} <ffffffff8014b9ec>{worker_thread+476} Aug 20 13:07:52 triton kernel: <ffffffff80134720>{default_wake_function+0} <ffffffff801326b3>{__wake_up_common+67} Aug 20 13:07:52 triton kernel: <ffffffff8014b810>{worker_thread+0} <ffffffff80150489>{kthread+217} Aug 20 13:07:52 triton kernel: <ffffffff80135ca0>{schedule_tail+64} <ffffffff8010f76b>{child_rip+8} Aug 20 13:07:52 triton kernel: <ffffffff801503b0>{kthread+0} <ffffffff8010f763>{child_rip+0} Aug 20 13:07:52 triton kernel: Aug 20 13:07:52 triton kernel: Aug 20 13:07:52 triton kernel: Code: 89 47 24 89 57 20 31 c0 48 83 c4 08 c3 66 90 48 83 ec 28 f7 Aug 20 13:07:52 triton kernel: RIP <ffffffff8011dae1>{query_current_values_with_pending_wait+65} RSP <ffff8100023f1dc8> Aug 20 13:07:52 triton kernel: CR2: 0000000000000024 Aug 20 13:07:52 triton kernel: <3>Debug: sleeping function called from invalid context at include/linux/rwsem.h:43 Aug 20 13:07:52 triton kernel: in_atomic():0, irqs_disabled():1 Aug 20 13:07:52 triton kernel: Aug 20 13:07:52 triton kernel: Call Trace:<ffffffff8013abd5>{profile_task_exit+21} <ffffffff8013bff2>{do_exit+34} Aug 20 13:07:52 triton kernel: <ffffffff80265f79>{do_unblank_screen+137} <ffffffff80124286>{do_page_fault+1926} Aug 20 13:07:52 triton kernel: <ffffffff8035ac32>{thread_return+0} <ffffffff8035ac84>{thread_return+82} Aug 20 13:07:52 triton kernel: <ffffffff8013434d>{activate_task+141} <ffffffff80112950>{handle_cpufreq_delayed_get+0} Aug 20 13:07:52 triton kernel: <ffffffff8010f5b5>{error_exit+0} <ffffffff80112950>{handle_cpufreq_delayed_get+0} Aug 20 13:07:52 triton kernel: <ffffffff8011dae1>{query_current_values_with_pending_wait+65} Aug 20 13:07:52 triton kernel: <ffffffff8011e0b1>{powernowk8_get+129} <ffffffff802e68a3>{cpufreq_get+115} Aug 20 13:07:52 triton kernel: <ffffffff8011298a>{handle_cpufreq_delayed_get+58} <ffffffff8014b9ec>{worker_thread+476} Aug 20 13:07:52 triton kernel: <ffffffff80134720>{default_wake_function+0} <ffffffff801326b3>{__wake_up_common+67} Aug 20 13:07:52 triton kernel: <ffffffff8014b810>{worker_thread+0} <ffffffff80150489>{kthread+217} Aug 20 13:07:52 triton kernel: <ffffffff80135ca0>{schedule_tail+64} <ffffffff8010f76b>{child_rip+8} Aug 20 13:07:52 triton kernel: <ffffffff801503b0>{kthread+0} <ffffffff8010f763>{child_rip+0} Aug 20 13:07:52 triton kernel: Aug 20 13:13:28 triton su(pam_unix)[3823]: session closed for user root Aug 20 13:13:36 triton gconfd (kare-3081): Exiting Aug 20 13:13:36 triton gdm(pam_unix)[2976]: session closed for user kare Aug 20 13:13:36 triton gdm[2817]: Master rebooting... Aug 20 13:13:36 triton dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1 Aug 20 13:13:38 triton gpm[2627]: O0o.oops(): [console.c(83)]: Aug 20 13:13:38 triton gpm[2627]: Opening console failed. Aug 20 13:14:31 triton shutdown: shutting down for system halt Aug 20 13:14:31 triton init: Switching to runlevel: 0
Additional information about my hardware configuration: - Logitech UltraX Flat keyboard (USB/wired) - Logitech MX1000 mouse - Asus A8N-SLI Premium motherboard
Kare, thats a completely unrelated oops to this bug (and is fixed in the kernel in updates-testing)
I quote from an email out of the fedora users mailing list, possibly linking this bug to bugnr 162865. After executing the statements recommended in that bug (re-executing kudzu after renaming hwconf and modprobe.conf), the behaviour changed from "infinitely fast" repetition of the last key, to ignoring keyboard input. Well.... it is a change. Follows the email: Start quote ============================================ Louis Lagendijk wrote: > There is another bug-report (162865) that may apply as weel: there is a > bug in the combination dual core processor + power now. Check the latest > kernel from testing. That fixed my problems on my AMD64 X2..... > Louis Thanks for the hint. I had already updated to 2.6.13, so I executed the suggested statements including kudzu. However, after rebooting in the smp kernel, after a while the OS stops responding to the keyboard. This is a change from the old situation, where the OS would repeat the last key extremely fast, rendering the keyboard useless too. Bottomline though is: it doesn't work yet. Anyway, thanks for the hint. Guus. ============================================ End quote
Additional information as regards comments 5, 8, 14, and 15. I swapped the mouse I described above with another, newer, mouse. This second mouse was the exact same Logitec model as the first. I had exactly the same symptoms with this second mouse. However ....., I bought a new mouse ( Viewsonic Viewmate MC201 USB ) and so far ( 2 days ) I have not had a single freeze incident. Is there something "different" in the way Logitec USB devices communicate?
Since the update to kernel 2.6.12-1.1447_FC4smp I have had no mouse or keyboard problems any more. As far as I am concerned, the problem was solved. Guus Bonnema.
Mass update to all FC4 bugs: An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream kernel (2.6.13.2). As there were ~3500 changes upstream between this and the previous kernel, it's possible your bug has been fixed already. Please retest with this update, and update this bug if necessary. Thanks.
2.6.14-1.1637_FC4 has been released as an update for FC4. Please retest with this update, as a large amount of code has been changed in this release, which may have fixed your problem. Thank you.
Yes, the new kernel seems to have fixed the bug. Iâm happy to call it closed.