upgrade to 2:1.2.99.2-0ubuntu1 makes session utterly slow

Bug #307306 reported by Martin Pitt
190
This bug affects 20 people
Affects Status Importance Assigned to Milestone
X.Org X server
Fix Released
High
gnome-desktop
Fix Released
High
gnome-power
Fix Released
Critical
libgnome
Invalid
Undecided
Unassigned
vino
Invalid
Undecided
Unassigned
gnome-desktop (Ubuntu)
Fix Released
High
Alberto Milone
Nominated for Jaunty by ICrash n BurnI
gnome-power-manager (Ubuntu)
Fix Released
High
Alberto Milone
Nominated for Jaunty by ICrash n BurnI
libxrandr (Ubuntu)
Invalid
High
Unassigned
Nominated for Jaunty by ICrash n BurnI

Bug Description

I upgraded Jaunty this morning, and after a reboot, my system was utterly slow and sluggish as soon as I started the GNOME session. boot and gdm worked fine, and a failsafe X-Terminal only session works fine as well.

I bisected this to the upgrade of libxrandr2 from 2:1.2.3-1 to 2:1.2.99.2-0ubuntu1.

This is a Dell Latitude D430

$ xrandr
Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1280 x 1280
VGA disconnected (normal left inverted right x axis y axis)
LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis) 261mm x 163mm
   1280x800 59.8*+
   1024x768 60.0
   800x600 60.3
   640x480 59.9
TMDS-1 disconnected (normal left inverted right x axis y axis)
TV disconnected (normal left inverted right x axis y axis)

$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)

Tags: oem-services
Revision history for this message
In , William Grant (wgrant) wrote :

Running Ubuntu jaunty on an i915 laptop, I've recently upgraded to libxrandr2 1.2.99.2. Upon login in the the first new X session after that, my screen started flickering constantly. Analysis of the xserver log showed that it was requesting the EDID lots of times. libxrandr 1.2.3 didn't show that problem, and downgrading to it returns sanity.

Revision history for this message
In , Timo Aaltonen (tjaalton) wrote :

*** Bug 19047 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Timo Aaltonen (tjaalton) wrote :

my 965 isn't affected, but apparently 945 is:

https://bugs.launchpad.net/ubuntu/+source/libxrandr/+bug/307306

Changed in xorg-server:
status: Unknown → Confirmed
Timo Aaltonen (tjaalton)
Changed in libxrandr:
importance: Undecided → High
status: New → Confirmed
Revision history for this message
In , Colin Watson (cjwatson) wrote :

My i965 (PCI ID 8086:2a02/8086:2a03) is affected. Downgrading libxrandr to 1.2.3 is awkward (I'm running Ubuntu Jaunty and a bunch of other stuff depends on it, which I don't really want to downgrade), but I looked through the changes between 1.2.3 and 1.2.99.2 and made a guess: forcing XRRGetCrtcTransform to think it's talking to a pre-1.3 server seems to be helping so far.

In my case, it was a little bit sluggish to start with although not hugely, but the EDID request storm really took off after unplugging my laptop from power and Ethernet and taking it away from my desk.

Revision history for this message
In , Bryce Harrington (bryce) wrote :

Ubuntu is currently using the 1.5.99.3 server, however there are a number of randr fixes in the git tree for the 1.6 branch subsequent to this version:

commit a82f10c5dd9fa74ff18759ab288bbd9c8b7ac4de
    randr: clear primaryOutput when the output is deleted

commit 2bc53ce66828b6c177e3298fa2f326c77c93e136
    randr: use primary output for RRFirstOutput()

commit f0234a9eb88ed103bca7db73a833c472ab95b48f
    randr: Mangle GetScreenResources sort order based on primary output

commit 2ef02833d614c42693e019a444560e84f501b5dc
    randr: Mangle compat Xinerama reply based on primary output

commit 0bdfdaa7df8105c7ffc3248a4fdd5f64da67103c
    randr: Add [GS]etOutputPrimary

Looking at the diffs, none jump out at me as obvious fixes for this problem, but especially the first two sound to me like potentially relevant.

Bryce Harrington (bryce)
Changed in libxrandr:
status: Confirmed → Triaged
Revision history for this message
Bryce Harrington (bryce) wrote :

Hi Colin,

You mentioned on the upstream bug that you were able to work around the problem by forcing the XRRGetCrtcTransform to believe it was talking to a pre-1.3 server. Does something like the attached patch work as well?

If so, perhaps we should consider disabling this functionality until a fix is available, since already several people have seen this problem.

Revision history for this message
Bryce Harrington (bryce) wrote :

Regarding the real fix -- in browsing through the xserver git tree, there's a handful of 1.3-related changes in the randr code which post-date the version of xserver currently in jaunty. Browsing through the changes, none jumped out at me as obvious causes for this problem, but perhaps a newer xserver would have whatever bits that libxrandr is now expecting.

I had keith over this last Sunday and he said he was going to put out the 1.6 final probably within the next week or two, so perhaps we should plan to upgrade to that version ASAP once it's out, and re-test this bug. Meanwhile, if disabling use of the Transformations stuff with the above patch solves the issue, we could just use that for the time being.

Revision history for this message
In , Martin Pitt (pitti) wrote :

I confirm the behaviour that Colin describes on my GM945: As long as I have the laptop docked (no battery) or undocked with power, it works reasonably, and I "only" get some 30 EDID detects in Xorg.0.log. But as soon as I unplug the power (I guess it's any change to power source which triggers this), the flood starts and the desktop becomes mostly unusable.

I tested Bryce's proposed workaround (http://launchpadlibrarian.net/20825929/disable_transform.patch) and it didn't work. No noticeable change.

Revision history for this message
Martin Pitt (pitti) wrote :

disable_transform.patch did not work for me, no noticeable change in behaviour.

Revision history for this message
David Vonka (vonkad) wrote :

It'd be great if there were a temporary fix. I got a completely unusable laptop here ... (my fault installing alpha, I know ...)

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

There's a new version in debian experimental, try building it (you need the new x11proto-randr from experimental to build). Sync requests have been filed too (bugs 314032 and 314198), so hopefully they'll find their way to jaunty soon.

Revision history for this message
Martin Pitt (pitti) wrote :

I built and installed it, it does not fix this bug.

Revision history for this message
David Vonka (vonkad) wrote : Re: [Bug 307306] Re: upgrade to 2:1.2.99.2-0ubuntu1 makes session utterly slow

I've switched to icewm for the moment, but I still do look forward to a fix
of the bug.

2009/1/6 Martin Pitt <email address hidden>

> I built and installed it, it does not fix this bug.
>
> --
> upgrade to 2:1.2.99.2-0ubuntu1 makes session utterly slow
> https://bugs.launchpad.net/bugs/307306
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Gavin McCullagh (gmccullagh) wrote :

I noticed this issue again.

This time I managed to get a logfile

I'm attaching it

Revision history for this message
Colin Watson (cjwatson) wrote :

I think I must have been mistaken, sorry; I can still reproduce that after my XrrGetCrtcTransform hack, so that was probably a red herring.

libxrandr 2:1.2.99.4-1 makes no obvious difference either.

One thing I do notice is that switching VTs seems to deconfuse X and get the system back to a usable state. I don't know if this is temporary or permanent (i.e. if it's going to require VT switches every so often throughout a session) yet, though.

Revision history for this message
Gavin McCullagh (gmccullagh) wrote :

Another logfile from this issue. This error seems to repeat over and over:

(EE) intel(0): Mode 1280x1024 does not fit virtual size 1024x1024 - internal error
(II) intel(0): I2C bus "CRTDDC_A" initialized.
(II) intel(0): I2C bus "CRTDDC_A" removed.
(II) intel(0): EDID vendor "SEC", prod id 19032
(II) intel(0): Printing DDC gathered Modelines:
(II) intel(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz)
(II) intel(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz)
(II) intel(0): EDID vendor "SEC", prod id 19032
(EE) intel(0): Mode 1280x1024 does not fit virtual size 1024x1024 - internal error
(II) intel(0): I2C bus "CRTDDC_A" initialized.
(II) intel(0): I2C bus "CRTDDC_A" removed.
(II) intel(0): EDID vendor "SEC", prod id 19032
(II) intel(0): Printing DDC gathered Modelines:
(II) intel(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz)
(II) intel(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz)
(II) intel(0): EDID vendor "SEC", prod id 19032

Revision history for this message
Peter Clifton (pcjc2) wrote :

As an off the wall suggestion, try killing gnome-settings-daemon, then swithing to console for a while, then back to graphics. Your symptoms, and the relation to Xrandr sound like they could be related to a problem I diagnosed earlier where g-s-d would get into a big loop continually firing Xrandr events at the X server, causing it to keep re-probing its outputs.

Revision history for this message
Alberto Milone (albertomilone) wrote :

The problem affects applications which listen to RandR events. In Gnome both gnome-desktop (hence gnome-settings-daemon) and gnome-power-manager do it.

I have written 2 patches which make the Gnome desktop usable again by preventing both apps from listening to RandR events. This, of course, doesn't solve the real problem.

If no fix is for libxrandr is found in time for Jaunty's release we may want to include my patch as a cheap workaround.

Revision history for this message
Alberto Milone (albertomilone) wrote :
Revision history for this message
Alberto Milone (albertomilone) wrote :
Revision history for this message
Alberto Milone (albertomilone) wrote :

oh, and the horrible /* */ for each line was caused by an IDE I used. I can change this if we decide to include the patches.

Revision history for this message
In , Peter Clifton (pcjc2) wrote :

Tracked this down with some of the ubuntu-x team..

The code in question is gnome-desktop / gnome-settings-daemon / gnome-power-manager / gdk.

g-p-m is sending a load of brightness change requests to produce a dimming effect when it chanes the backlight brighness.

For each change, we get an output property notification which is picked up by several listening clients.

gnome-settings-daemon listens to the Xrandr notifications directly, and reprobes information on recieving each backlight change notification.

gnome-power-manager's code-paths to listen directly to the Xrandr notifications seem to be disabled (if (FALSE)), however code _is_ called to attach to GDK's "monitors-changed" signal. When that is triggered, g-p-m probes Xrandr for events.

GDK is emitting a "monitors-changed" event for every Xrandr event encountered. As an _untested_ theory.. I'm wondering if the bug relating to the "window" property on some Xrandr notifications - (fixed in the noted libxrandr update), might have previously been causing GDK to drop some of those events?

Alberto Milone has worked up patches to g-s-d and g-p-m following my discovery that Xrandr 1.3 now supports an API to query for the "Current" data, rather than triggering a re-probe of the hardware.

I'm also a little suspicious that GDK's "monitors-changed" event is triggering rather more often than it needs to be, given the description of that event.) Alberto wonders if any TV-out output property changes are relevant to that though. My local fix to workaround the problem patches GDK to ignore Xrandr notifications for changes to output properties.

Changed in gnome-desktop:
importance: Undecided → Unknown
status: New → Unknown
Changed in gnome-desktop:
status: Unknown → New
Changed in gnome-power:
status: Unknown → New
Revision history for this message
Alberto Milone (albertomilone) wrote :

As Peter Clifton pointed out, there's a new and less expensive call in the RandR 1.3 API (XRRGetScreenResourcesCurrent), credits to him for telling me about it. This function doesn't make RandR reprobe hardware and it's definitely the right function to use when listening for events (at least in this case).

As I found out that gnome-desktop wasn't the only one which was causing high CPU usage, I have filed separate bug reports against gnome-desktop and gnome-power-manager and provided upstream with patches which fix the problem. Now, if RandR 1.3 is availble, XRRGetScreenResourcesCurrent is used instead of XRRGetScreenResources and the problem is gone.

I think we can unsubscribe the both the Xserver and libxrandr since they seem to do the right thing.

Changed in libxrandr:
status: Triaged → Invalid
Changed in gnome-desktop:
assignee: nobody → albertomilone
importance: Undecided → High
status: New → In Progress
Changed in gnome-power-manager:
assignee: nobody → albertomilone
importance: Undecided → High
status: New → In Progress
Changed in gnome-desktop:
status: New → Fix Released
Changed in gnome-power:
status: New → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-desktop - 1:2.25.5-0ubuntu1

---------------
gnome-desktop (1:2.25.5-0ubuntu1) jaunty; urgency=low

  * New upstream version:
    libgnome-desktop
    - GnomeBG: use gdk_color_equal() instead of custom function
    - GnomeRR: use XRRGetScreenResourcesCurrent instead of
      XRRGetScreenResources when available (xrandr 1.3) because it's cheaper
      (lp: #307306)
    - GnomeBG: emit "transitioned" signal instead of "changed" signal for
      new frames in a slideshow background
    - GnomeBG: reorganize code a bit
    - GnomeBG: add fading API to support fading between two backgrounds

gnome-desktop (1:2.25.3-0ubuntu2) jaunty; urgency=low

  * debian/patches/100_load_desired_settings.patch:
    - libgnome-desktop/gnome-rr-config.c:
      + clean up the patch to reuse code from the current API
      + don't segfault with old configuration files (LP: #314406)
      + remove notification on login when the configuration file
        is absent or invalid
      + don't let configurations_read_from_file() try to read xml
        files which don't exist

 -- Sebastien Bacher <email address hidden> Tue, 20 Jan 2009 10:50:09 +0100

Changed in gnome-desktop:
status: In Progress → Fix Released
Revision history for this message
Peter Clifton (pcjc2) wrote :

I've added comments on the upstream bugs to point out that the fix isn't quite correct.

Testing the Xrandr client library for version at compile time is necessary, but you also need to test the reported Xrandr protocol version from the server, since in the general case, the two might not match.

Revision history for this message
Alberto Milone (albertomilone) wrote :

It would be a problem only if one downgraded libxrandr to a previous version. Usually distributions don't update libxrandr or the Xserver in stable releases. This means that g-d and g-p-m will have to be rebuilt (in this case) in order to be used with previous versions of libxrandr. In any case future upgrades won't be a problem.

Revision history for this message
Peter Clifton (pcjc2) wrote :

Also, unfortunately the problem isn't fixed by the cheaper call to XRRGetScreenResourcesCurrent

Other Xrandr calls are expensive, such as the "XRRGetScreenSizeRange" one made in gnome-desktop's gnome-rr.c

This Xserver backtrace shows the issue:

#0 0xb809e430 in __kernel_vsyscall ()
#1 0xb7ce7700 in __nanosleep_nocancel () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7d24ffc in usleep () from /lib/tls/i686/cmov/libc.so.6
#3 0xb7ab826e in i830WaitForVblank (pScreen=0xa197040) at ../../src/i830_display.c:379
#4 0xb7abaf80 in i830_crtc_mode_set (crtc=0xa199b80, mode=0xbfdb9ea0, adjusted_mode=0xa4d70e8, x=0, y=0) at ../../src/i830_display.c:1511
#5 0x080ed08d in xf86CrtcSetModeTransform (crtc=0xa199b80, mode=0xbfdb9ea0, rotation=1, transform=0x0, x=0, y=0)
    at ../../../../hw/xfree86/modes/xf86Crtc.c:366
#6 0x080ed6d6 in xf86CrtcSetMode (crtc=0xa199b80, mode=0xbfdb9ea0, rotation=8180, x=0, y=0) at ../../../../hw/xfree86/modes/xf86Crtc.c:413
#7 0xb7ab956d in i830GetLoadDetectPipe (output=0xa19b618, mode=0xbfdb9ea0, dpms_mode=0xbfdb9f78) at ../../src/i830_display.c:1811
#8 0xb7ad746d in i830_tv_detect (output=0xa19b618) at ../../src/i830_tv.c:1376
#9 0x080eda90 in xf86ProbeOutputModes (scrn=0xa197040, maxX=4096, maxY=4096) at ../../../../hw/xfree86/modes/xf86Crtc.c:1500
#10 0x080f56c0 in xf86RandR12GetInfo12 (pScreen=0xa19c460, rotations=0xbfdba16a) at ../../../../hw/xfree86/modes/xf86RandR12.c:1255
#11 0x08162e89 in RRGetInfo (pScreen=0xa19c460) at ../../randr/rrinfo.c:196
#12 0x08167084 in ProcRRGetScreenSizeRange (client=0xa3d2208) at ../../randr/rrscreen.c:227
#13 0x0815f305 in ProcRRDispatch (client=0x0) at ../../randr/randr.c:473
#14 0x0808cdbf in Dispatch () at ../../dix/dispatch.c:437
#15 0x08071aad in main (argc=10, argv=0xbfdba324, envp=Cannot access memory at address 0x8
) at ../../dix/main.c:383

Revision history for this message
Peter Clifton (pcjc2) wrote :

Checking the Xorg server code, the following procedures make the RRGetInfo call, which seems to lead to the expensive probe:

ProcRRGetScreenSizeRange
ProcRRGetScreenResources
ProcRRGetScreenInfo
ProcRRSetScreenConfig

Revision history for this message
Peter Clifton (pcjc2) wrote :

>It would be a problem only if one downgraded libxrandr to a previous version. Usually distributions don't update
>libxrandr or the Xserver in stable releases. This means that g-d and g-p-m will have to be rebuilt (in this case) in order >to be used with previous versions of libxrandr. In any case future upgrades won't be a problem.

As we discussed on IRC, this is fine for distros where the program is being used on the locally shipped X server, with a consistent support in the Xrandr client library and the local X server. (e.g. Fine in the context of a disto local patch).

For an upstream fix, they must consider the case where the X server might be remote, where it is much more likely that the client library and server extention don't match in feature-set.

Revision history for this message
Peter Clifton (pcjc2) wrote :

My local kludgy workaround for now is this:

-- gnome-desktop-2.25.5.orig/libgnome-desktop/gnome-rr.c
+++ gnome-desktop-2.25.5/libgnome-desktop/gnome-rr.c
@@ -512,6 +512,8 @@

        switch (event->subtype)
        {
+ case RRNotify_OutputProperty:
+ return GDK_FILTER_CONTINUE;
        default:
            break;
        }

Just changing the mask of events we're asking for doesn't seem to help - possibly because GDK already set the mask, and included the property change notifications.

Realistically, we should not be waking up so many clients for such changes, and Xrandr needs to grow some more selective ways to mask properties we might be interested in.

Also, a complete family of "Curretn" method call variants to be used in notification callbacks would be a useful thing to have in Xrandr 1.4.

Revision history for this message
Alberto Milone (albertomilone) wrote :

I'm curious to know more on how gnome-power-manager and gnome-settings-daemon are used remotely so as to better define the use-case in which this change would lead to a failure.

It's weird that I can't reproduce the problem any longer (even with XRRGetScreenSizeRange).

I have a few questions:
1) Does it solve the problem if you patch out the if-block with XRRGetScreenSizeRange in gnome-rr.c?
2) Did you apply the patch for gnome-power-manager yourself (as this update has not been included in Ubuntu yet)?

Revision history for this message
Peter Clifton (pcjc2) wrote :

These programs might be used remotely, or in a nested X session, or a VNC session, for example. I realise there are ways and means, but I suspect the stock VNC server from RealVNC won't support that extension (theory untested).

I have in the past (not currently) run servers hosting desktops, accessible via VNC. IE.. not the distro's stock X server.

In truth, the suggestion to fix this was more about "correctness" than whether it is likely the bug would be hit.

Revision history for this message
Peter Clifton (pcjc2) wrote :

gnome-power-manager isn't bothering me, since I still have the patched version of GDK which isn't emitting the "monitors-changed" event for output property notifications.

gdkevents-x11.c, line 2114:

     if (screen && notify->subtype != RRNotify_OutputProperty)
  _gdk_x11_screen_process_monitors_change (screen);

Just testing blocking our XRRGetScreenSizeRange now

Revision history for this message
Peter Clifton (pcjc2) wrote :

Blocking out XRRGetScreenSizeRange does indeed also fix the problem, however I noted that the call fills in information which may be accessed via various APIs, so I'd prefer to leave it in there if possible.

At least, disabling the update when recieving an output property notification just means that the performance problem is taken care without harming the update of information feeding those getters.

If we were being really fancy, we could actually inspect the notification for change of output property, and just ignore the brightness change ones. (If you're concerned that TV-out details might be relevant to re-query Xrandr).

Looking at this though, I don't think think the applications concerend actually care about output properties. GDK's "monitors-changed" emission, might arguably be interesting in the absence of a "output-property-changed" signal.

In the longer term, I think if GDK is going to attempt to wrap Xrandr, it needs to do a better mapping of these notifications, and / or proxying of information gleaned from the change notification events.

Revision history for this message
Peter Clifton (pcjc2) wrote :

This is most easily reproducible if you have a laptop, remove / insert the AC lead, and wait some seconds before gnome-power-manager notices, and starts to fade the backlight brightness between its AC and battery presets.

Killing gnome-settings-daemon fixes the issue (or patching it as above).

Since you're assigned to this, I'll not take the liberty of resetting the "Fix relesaed" status, but would suggest it might want to go back to "Confirmed"?

Changed in gnome-desktop:
status: Fix Released → In Progress
Revision history for this message
Alberto Milone (albertomilone) wrote :

I set the report to "in progress".

Your workaround shouldn't cause any problem to either the RandR applet or the g-s-d, therefore I think it would be ok to apply it.

We can ask upstream to adopt the patch and see how it goes. Do you want me to do this or do you prefer to do it yourself?

Revision history for this message
Peter Clifton (pcjc2) wrote :

Sure.. are those the only two consumers of gnome-rr.c's API?

If you're happy to push stuff upstream, please go ahead. I was hoping my mail to the xorg list ('CC yourself and KeithP) would yield some insight as to what they consider the best fix.

Revision history for this message
Alberto Milone (albertomilone) wrote :

Ok, thanks for your fix then. I'll discuss this with upstream

Revision history for this message
Alberto Milone (albertomilone) wrote :

I have provided upstream with Peter's patch (after testing it) and I've also written another patch so as to make sure that gnome-desktop checks the version of the library at runtime too:
http://bugzilla.gnome.org/show_bug.cgi?id=568537

Changed in libgnome:
importance: Unknown → Undecided
status: Unknown → New
status: New → Invalid
Revision history for this message
Max Bowsher (maxb) wrote :

I'm afraid that for me, the bug still exists even after rebuilding gnome-desktop with http://bugzilla.gnome.org/attachment.cgi?id=126905&action=view from http://bugzilla.gnome.org/show_bug.cgi?id=568160, and rebuilding gnome-power-manager with http://bugzilla.gnome.org/attachment.cgi?id=126753&action=view and http://bugzilla.gnome.org/attachment.cgi?id=126770&action=view from http://bugzilla.gnome.org/show_bug.cgi?id=568162.

It is noticable from the CPU graph that there is *some* improvement, but there is still clear inappropriate CPU-busyness from Xorg. Killing gnome-power-manager (but not gnome-settings-daemon) stops the CPU-busyness.

Revision history for this message
Carey Underwood (cwillu) wrote :

Just started happening to me a couple days after I upgraded to jaunty, didn't seem to be any updates that triggered it.

Consistently occurred for 3 reboots, going away when I switched to vesa, and coming back when switching back to intel, and then mysteriously disappeared again just as I was switching back into intel to try the gnome-settings-daemon workaround.

Revision history for this message
Alberto Milone (albertomilone) wrote :

Max: what driver are you using?

Carey: it depends on RandR events. Vesa doesn't support them.

Revision history for this message
Max Bowsher (maxb) wrote :

intel / dri i915 - I'll attach Xorg.0.log

Though, I've now noticed that about 2 and a half minutes after login, the rogue CPU usage stops. (In comparison to stopping immediately if I kill gnome-power-manager).

Revision history for this message
Jarkko Oranen (oranenj) wrote :

I noticed that running the gnome-display-properties application also triggers this; I was able to consistently trigger this bug by:

1) first having my external monitor unplugged
2) plugging it in; at this point, nothing happens.
3) start gnome-display-properties -> X.org goes insane and the display properties app stays unresponsive.

(it appears to work if gnome-power-manager is not running, but clicking "detect monitors" seems to trigger the bug regardless.)

Revision history for this message
Gediminas Paulauskas (menesis) wrote :

Xorg on my also used 100% of one of cores. But I was not able to solve this without recompiling packages.
 * Nothing changed if I killed gnome-power-manager or gnome-settings-daemon.
 * I downgraded libxrandr to intrepid version, and the related packages - no change.
 * Removed libgnome-desktop-11 in favor of libgnome-desktop-7 and downgraded many gnome packages to intrepid version, although they were working mostly fine for a couple of weeks.

Strangely enough, only after I downgraded gnome-session, the high cpu use by xorg has stopped.

Dell XPS 1330 using nvidia x drivers so intrepid xorg, other than that mostly jaunty packages.

Revision history for this message
Max Bowsher (maxb) wrote :

Some additional information on my problems reported in comment 33: (which, to recap, are that gnome-power-manager still stimulates Xorg into using excessive CPU with the patches applied, but not as excessive as without them, and that the CPU usage stops after a while)

I turned off autostart of g-p-m in gnome-session-properties and instead ran it manually as 'gnome-power-manager --no-daemon --verbose' so that I could capture its logging. I am attaching the result. Of particular relevance, note that in the logs there is a gap of 2 minutes 26 seconds in the log timestamps at line 86 of the file - it is during this interval that the CPU usage is occurring. If the log output is anything to judge by, it looks like g-p-m may be blocked waiting on Xorg during this time. Once this situation unblocks, a HUGE quantity of various gpm_brightness_xrandr_* calls are logged.

Revision history for this message
Isaac Clerencia (isaaccp) wrote :

i am completely up-to-date but still having problems whenever the screen brightness changes, even if it's a manual change by me (i.e., using the Macbook brightness buttons) ...

Revision history for this message
Mario Limonciello (superm1) wrote :

closing gnome desktop task. it was fixed in version 1:2.25.5-0ubuntu1

Changed in gnome-desktop:
status: In Progress → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-power-manager - 2.24.0-0ubuntu14

---------------
gnome-power-manager (2.24.0-0ubuntu14) jaunty; urgency=low

  * Add 79-randr13-speed-fix.patch from Gnome SVN to use a less expensive
    call when operating with xrandr 1.3. Original patch by Alberto Milone,
    much thanks. (LP: #307306)

 -- Mario Limonciello <email address hidden> Wed, 28 Jan 2009 13:44:54 -0600

Changed in gnome-power-manager:
status: In Progress → Fix Released
Revision history for this message
Max Bowsher (maxb) wrote :

Reversing automated action of Launchpad Janitor, as per my previous comments the patch improves but does not fully fix the problem with gnome-power-manager

Changed in gnome-power-manager:
status: Fix Released → In Progress
Revision history for this message
Max Bowsher (maxb) wrote :

I am reopening the task against gnome-desktop, as in my case, on the Acer Aspire One, the current 1:2.25.5-0ubuntu1 does _not_ fix the problem. I require additionally Peter Clifton's workaround from comment 23, a.k.a. http://bugzilla.gnome.org/attachment.cgi?id=126905&action=view, or the Xorg CPU usage pegs at 50% (100% of one core) and remains there, with killing gnome-power-manager _not_ being a solution in this case.

Changed in gnome-desktop:
status: Fix Released → In Progress
Revision history for this message
Alberto Milone (albertomilone) wrote :

Max: does killing gnome-settings-daemon solve the problem?

Revision history for this message
Max Bowsher (maxb) wrote :

No, killing gnome-settings-daemon does not affect the CPU usage level, as mentioned in comment 33 above.

Revision history for this message
In , Eric Anholt (eric-anholt) wrote :

So is there any evidence of the server actually doing anything wrong? It sounds like we have at least some instances of common clients misbehaving.

Revision history for this message
In , Eric Anholt (eric-anholt) wrote :

keithp pointed out that in fact the server *was* doing the wrong thing.

commit 10f26957f8392eb7913172f482f66eb71252761d
Author: Eric Anholt <email address hidden>
Date: Fri Jan 30 19:06:17 2009 -0800

    randr: Avoid re-querying the configuration on everything but GetScreenResources.

    The new path should only re-query on the other requests when we haven't
    gathered the information from the DDX yet (such as with a non-RandR 1.2 DDX).

    Bug #19037.

(confirmed that with this patch I can xrandr --current --props without hitting the re-query)

Revision history for this message
Alberto Milone (albertomilone) wrote :

Ok Max, it must be a different bug then. Please file a new bug report and explain that, differently from this bug, killing gnome-settings-daemon and gnome-power-manager doesn't solve the problem.

Revision history for this message
Bryce Harrington (bryce) wrote :
Changed in xorg-server:
status: Confirmed → Fix Released
Revision history for this message
Max Bowsher (maxb) wrote :

Bug 324524 filed concerning the g-p-m slow startup and less-than-full-but-still-abnormal CPU usage.

I don't recall any relevant updates, but the full CPU usage issue which I refer to in the 2009-01-30 comments no longer reproduces for me, so I'm happy to close this bug.

Revision history for this message
Max Bowsher (maxb) wrote :

Re Alberto's last comment - killing g-p-m _does_ solve the issue now broken out into bug 324524 - I'm absolutely convinced that that one is g-p-m related.

The issue which g-p-m didn't solve was the full CPU usage which I can no longer reproduce. Sorry for being less than clear which one I was talking about.

Revision history for this message
Max Bowsher (maxb) wrote :

Undoing re-opening of bug, as some subsequent change seems to have fixed the problem for real.

Changed in gnome-power-manager:
status: In Progress → Fix Released
Changed in gnome-desktop:
status: In Progress → Fix Released
Revision history for this message
Reuben Thomas (rrt) wrote :

I am getting exactly this problem, still, with the latest jaunty packages that have claimed to fix it.

If I run gnome-settings-daemon, I get constant ~30% CPU usage.

If I kill gnome-settings-daemon, the problem goes away.

I have another machine also running jaunty which doesn't show the problem, using the same driver (but different Intel hardware: the functioning machine is a Samsung NC-10 Atom-based laptop, and the non-functioning one is a Mac mini, first Intel generation with Intel integrated graphics).

Revision history for this message
Joseph Method (tristil) wrote :

The g-s-d problem caused me to misinterpret a problem with dual-monitor displays. On a Macbook 1,1 whenever I plugged in a DVI-to-HDMI connector to a flatscreen television (using a TMDS-1 output on an intel card), on hotplug the machine would start to slow down. On coldplug and an unaltered xorg.conf it would attempt to load both displays but the flatscreen would start flickering on and off and eventually stop attempting to display anything. xrandr would show both active LVDS and TMDS-1 connections. Any attempt to use gnome-display-settings would only show a blank application window that could not be closed except by force quit. I had assumed that this was an issue directly with xserver-xorg-intel until I saw this bug.

As of today, killing gnome-settings-daemon immediately caused the flatscreen video to appear and slowness issues are gone. Trying to use gnome-display-settings immediately kills the display and shows the blank window again. Perhaps this points to xrandr and intel, or xrandr and dual-monitor auto-detection?

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)

Revision history for this message
Joseph Method (tristil) wrote :
Revision history for this message
Joseph Method (tristil) wrote :

Just to be clear, these are the same symptoms that Chousuke reported on 2009-01-26. Running gnome-display-properties will cause the screen to go black until it's closed, regardless of whether g-s-d is running. A clean X session with g-s-d disabled at startup and briefly running gnome-display-properties is the same size as the previous log.

Revision history for this message
Sebastien Bacher (seb128) wrote :

commenting on a closed bug about different issues will not work great there, you should better open new bugs about your performances issue with a clear description

Revision history for this message
Sebastien Bacher (seb128) wrote :

could whoever is subscribed to this bug with an anti-spam service which replies to comment stop that now?

Revision history for this message
Twig (pfirth) wrote :

That may have been my overzealous spam filter. I've disabled it now. Sorry for the problem.

Revision history for this message
Joseph Method (tristil) wrote :
Revision history for this message
MrAuer (mr-auer) wrote :

I noticed this too, updated today, installed from Jaunty Beta amd64. Gnome is unusably slow on a dualcore - sucks up between 50-90% idling from login onwards - this happens every time I log in to Gnome. The problem is only with Gnome - Im now running XFCE and everything works right and smooth, with cpu idling at a few percentage.

One monitor only, Nvidia driver supplied by Jaunty repos (180.37). Ill try to look further into this later.

Changed in gnome-desktop:
status: Fix Released → New
Revision history for this message
Sesivany (jiri-eischmann) wrote :

I upgraded from Ubuntu 8.10 to 9.04 64bit. Xorg takes 15-30 % CPU all the time even if it's idle.
lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)

Revision history for this message
Alberto Milone (albertomilone) wrote :

if killing both gnome-setting-daemon and gnome-power-manager doesn't solve the problem, please file a new bug report and follow the instructions reported here to diagnose the problem:
https://wiki.ubuntu.com/X/Troubleshooting/HighCPU

Revision history for this message
Sam Denison (z-launchpad-denisons-org) wrote :

I also have had this problem, stopping the mentioned GNOME components didn't solve the problem, although it did bring the X server CPU usage down from about 50% to about 20%. I have an IBM ThinkPad X32, with a "ATI Radeon Mobility M6 LY (AGP)" 16MB.

Changed in gnome-desktop:
status: New → Fix Released
Revision history for this message
Pavol Klačanský (pavolzetor-deactivatedaccount) wrote :

hallo, i have same problem, the status bars cause it, I've attached screenshot
when I use theme without animated status bars, it's better

Revision history for this message
BigBadBassMan (d-reiche) wrote :

this also seems to affect vino (vino-server) because disabling it shows normal behaviour, whereas an enabled vino whill eat up to 70% of CPU on a Core2Duo E8400 with only Firefox and pidgin opened.

Revision history for this message
William Grant (wgrant) wrote : Re: [Bug 307306] Re: upgrade to 2:1.2.99.2-0ubuntu1 makes session utterly slow

On Mon, 2009-04-27 at 12:35 +0000, BigBadBassMan wrote:
> this also seems to affect vino (vino-server) because disabling it shows
> normal behaviour, whereas an enabled vino whill eat up to 70% of CPU on
> a Core2Duo E8400 with only Firefox and pidgin opened.

 affects vino
 status invalid

That would be a different bug. Please file a new one.

--
William Grant
Ubuntu Developer - http://www.ubuntu.com/

Changed in vino:
status: New → Invalid
Michael Terry (mterry)
tags: added: oem-services
Changed in xorg-server:
importance: Unknown → High
Changed in gnome-desktop:
importance: Unknown → High
Revision history for this message
David Parker (davparker) wrote :

unsubscribe

On Wed, Sep 15, 2010 at 4:43 PM, Bug Watch Updater <
<email address hidden>> wrote:

> ** Changed in: gnome-desktop
> Importance: Unknown => High
>
> --
> upgrade to 2:1.2.99.2-0ubuntu1 makes session utterly slow
> https://bugs.launchpad.net/bugs/307306
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (309776).
>
> Status in GNOME Desktop Common Files: Fix Released
> Status in Gnome Powermanager: Fix Released
> Status in libgnome: Invalid
> Status in GNOME Remote Desktop: Invalid
> Status in X.Org X server: Fix Released
> Status in “gnome-desktop” package in Ubuntu: Fix Released
> Status in “gnome-power-manager” package in Ubuntu: Fix Released
> Status in “libxrandr” package in Ubuntu: Invalid
>
> Bug description:
> I upgraded Jaunty this morning, and after a reboot, my system was utterly
> slow and sluggish as soon as I started the GNOME session. boot and gdm
> worked fine, and a failsafe X-Terminal only session works fine as well.
>
> I bisected this to the upgrade of libxrandr2 from 2:1.2.3-1 to
> 2:1.2.99.2-0ubuntu1.
>
> This is a Dell Latitude D430
>
> $ xrandr
> Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1280 x 1280
> VGA disconnected (normal left inverted right x axis y axis)
> LVDS connected 1280x800+0+0 (normal left inverted right x axis y axis)
> 261mm x 163mm
> 1280x800 59.8*+
> 1024x768 60.0
> 800x600 60.3
> 640x480 59.9
> TMDS-1 disconnected (normal left inverted right x axis y axis)
> TV disconnected (normal left inverted right x axis y axis)
>
> $ lspci | grep VGA
> 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS,
> 943/940GML Express Integrated Graphics Controller (rev 03)
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/gnome-desktop/+bug/307306/+subscribe
>

Changed in gnome-power:
importance: Unknown → Critical
Changed in xorg-server:
importance: High → Unknown
Changed in xorg-server:
importance: Unknown → High
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.