continuous jerky mouse movements while using nouveau driver in 12.04

[psypher]

This first time I started using the nouveau driver was in 12.04. So I would not be able to say if this worked in other Ubuntu versions.

When moving around the screen at random times the mouse movements are very jerky. ou would move i a direction then it suddenly gets stuck for a microsecond breaking workflow. This happens while dragging items or just moving about the desktop.

When I switch to the prop nvidia drivers this problem disappears, mouse movement is super smooth. I have also done some IRQ troubleshooting and it not that. Only happens with nouveau driver on this laptop (Dell XPS L701). I am not running 12.04 on any other PC's so I cannot say if this is device specific.

I don't particularly want to use the prop drivers as I nvidia's multi monitor support is shocking and the new ubuntu support is WAY better. I constantly switch monitors so using nvidia is just not feasible.

Thanks

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: xserver-xorg-video-nouveau 1:0.0.16+git20111201+b5534a1-1build2
ProcVersionSignature: Ubuntu 3.2.0-12.21-generic 3.2.2
Uname: Linux 3.2.0-12-generic x86_64
.tmp.unity.scope.cities: Error: [Errno 21] Is a directory: '/tmp/unity-scope-cities'
.tmp.unity.support.test.0:

ApportVersion: 1.91-0ubuntu1
Architecture: amd64
CompizPlugins: [core,bailer,detection,composite,opengl,decor,mousepoll,vpswitch,regex,animation,snap,expo,move,compiztoolbox,place,grid,imgpng,gnomecompat,wall,ezoom,workarounds,resize,fade,unitymtgrabhandles,scale,session,unityshell]
CompositorRunning: compiz
Date: Sat Feb 4 17:15:36 2012
DistUpgraded: Log time: 2011-12-21 10:30:51.848974
DistroCodename: precise
DistroVariant: ubuntu
EcryptfsInUse: Yes
ExtraDebuggingInterest: Yes, whatever it takes to get this fixed in Ubuntu
GraphicsCard:
 NVIDIA Corporation GF106 [GeForce GT 445M] [10de:0dd2] (rev a1) (prog-if 00 [VGA controller])
   Subsystem: Dell Device [1028:046c]
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20111129.1)
MachineType: Dell Inc. XPS L701X
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-12-generic root=UUID=4d02337e-4d2f-46d2-8ff7-6bfd4cd1fb0a ro quiet splash vt.handoff=7
SourcePackage: xserver-xorg-video-nouveau
UpgradeStatus: Upgraded to precise on 2011-12-21 (45 days ago)
dmi.bios.date: 11/29/2010
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A06
dmi.board.vendor: Dell Inc.
dmi.board.version: A06
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: A06
dmi.modalias: dmi:bvnDellInc.:bvrA06:bd11/29/2010:svnDellInc.:pnXPSL701X:pvrA06:rvnDellInc.:rn:rvrA06:cvnDellInc.:ct8:cvrA06:
dmi.product.name: XPS L701X
dmi.product.version: A06
dmi.sys.vendor: Dell Inc.
version.compiz: compiz 1:0.9.6+bzr20110929-0ubuntu8
version.ia32-libs: ia32-libs 20090808ubuntu33
version.libdrm2: libdrm2 2.4.30-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 7.11-0ubuntu4
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 7.11-0ubuntu4
version.xserver-xorg-core: xserver-xorg-core 2:1.11.3-0ubuntu10
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.6.99.901-1ubuntu3
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.14.99~git20111219.aacbd629-0ubuntu2
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.17.0-1ubuntu3
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20111201+b5534a1-1build2

[psypher (psypher246)]

I have just tested this issue and made a recording. It's very interesting. I started a stopwatch and just made small circular mouse movements. I noted that almost every 10 seconds (around the 8 second mark) the mouse will get stuck, as I described, but the stopwatch clock ALSO gets stuck. Then I played the recording back and could clearly see the stopping clock. But during the recording I was not moving my mouse and only the recording would show the freeze. Then I tried moving my mouse at the same the recording is playing. I was clearly able to see that every 10 seconds (around the 3 second mark) the recording would freeze, and then again at 8 seconds the actual recording will freeze as well. But that was expected as that was whatI was recording.

So in conclusion it seems that if you are moving your mouse about almost every 10 seconds the entire screen freezes for a microsecond, this is easily repeatable as described above. Also tried it while playing a youtube video. Play video, not moving mouse, all fine, move mouse around and every 10 seconds video lags.

 Although it doesn't seem like the trigger of the timer is the start of the mouse moving. I could be typing something and want to move the mouse and immediately it gets stuck. It's as if there is a background process thats constantly running and at regular intervals causes if freeze only if the mouse happens to move at that time.

[Michael Stein (der-stein)]

I can report the same behaviour on my samsung p560.
Graphic: NVIDIA GeForce 9600M GS
The mouse jerks every 8 seconds.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Ryan G (rtgkid)]

VERY annoying. Could someone please email Canonical letting them know about this bug?

[psypher (psypher246)]

Ryan, logging a bug is the best you can do. Then the process is being followed. please click "this bug affects you" at the top and subscribe to follow on progress. that gains attention. I will keep at it as I detest the nvidia screen manager app. Ubuntu's work on multi-monitors is going well but it only seems to work when I am running nouveau driver. Nvidia's sucks, ubuntu's dynamic

Thanks

[psypher (psypher246)]

This is not just an ubuntu issue:

http://forums.opensuse.org/english/get-technical-help-here/applications/455885-opensuse-11-4-freezes-every-10-seconds-so.html
http://lists.opensuse.org/opensuse-bugs/2011-03/msg03309.html
https://bbs.archlinux.org/viewtopic.php?id=134946

Guys there complain about the exact same issue but they have EDID errors in their logs popping up at the same time as the freeze. I don't see those logs. Does that log somewhere else other than syslog?

Please could this be urgently logged upstream. Nouveau bug logging procedure says the distro must log the bug.

I am happy to supply any info and do tests.

THANKS!

[psypher (psypher246)]

HI could this bug please be logged upstream asap to get some attention to it. Makes for a very annoying desktop experience

[Timo Aaltonen (tjaalton)]

This is actually fixed in kernel 3.3-rc1. The commit diff to 3.2 is 115 commits, anyone willing to bisect the diff?

[Joel Wright (joel-wright-k)]

I would question the above comment about it being fixed in kernel 3.3 - I tried upgrading to mainline 3.3.1 and was still seeing the same behaviour. The pauses were smaller, but still in evidence.

It's a shame, but it looks like I'll have to keep using the nvidia binary driver for a bit longer :(

[psypher (psypher246)]

HI Martin,

I have just updated and this bug is not fixed

[Jonas (joney)]

me and a colleague also can confirm this problem on Lenovo T410. I found another bug report with a similar symptom

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/746084
and also a link to a workaround:
http://souriguha.wordpress.com/2011/03/08/how-to-solve-problem-with-thinkpadkslowd-kworker-on-linux-kernel-2-35-2-36/

This seems to fix it for me. Maybe others can try that? The fix is

#echo N> /sys/module/drm_kms_helper/parameters/poll

[Colin Svingen (swoogan)]

I can confirm that jones' solution has fixed the problem on my Lenovo W510. I have had this problem since (at least) 11.04, but it appeared to be slightly improved in 11.10 or 12.04 (freezing for a shorter duration).

Additionally, as this may not be obvious to all users, I had to run the command with sudo. However, just running

# sudo echo N > /sys/module/drm_kms_helper/parameters/poll

did not work. I had to run

# sudo -i

then

# echo N > /sys/module/drm_kms_helper/parameters/poll

Thanks jones! This issue has been bugging me for a year or more.

[Joel Wright (joel-wright-k)]

Just thought I'd pitch in as well and say that disabling drm kms polling also solves the problem on my Dell E6510.

Finally I can go all open-source :)

[psypher (psypher246)]

I can confirm that this indeed does fix the issue.
Is adding it to my rc.local as so correct:

echo N > /sys/module/drm_kms_helper/parameters/poll
exit 0

Else I see the setting is not saved upon reboot

[stepankk (stepankk)]

I confirm the issue exists on Lenovo W520, Nvidia Quadro 2000M, Ubuntu 12.04, nouveau video driver.

[Lubomir Lackovic (luboss18)]

I am also affected by this bug, but I have radeon graphics on my desktop (Kubuntu 12.04, Intel i750, Radeon 4890). I had the same problem in Kubuntu 11.10 and also in Ubuntu 11.10 - it was one of the reasons why I used Catalyst before (it was not affected). Later I started using opensource radeon driver and learned to live with this bug.

I have also found that people with intel graphics have the same problem:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/653815

I can also confirm that workaround posted by jones works.

Some basic system info:

root@luboss-desktop:/# uname -a
Linux luboss-desktop 3.5.0-13-generic #13-Ubuntu SMP Tue Aug 28 08:31:47 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
root@luboss-desktop:/# lshw -c video
  *-display
       description: VGA compatible controller
       product: RV790 [Radeon HD 4890]
       vendor: Hynix Semiconductor (Hyundai Electronics)
       physical id: 0
       bus info: pci@0000:01:00.0
       version: 00
       width: 64 bits
       clock: 33MHz
       capabilities: pm pciexpress msi vga_controller bus_master cap_list rom
       configuration: driver=radeon latency=0
       resources: irq:46 memory:e0000000-efffffff memory:fbee0000-fbeeffff ioport:ee00(size=256) memory:fbe00000-fbe1ffff
root@luboss-desktop:/#

If needed I am happy to provide more info...

[Roger R. Cruz (roger-r-cruz)]

The work-around of disabling polling works for me. I have confirmed that on the M4600, the polling of its 5 ports take up to 484 milliseconds during which the system is "frozen". I haven't investigated why but I'm confident that they way nouveau is detecting the DDC and EDID information is causing these brief lockups.

Gents,

I have instrumented the nouveau driver to get exact timing and the problem is definitely the EDID probe for the HDMI port taking 250 milliseconds and DDC detection taking 160 milliseconds for each port!

HDMI port connected

Nov 7 20:00:21 Precision-M4600-JRYQKQ1 kernel: [ 231.106058] Got to nouveau_connector_detect
Nov 7 20:00:21 Precision-M4600-JRYQKQ1 kernel: [ 231.106059] [drm] nouveau 0000:01:00.0: nouveau_connector_detect:238 -
Nov 7 20:00:21 Precision-M4600-JRYQKQ1 kernel: [ 231.106061] [drm] nouveau 0000:01:00.0: nouveau_connector_detect:247 - Detecting DDC
Nov 7 20:00:21 Precision-M4600-JRYQKQ1 kernel: [ 231.138669] [drm] nouveau 0000:01:00.0: nouveau_connector_detect:249 - DDC detected
Nov 7 20:00:21 Precision-M4600-JRYQKQ1 kernel: [ 231.138670] [drm] nouveau 0000:01:00.0: nouveau_connector_detect:251 - Getting EDID information
Nov 7 20:00:21 Precision-M4600-JRYQKQ1 kernel: [ 231.352525] [drm] nouveau 0000:01:00.0: nouveau_connector_detect:253 - EDID information obtained
Nov 7 20:00:21 Precision-M4600-JRYQKQ1 kernel: [ 231.352529] [drm:output_poll_execute], [CONNECTOR:17:DP-3] status updated from 1 to 1

HDMI port disconnected

Nov 7 20:04:07 Precision-M4600-JRYQKQ1 kernel: [ 457.286060] [drm:output_poll_execute], [CONNECTOR:17:DP-3] Probing...
Nov 7 20:04:07 Precision-M4600-JRYQKQ1 kernel: [ 457.286061] Got to nouveau_connector_detect
Nov 7 20:04:07 Precision-M4600-JRYQKQ1 kernel: [ 457.286062] [drm] nouveau 0000:01:00.0: nouveau_connector_detect:238 -
Nov 7 20:04:07 Precision-M4600-JRYQKQ1 kernel: [ 457.286064] [drm] nouveau 0000:01:00.0: nouveau_connector_detect:247 - Detecting DDC
Nov 7 20:04:07 Precision-M4600-JRYQKQ1 kernel: [ 457.446021] [drm] nouveau 0000:01:00.0: nouveau_connector_detect:249 - DDC not detected!
Nov 7 20:04:07 Precision-M4600-JRYQKQ1 kernel: [ 457.446024] [drm:output_poll_execute], [CONNECTOR:17:DP-3] status updated from 2 to 2

No ports connected. Notice the DDC detection takes 160 millisecs to time out for each DP port. total detection time 484 milliseconds

Nov 7 20:07:16 Precision-M4600-JRYQKQ1 kernel: [ 645.966016] [drm:output_poll_execute], [CONNECTOR:9:DP-1] Probing...
Nov 7 20:07:16 Precision-M4600-JRYQKQ1 kernel: [ 645.966027] Got to nouveau_connector_detect
Nov 7 20:07:16 Precision-M4600-JRYQKQ1 kernel: [ 645.966033] [drm] nouveau 0000:01:00.0: nouveau_connector_detect:238 -
Nov 7 20:07:16 Precision-M4600-JRYQKQ1 kernel: [ 645.966039] [drm] nouveau 0000:01:00.0: nouveau_connector_detect:247 - Detecting DDC
Nov 7 20:07:16 Precision-M4600-JRYQKQ1 kernel: [ 646.126051] [drm] nouveau 0000:01:00.0: nouveau_connector_detect:249 - DDC not detected! <==== .16
Nov 7 20:07:16 Precision-M4600-JRYQKQ1 kernel: [ 646.126053] [drm:output_poll_execute], [CONNECTOR:9:DP-1] status updated from 2 to 2
Nov 7 20:07:16 Precision-M4600-JRYQKQ1 kernel:...

[e64462 (nhdaimyo)]

The suggested fix does not work for me. As you can see, the file

/sys/module/drm_kms_helper/parameters/poll

contains the correct value:

root@desktop:~# cat /sys/module/drm_kms_helper/parameters/poll
N

Also, I've had: "tail -f /var/log/Xorg.0.log" running in the background while I attempt to resolve this issue, and I've noticed that the lag happens exactly when Xorg.0.log is flooded with the following messages:

[ 2256.623] (II) NOUVEAU(0): EDID vendor "SAM", prod id 1315
[ 2256.623] (II) NOUVEAU(0): Using hsync ranges from config file
[ 2256.623] (II) NOUVEAU(0): Using vrefresh ranges from config file
[ 2256.623] (II) NOUVEAU(0): Printing DDC gathered Modelines:
[ 2256.623] (II) NOUVEAU(0): Modeline "1920x1080"x0.0 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync (67.5 kHz)
[ 2256.623] (II) NOUVEAU(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz)
[ 2256.623] (II) NOUVEAU(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz)
[ 2256.623] (II) NOUVEAU(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz)
[ 2256.623] (II) NOUVEAU(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz)
[ 2256.623] (II) NOUVEAU(0): Modeline "1280x800"x0.0 83.50 1280 1352 1480 1680 800 803 809 831 -hsync +vsync (49.7 kHz)
[ 2256.623] (II) NOUVEAU(0): Modeline "1280x960"x0.0 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz)
[ 2256.623] (II) NOUVEAU(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz)
[ 2256.623] (II) NOUVEAU(0): Modeline "1440x900"x0.0 106.50 1440 1520 1672 1904 900 903 909 934 -hsync +vsync (55.9 kHz)
[ 2256.623] (II) NOUVEAU(0): Modeline "1600x1200"x0.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz)
[ 2256.623] (II) NOUVEAU(0): Modeline "1680x1050"x0.0 146.25 1680 1784 1960 2240 1050 1053 1059 1089 -hsync +vsync (65.3 kHz)

The two happen at the same time, every time.