Mouse cursor stops when moves around.

[nimnull22]

Does anyone notice that mouse cursor periodically stops or freezes up when you moves it around or drug something around.

0: 23475 IO-APIC-edge timer
1: 2200 IO-APIC-edge i8042
8: 1 IO-APIC-edge rtc0
9: 95 IO-APIC-fasteoi acpi
12: 136 IO-APIC-edge i8042
14: 9205 IO-APIC-edge ata_piix
15: 0 IO-APIC-edge ata_piix
16: 4922 IO-APIC-fasteoi uhci_hcd:usb5, i915, yenta
17: 0 IO-APIC-fasteoi mmc0, mmc1, Intel ICH6
18: 0 IO-APIC-fasteoi uhci_hcd:usb4
19: 14471 IO-APIC-fasteoi uhci_hcd:usb3 <---- this is my mouse


Is it because of debug modules in kernel or somewhere else??
I use fxce, but in Gnome the same issue.

Thanks

And second question:
I have this in dmesg:

type=1401 audit(1287387798.015:6): security_compute_sid: invalid context system_u:system_r:xauth_t:s0-s0:c0.c1023 for scontext=system_u:system_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xauth_exec_t:s0 tclass=process

Should we be worry about this message?

Thanks.

[CSchwangler]

Does anyone notice that mouse cursor periodically stops or freezes up when you moves it around or drug something around.

I have used KDE and XFCE of F14 and am now using LXDE but never had a problem with a frozen mouse cursor. Can you check if something heavy is running on your machine, e.g. by opening top or htop and inspect the list while you move the mouse cursor.

I am pretty sure that it is not related to debug code, since I am running F14 on an old Pentium-M 1.5 GHz and don't have the problem.

[nimnull22]

May be I was not clear when I described this issue - mouse cursor freezes for about 0,1~0,2 sec. But it can be noticed and happened every 20-15 second.

I will try to use vesa video driver to check, because I have i915GM video card and then will open bug about it.

Thanks

[jpollard]

It may depend on your system. When memory is limited and there
are lots of active windows (GIMP is one such), then the X server can
start paging. This can cause such lags, but usually it stops once the
system has equalized memory against the X server so it can keep up
with the movement.

If it occurs regularly you might check to see if cron is running something
as well. 15 second intervals is almost like a clock poll activity.

[nimnull22]

I have got perfectly clean and unloaded Fedora:

Cn Avg residency P-states (frequencies)
C0 (cpu running) ( 0.1%)
polling 0.0ms ( 0.0%)
C1 halt 0.0ms ( 0.0%)
C2 0.1ms ( 0.0%)
C3 103.0ms (99.9%)

Wakeups-from-idle per second : 9.9 interval: 20.0s
no ACPI power usage estimate available


Problem is - i915 driver (as usual unfortunately). I restart X with vesa driver and do not have any mouse freezes. I going to open the bug report.

Thanks.

[hellork]

I ran into a similar problem with my Microsoft mouse. Problem vanishes when I plug in the Lenovo mouse which uses the same driver which suggests that it is a hardware problem with the mouse.

The Lenovo mouse has a different problem, however. when I middle click something, it occasionally pastes twice! Running xev shows the mouse is actually sending two click events sometimes. Probably a dirty switch will be found if I take it apart...

[nimnull22]

No, no, no. This problem is much deeper. It is because:

Chris Wilson
Thu, 12 Aug 2010 12:58:46 -0700
Polling for a VGA device on an old system can be quite expensive,
causing latencies on the order of 600ms. As we hold the mode mutex for
this time and also need the same mutex to move the cursor, we trigger a
user-visible stall.

The real solution would involve improving the granulatity of the
locking and so perhaps performing some of the probing not under the lock
or some other updates can be done under different locks. Also reducing the
cost of probing for a non-existent monitor would be worthwhile. However,
exposing a parameter to disable polling is a simple workaround in the
meantime.

In order to accommodate users turning polling on and off at runtime, the
polling is potentially re-enabled on every probe. This is coupled to
the user calling xrandr, which seems to be a vaild time to reset the
polling timeout since the information on the connection has just been
updated. (The presumption being that all connections are probed in a
single xrandr pass, which is currently valid.)


And for 36 kernel:
"As of 2.6.36, there are two workarounds. (a) the kernel doesn't attempt
to do load-detection on your machine (the cause of the stutter), (b) there
is a module parameter (/sys/module/drm_kms_helper/parameters/poll) to
disable the polling entirely."

But for 35 kernel, I and others are still waiting for a remedy:
"Petition the Fedora maintainers for a new kernel. The disable polling was
tagged for stable, iirc, so it should be appearing in a kernel update
soon."


Thanks.

[lmcogs]

I have noticed mouse problems similar to this for past week,. At the moment it's ok I'm on 2.6.35.6-48.fc14.x86_64 KDE 4.5.2 and no problems yet.