xorg is jerky, uses too much cpu, small display bugs

Bug #653851 reported by Aroll605 on 2010-10-02
28
This bug affects 4 people
Affects Status Importance Assigned to Milestone
NVIDIA Drivers Ubuntu
Undecided
Unassigned
nvidia-graphics-drivers (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: xorg

1. General CPU usage is higher than before (more than on Ubuntu 10.04)
2. Some windows take a bit more time to appear than usual.
3. Menus (left-click too) appear slower too and are jerky when opening sub-menus and mouse moving.
4. Windows and menus take too much time to be "deleted" and new ones appear slightly before the "deletion" of the older menu (ex: when moving the mouse from one menu option to an adjacent one the previous menu disappears slightly after the new one appears).

It is possible that it could be compiz's fault. Xorg CPU usage is somewhat lower and generally smoother when not using compiz window decorator.

Description: Ubuntu maverick (development branch)
Release: 10.10

It's the release candidate 1.

Linux lev-laptop 2.6.35-22-generic #33-Ubuntu SMP Sun Sep 19 20:32:27 UTC 2010 x86_64 GNU/Linux

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: xorg 1:7.5+6ubuntu3
ProcVersionSignature: Ubuntu 2.6.35-22.33-generic 2.6.35.4
Uname: Linux 2.6.35-22-generic x86_64
NonfreeKernelModules: nvidia
.proc.driver.nvidia.version:
 NVRM version: NVIDIA UNIX x86_64 Kernel Module 256.53 Fri Aug 27 20:27:48 PDT 2010
 GCC version: gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)
Architecture: amd64
Date: Sat Oct 2 19:35:27 2010
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
MachineType: TOSHIBA Satellite A660
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.35-22-generic root=UUID=1f3c0146-bd33-4634-89bf-a3fda3efa589 ro quiet splash
ProcEnviron:
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: xorg
Symptom: display
dmi.bios.date: 07/02/10
dmi.bios.vendor: TOSHIBA
dmi.bios.version: 1.50
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: NWQAA
dmi.board.vendor: TOSHIBA
dmi.board.version: 1.00
dmi.chassis.asset.tag: *
dmi.chassis.type: 9
dmi.chassis.vendor: TOSHIBA
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnTOSHIBA:bvr1.50:bd07/02/10:svnTOSHIBA:pnSatelliteA660:pvrPSAW3C-045017:rvnTOSHIBA:rnNWQAA:rvr1.00:cvnTOSHIBA:ct9:cvrN/A:
dmi.product.name: Satellite A660
dmi.product.version: PSAW3C-045017
dmi.sys.vendor: TOSHIBA
glxinfo: Error: [Errno 2] No such file or directory
system:
 distro: Ubuntu
 codename: maverick
 architecture: x86_64
 kernel: 2.6.35-22-generic

Aroll605 (aroll605) wrote :
Aroll605 (aroll605) wrote :

Forgot to mention, also scrolling is jerky, especially in system applications like gnome-system-monitor or anywhere else.

Aroll605 (aroll605) wrote :

And gedit, nautilus as well. Scrolling is jerky but gets better after a few complete scroll ups and downs.

Timo Aaltonen (tjaalton) on 2010-10-03
affects: xorg (Ubuntu) → nvidia-graphics-drivers (Ubuntu)
satwien (satwien) wrote :

I'm in exactly the same situation, same effects.
Same kernel, same architecture (amd64) same distro, same nVidia driver ...
I will subscribe to this bug, also.

Same it's very slower than lucid.

To view the différences, just activate the screenlet "Output", CPU usage will be 25% (Process Xorg)

Ali Onur Uyar (aouyar) wrote :

The problem does not occur only with Nvidia chipsets but also with Intel Video (Intel GM45). The GUI is sooo slow it is unbearable. Here is one way to replicate the problem:
1. Click on Gnome Main Menu.
2. Start moving the pointer up and down over the menu entries.
3. In a few seconds Xorg will be consuming 50% of the CPU and gnome-panel the remaining 50%.

The problem is not limited to gnome-panel. It seems like any application that is updating the screen consumes processing time and at the same time causes the Xorg processing time to shoot up. No complex graphical operations are required for triggering the problem; opening a GTK menu in any application (thunderbird, gedit) and scrolling over the menu items causes excessive CPU utilization. The most notorious example was opening a gedit instance and scrolling through the File Menu causing gedit to consume 60% and Xorg consume 40% CPU. It is is also important to note that scrolling thorugh the Menu items is very slow.

The most annoying aspect of the general sluggishness in the interface is delays in text input. The characters that one is typing stop from appearing in the screen and one or two seconds later many characters appear at once,

The problem doesn't seem to be limited to Compiz or 3D effects either, because the sluggishness in scroling through the menus can even be observed after switching from Compiz to Metacity using the Compiz Fusion Applet.

Ali Onur Uyar (aouyar) wrote :

I have detected just the same symptoms on a 32-bit Maverick Install with Intel Video (Intel GM45). The problem does not seem to be specific to Nvidia drivers. I've done testing with 2.6.35-22-generic, 2.6.35-23-generic and I've also tried 2.6.36 from Kernel PPA and the results are basically the same.

affects: nvidia-graphics-drivers (Ubuntu) → xserver-xorg-video-intel (Ubuntu)
affects: xserver-xorg-video-intel (Ubuntu) → nvidia-graphics-drivers (Ubuntu)
Darik Horn (dajhorn) wrote :

This problem resolved for me on several computers when I installed the stable xorg stack from the x-updates ppa:

  https://launchpad.net/~ubuntu-x-swat/+archive/x-updates

Ali Onur Uyar (aouyar) wrote :

In my case it seems like the problem is high interrupt load due to ACPI. I still do not understand what exactly ACPI has to do with Xorg CPU Utilization, it is even stranger that an ACPI problem could cause high CPU utilization for user applications like gedit or thunderbird, but the fact is that once I added acpi=off to Kernel Boot, the Xorg, gnome-panel, gedit, thunderbird CPU utilization were scaled to more reasonable levels and the GUI become much more responsive.

Turning of ACPI disables many important functions like checking the battery charge level and screen brightness so I ended up following the Ubuntu ACPI Debugging Document (https://wiki.ubuntu.com/DebuggingACPI) trying to pinpoint the problem. In the end I was not able to pinpoint the problem, but I discovered that in my case the pnpacpi=off boot option instead of the acpi=off option provided a reasonable solution. With the pnpacpi=off option critical functions like battery charge level monitoring and screen brightness contol works without causing unresponsive GUI.

I am not sure to which package file, what seems to be an ACPI bug. When the pnpacpi=off or acpi=off option is not used, one can observe a very high number of interrupts produced by ACPI in /proc/interrupts crippling GUI responsiveness. I did some testing with Lucid and Maverick Live CDs to determine that the problem occurs in clean Lucid and Maverick installs on Lenovo Ideapad U150, but the impact is more noticable in Lucid.

To post a comment you must log in.