Bug 756300 - usb mouse and keyboard slow
usb mouse and keyboard slow
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2011-11-23 02:46 EST by Johan Vervloet
Modified: 2013-07-31 22:08 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-07-31 22:08:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
smolt profile (3.60 KB, text/plain)
2011-11-23 02:46 EST, Johan Vervloet
no flags Details
alcik's smolt profile (8.16 KB, text/plain)
2011-12-04 20:32 EST, alcik
no flags Details
alcik's last 3 weeks updates (5.83 KB, text/plain)
2011-12-04 20:36 EST, alcik
no flags Details

  None (edit)
Description Johan Vervloet 2011-11-23 02:46:20 EST
Created attachment 535357 [details]
smolt profile

Description of problem:

I have a Dell Precision M4500 laptop, and I did a clean install of Fedora 16.  Occasionally, the system responds very slow on the usb keyboard and mouse (slow mouse pointer, characters displaying after a delay, or not displaying at all), while there seems no problem when using the keyboard or touchpad of the laptop itself.

Rebooting the system mostly solves the problem.

If after booting the external mouse and keyboard work ok, they won't stop working.  If the problem occurs, it occurs from booting till shutdown.  In that case, the following lines can are present in /var/log/messages.

Nov 23 08:17:26 linux-jve kernel: [   89.109878] irq 17: nobody cared (try booting with the "irqpoll" option)
Nov 23 08:17:26 linux-jve kernel: [   89.109885] Pid: 0, comm: kworker/0:1 Tainted: G         C  3.1.1-2.fc16.x86_64 #1
Nov 23 08:17:26 linux-jve kernel: [   89.109888] Call Trace:
Nov 23 08:17:26 linux-jve kernel: [   89.109891]  <IRQ>  [<ffffffff810b2222>] __report_bad_irq+0x38/0xc3
Nov 23 08:17:26 linux-jve kernel: [   89.109905]  [<ffffffff810b24bc>] note_interrupt+0x176/0x1fa
Nov 23 08:17:26 linux-jve kernel: [   89.109910]  [<ffffffff810b0a0f>] handle_irq_event_percpu+0x15d/0x1a5
Nov 23 08:17:26 linux-jve kernel: [   89.109914]  [<ffffffff810b0a92>] handle_irq_event+0x3b/0x59
Nov 23 08:17:26 linux-jve kernel: [   89.109920]  [<ffffffff81078268>] ? sched_clock_cpu+0x42/0xc6
Nov 23 08:17:26 linux-jve kernel: [   89.109925]  [<ffffffff810b2c7c>] handle_fasteoi_irq+0x80/0xa4
Nov 23 08:17:26 linux-jve kernel: [   89.109931]  [<ffffffff81010af9>] handle_irq+0x88/0x8e
Nov 23 08:17:26 linux-jve kernel: [   89.109937]  [<ffffffff814c040d>] do_IRQ+0x4d/0xa5
Nov 23 08:17:26 linux-jve kernel: [   89.109944]  [<ffffffff814b756e>] common_interrupt+0x6e/0x6e
Nov 23 08:17:26 linux-jve kernel: [   89.109946]  <EOI>  [<ffffffff81014b35>] ? paravirt_read_tsc+0x9/0xd
Nov 23 08:17:26 linux-jve kernel: [   89.109957]  [<ffffffff8126974c>] ? intel_idle+0xd8/0x100
Nov 23 08:17:26 linux-jve kernel: [   89.109962]  [<ffffffff8126972e>] ? intel_idle+0xba/0x100
Nov 23 08:17:26 linux-jve kernel: [   89.109968]  [<ffffffff813a5fce>] cpuidle_idle_call+0xe8/0x182
Nov 23 08:17:26 linux-jve kernel: [   89.109973]  [<ffffffff8100e2e3>] cpu_idle+0xa4/0xe8
Nov 23 08:17:26 linux-jve kernel: [   89.109980]  [<ffffffff814a54dc>] start_secondary+0x23f/0x241
Nov 23 08:17:26 linux-jve kernel: [   89.109983] handlers:
Nov 23 08:17:26 linux-jve kernel: [   89.109988] [<ffffffff81335488>] usb_hcd_irq
Nov 23 08:17:26 linux-jve kernel: [   89.110000] [<ffffffffa028671b>] azx_interrupt
Nov 23 08:17:26 linux-jve kernel: [   89.110003] Disabling IRQ #17

Version-Release number of selected component (if applicable):

Name        : kernel
Arch        : x86_64
Version     : 3.1.1
Release     : 2.fc16

Name        : xorg-x11-drv-nouveau
Arch        : x86_64
Epoch       : 1
Version     : 0.0.16
Release     : 27.20110720gitb806e3f.fc16

How reproducible:

It sometimes just happens when booting

Steps to Reproduce:

1. Boot
Actual results:

slow response to USB mouse and USB keyboard.  Laptop keyboard and touchpad work fine.

Expected results:

USB Mouse and USB keyboard should behave the same way as the laptop keyboard and touchpad

Additional info:

Smolt profile in attachment
Comment 1 alcik 2011-12-04 20:32:22 EST
Created attachment 540572 [details]
alcik's smolt profile

Dell Latitude 6510 - Fedora 14
Comment 2 alcik 2011-12-04 20:36:35 EST
Created attachment 540573 [details]
alcik's last 3 weeks updates

My updates from last 3 weeks (I hibernate every day so no clue about my previous reboots).
Comment 3 alcik 2011-12-04 21:08:09 EST
Same thing here on Fedora 14 on Dell Latitude 6510. 
When using USB mouse, mouse pointer is moving non fluently and slow. In the same time when using touchpad, mouse pointer is fast and fluent (ether with connected and disconnected USB mouse). 
Mouse is wired Logitech optical mouse which works always just fine on the other box. I dont use external USB keybord but when connected one it seems to work a just little slower than laptop's internal. But it could be only my impression. Difference is rather small.
As long a I am using F14 this problem occasionally happened after reboot (hibernating mostly so rare reboots here, but I can guess it was 1 at each 5-10 reboots). After next reboot everything was usually working fine. 

But few days ago after some updates and reboot this happens every time. Rebooting does not help anymore. Mouse pointer's nonfluency makes my USB mouse rather unusable. Also I've checked some other USB mouse. Same effect, while with other computer is working perfectly. 
I hibernate every day, and reboot rarely, so no clue which update could break that. So I attached all my updates from last 3 weeks.

Some package versions:

Name        : kernel
Version     :
Release     : 106.fc14

Name        : xorg-x11-drv-mouse
Version     : 1.5.0
Release     : 5.fc14

Name        : xorg-x11-drv-vesa
Version     : 2.3.0
Release     : 2.fc14
Comment 4 alcik 2011-12-04 21:58:11 EST
I have noticed two things:

1. Some time ago I have set yum up to save 4 previous kernel's releases packages instead of default 2 previous releases. So i have always at least five kernel versions. I have rebooted trying all kernel releases and mouse works OK after reboot with oldest: Strangely enough, I am almost sure, I was rebooting after some of later kernel upgrades and mouse was working fine. 

2. Even more strange is that after reboot (even with current kernel), when X are still starting mouse pointer works perfectly fine - it moves fluently and fast. But just second or two after gdm's "choose a user" window pops up the mouse is going mad again.
Comment 5 alcik 2011-12-05 06:02:47 EST
Well, it looks like it was a coincidence. This time I was rebooting my box with kernel for 3 times. And each time mouse still doesn't work as expected. Or maybe as it was rare to boot with mouse going crazy before it is rare now to boot with mouse working just fine.
Comment 6 Sridhar Dhanapalan 2012-01-08 20:10:24 EST
I'm seeing the same symptoms as alcik on my Dell Latitude E6410. I prefer to use my laptop at work on a stand with a USB keyboard and mouse for better ergonomics, so having a fix for this is important to me.

USB mice and keyboards were working fine before 25 Dec (although I don't reboot often and usually use sw suspend, so the problem might be older than that). I've spent the last two weeks using just the in-built keyboard and touchpad.

Today I tried a USB keyboard and mouse again, and I found a horrible lag. This would happen occasionally in the past, but a reboot or restart of X would usually fix it. This workaround doesn't work any more - the problem now happens every time. Changing the mouse and keyboard doesn't help.

I've tried three kernels:, and I get the same problem on all of them. The mouse pointer moves smoothly for a second while X is starting, but once the gdm greeter is up the pointer becomes laggy. Mice and keyboards are also laggy at TTYs, using gpm at runlevel 3.
Comment 7 alcik 2012-01-08 22:15:55 EST
@Sridhar Dhanapalan: what seems to work for me now (usually), however strange it is, is catching the moment when X are starting (more precise, moment when mouse pointer appears for the first time - this second you wrote about) and then starting moving mouse as fast, randomly and rapidly as I can. Be careful, as you probably, will look like as someone crazy, at least I did. I'm usually keeping those mad activity a short while after gnome logon windows shows. Not always working (I'm trying to reboot as rare as it is possible), but I think worth to try. Please give some info if it works for you too - it may be some kind of clue for RH developers some day :-).
Comment 8 Sridhar Dhanapalan 2012-01-08 23:23:23 EST
No luck for me. I tried moving the mouse around rapidly once the pointer shows. It moves smoothly for a few seconds but then it becomes laggy as gdm starts up.
Comment 9 Josh Boyer 2012-03-01 08:46:08 EST
Johan, are you still seeing this on the latest F16 kernel?

Sridhar and alcik, F14 is EOL.  There is nothing that can be done on those kernels.
Comment 10 Sridhar Dhanapalan 2012-03-01 19:09:23 EST
That's a shame - everything was working fine before late 2011. A regression in the same release is not a good thing :(
Comment 11 Johan Vervloet 2012-03-02 10:32:26 EST
Josh, I often do some distro hopping, and I don't run Fedora any more on this particular laptop.  But I can tell you that this problem is not fedora-specific, I've recently seen it with Linux Mint 12 as well.  I think it might have something to do with the proprietary nvidia drivers, which I install because I run into wors problems with nouveau (see #754882).
Comment 12 alcik 2012-03-02 10:52:08 EST
@Johan and @Josh: I cant speak about other distros but I do not use nvidia drivers. I have some intel based onboard graphics card and as I mentioned before I use xorg-x11-drv-vesa driver.

Im still on F14, but when trying F16-livecd I have not noticed any problems with mouse pointer.

Comment 13 Sridhar Dhanapalan 2012-03-02 18:16:14 EST
Not nvidia related for me either. I'm using the default intel drivers.
Comment 14 Dave Jones 2012-03-22 13:16:28 EDT
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.
Comment 15 Dave Jones 2012-03-22 13:18:24 EDT
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.
Comment 16 Dave Jones 2012-03-22 13:26:48 EDT
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.
Comment 17 Dave Neary 2012-05-31 10:59:18 EDT
I have a Dell Latitude E6500, and have a similar problem. Intermitten laggy mouse. For me, though, it doesn't last from boot until reboot - it will start more or less at random (I've had it happen when the browser, OOo, Empathy and Thunderbord, respectively are the active application. This is running Fedora 17 (installed from F17 Beta, upgraded regularly since).
Comment 18 Dave Neary 2012-05-31 16:31:09 EDT
I just caught top while this was happening, and a few kworker threads were each taking a big chunk of CPU each when the mouse slowed down. That's probably not helpful in diagnosing the problem, but I'm happy to try to figure out what might be causing that to happen, if someone can suggest the tools I can run to get some data for you.

Comment 19 Johan Vervloet 2012-05-31 17:48:17 EDT
As told before, and I am not running Fedora ATM, but this is a problem that also exists on other distros.  I am now experiencing it with Mint 13 and the proprietary nvidia driver.

But, for the good news: I have found a workaround: if you suspend and resume your system, the problem is gone.  A lot quicker than having to reboot.
Comment 20 Sridhar Dhanapalan 2012-05-31 22:41:42 EDT
No dice here - my mouse was slow even after a suspend-resume cycle. Admittedly this is on F14 (Dell Latitude E6410), which I recognise is EOL. Still perplexed as to why everything was working great until only 6 months ago.
Comment 21 Dave Neary 2012-06-01 03:12:03 EDT
Johan: I don't think we're seeing the same problem - a similar symptom, perhaps. I have an Intel graphics card, no nvidia driver. It seems like something is getting priority over refreshing X at the kernel level, and then when the job terminates, everything goes back to normal.

Someone on a forum suggested tracker, but it wasn't the Tracker indexer that was eating CPU when the mouse slowed down, it was kworker threads.

What I could use now is some hints on instrumenting the problem to give better data on the symptom. Anyone know how to track things like X refresh rate, disk I/O (and what processes are responsible for it) and processor load (and what's responsible for it) at the same time, and match them up at the end? I suppose that some combination of bootchart, spew, perf, systemtap, sysstat and iostat could provide insight? But with what magical incantations? Any recommendations?
Comment 22 Martin Edlman 2012-07-11 16:14:56 EDT
I have very same problem with Fedora 17 on HP Pavilion dv7 notebook (Intel i7, 4GB RAM) - all kernels, no update helped. Currently running kernel-3.4.4-5.fc17.x86_64. I didn't have this problem on Fedora 16 or at least I'm not aware of it.

Sometime USB keyboard slows down, notebook keyboard works fine. Unplugging and plugging in the keyboard helps, but I lose xfce4 keybord layout switch plugin settings so I have to set it up again. And it's annoying.

There are no device, usb, module, whatever errors in /var/log/messages nor in dmesg.

Maybe it's only a coincidence, but it happened several times when I was writing a long mail in Thunderbird. Otherwise it happens randomly in various apps.

And the same happened to me also on desktop computer in the office, where I have PS/2 keyboard. Sadly, replugging doesn't help on PS/2. So I had to ssh to the machine and restart xwindows. Or reboot :-(. I replaced the PS/2 keyboard with a USB one so I can replug it, but it's not the solution I like.
Comment 23 jeefoo 2013-01-03 04:02:34 EST

I have the same problem on my Lenovo notebook, USB keyboard and mouse are to slow and delayed. The OS is fedora 17 x86_64, kernel version: 3.6.10-2.fc17.x86_64 #1 SMP

There are no suspicious text in dmesg, till three days before it was work perfectly. I've never had problems like this before. Can be a new kernel problem? I recently updated my kernel.
Comment 24 Josh Boyer 2013-03-14 13:40:51 EDT
Is this still a problem with 3.8.2 in updates-testing?
Comment 25 Johan Vervloet 2013-03-24 09:57:24 EDT
I am running Fedora again, so I can test again :-)

I installed 3.8.2:

yum install kernel kmod-nvidia --enablerepo=updates-testing

uname -r

The problem still occurs.

Excerpt from dmesg:

[   75.249109] irq 17: nobody cared (try booting with the "irqpoll" option)
[   75.249117] Pid: 0, comm: swapper/3 Tainted: PF          O 3.8.4-202.fc18.x86_64 #1
[   75.249118] Call Trace:
[   75.249120]  <IRQ>  [<ffffffff810f133d>] __report_bad_irq+0x3d/0xe0
[   75.249135]  [<ffffffff810f17e7>] note_interrupt+0x1b7/0x200
[   75.249140]  [<ffffffff814fbd00>] ? cpuidle_wrap_enter+0x50/0xa0
[   75.249142]  [<ffffffff814fb310>] ? cpufreq_p4_target+0x120/0x120
[   75.249145]  [<ffffffff810eefc7>] handle_irq_event_percpu+0xa7/0x1f0
[   75.249147]  [<ffffffff814fb310>] ? cpufreq_p4_target+0x120/0x120
[   75.249149]  [<ffffffff810ef151>] handle_irq_event+0x41/0x70
[   75.249151]  [<ffffffff810f2329>] handle_fasteoi_irq+0x59/0x100
[   75.249157]  [<ffffffff8101619f>] handle_irq+0xbf/0x150
[   75.249162]  [<ffffffff81654352>] ? __atomic_notifier_call_chain+0x12/0x20
[   75.249165]  [<ffffffff81654376>] ? atomic_notifier_call_chain+0x16/0x20
[   75.249168]  [<ffffffff8165a46a>] do_IRQ+0x5a/0xe0
[   75.249171]  [<ffffffff8165062d>] common_interrupt+0x6d/0x6d
[   75.249172]  <EOI>  [<ffffffff810868ee>] ? __hrtimer_start_range_ns+0x1be/0x400
[   75.249178]  [<ffffffff814fbd00>] ? cpuidle_wrap_enter+0x50/0xa0
[   75.249181]  [<ffffffff814fbcf9>] ? cpuidle_wrap_enter+0x49/0xa0
[   75.249183]  [<ffffffff814fbd60>] cpuidle_enter_tk+0x10/0x20
[   75.249185]  [<ffffffff814fb999>] cpuidle_idle_call+0xa9/0x260
[   75.249189]  [<ffffffff8101d45f>] cpu_idle+0xaf/0x120
[   75.249193]  [<ffffffff8163f62a>] start_secondary+0x24f/0x251
[   75.249194] handlers:
[   75.249198] [<ffffffff81463930>] usb_hcd_irq
[   75.249215] [<ffffffffa0f558a0>] azx_interrupt [snd_hda_intel]
[   75.249216] Disabling IRQ #17
Comment 26 Josh Boyer 2013-03-24 10:05:36 EDT
Does it occur without the proprietary module loaded?
Comment 27 Johan Vervloet 2013-03-24 10:20:34 EDT
I removed the nvidia drivers, as described on http://solidsmoke.blogspot.be/2011/12/fedora-16-uninstall-proprietary-nvidia.html. I rebooted, nvidia is gone, but the problem still occurs (same messages in stack trace)

Dmesg also still mentions that the kernel is tainted. Maybe because I have virtualbox installed. Could that be a problem?
Comment 28 Fedora End Of Life 2013-07-03 19:26:41 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 29 Fedora End Of Life 2013-07-31 22:08:36 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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