Bug 154539 - Kernel 2.6.11-1.14 & 2.6.11-1.27 break USB mouse/keyboard.
Kernel 2.6.11-1.14 & 2.6.11-1.27 break USB mouse/keyboard.
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-12 11:13 EDT by Adam Bowns
Modified: 2015-01-04 17:18 EST (History)
7 users (show)

See Also:
Fixed In Version: kernel-2.6.14-1.1637_FC4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-26 09:20:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Adam Bowns 2005-04-12 11:13:49 EDT
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:
Comment 1 Adam Bowns 2005-04-12 13:03:10 EDT
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
Comment 2 Kent Engström 2005-04-24 12:33:44 EDT
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.
Comment 3 Edgar Hoch 2005-04-28 07:55:59 EDT
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.
Comment 4 Adam Bowns 2005-05-23 16:41:11 EDT
I've just upgraded to kernel-2.6.11-1.27_FC3 and I am still having the same problem.
Comment 5 Mike 2005-06-01 00:26:17 EDT
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]
Comment 6 Dave Jones 2005-06-01 02:00:27 EDT
do you have legacy usb emulation enabled in your bios ?
Comment 7 Adam Bowns 2005-06-01 09:03:28 EDT
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.
Comment 8 Mike 2005-06-01 09:52:53 EDT
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.

Comment 9 Adam Bowns 2005-06-01 12:30:09 EDT
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.
Comment 10 Wouter Beek 2005-06-15 15:24:09 EDT
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+.
Comment 11 Dave Jones 2005-07-15 15:00:32 EDT
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.
Comment 12 Adam Bowns 2005-07-16 14:07:21 EDT
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.
Comment 13 Adam Bowns 2005-07-16 14:33:32 EDT
Sorry guys, I spoke to soon. USB keyboard froze up again just like before, it
just took a long time to happen.
Comment 14 Mike 2005-07-18 11:26:15 EDT
>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. )
Comment 15 Mike 2005-07-26 23:00:08 EDT
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.)
Comment 16 Kare Nuorteva 2005-08-19 16:19:04 EDT
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).  
Comment 17 A.J. Bonnema 2005-08-20 05:38:56 EDT
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.
Comment 18 Kare Nuorteva 2005-08-20 09:09:37 EDT
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
Comment 19 Kare Nuorteva 2005-08-20 09:16:36 EDT
Additional information about my hardware configuration:
- Logitech UltraX Flat keyboard (USB/wired)
- Logitech MX1000 mouse
- Asus A8N-SLI Premium motherboard
Comment 20 Dave Jones 2005-08-20 14:17:26 EDT
Kare, thats a completely unrelated oops to this bug (and is fixed in the kernel
in updates-testing)
Comment 21 A.J. Bonnema 2005-08-20 21:21:37 EDT
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 
Comment 22 Mike 2005-08-25 00:24:14 EDT
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?
Comment 23 A.J. Bonnema 2005-09-17 07:17:58 EDT
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.
Comment 24 Dave Jones 2005-09-30 03:12:40 EDT
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.
Comment 25 Dave Jones 2005-11-10 15:21:23 EST
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.
Comment 26 Adam Bowns 2005-11-26 09:20:46 EST
Yes, the new kernel seems to have fixed the bug. I’m happy to call it closed.

Note You need to log in before you can comment on or make changes to this bug.