Bug 756300

Created attachment 540572 [details]
alcik's smolt profile

Dell Latitude 6510 - Fedora 14

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).

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     : 2.6.35.14
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

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: 2.6.35.14-96.fc14. 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.

Well, it looks like it was a coincidence. This time I was rebooting my box with 2.6.35.14-96.fc14 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.

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: 2.6.35.14-106.fc14.x86_64, 2.6.35.14-103.fc14.x86_64 and 2.6.35.14-100.fc14.x86_64. 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.

@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 :-).

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.

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.

That's a shame - everything was working fine before late 2011. A regression in the same release is not a good thing :(

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).

@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.

regards

Not nvidia related for me either. I'm using the default intel drivers.

[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

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).

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.

Dave.

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.

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.

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?

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.

Hello,

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.

Is this still a problem with 3.8.2 in updates-testing?

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
3.8.4-202.fc18.x86_64

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

Does it occur without the proprietary module loaded?

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?

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.

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.