[karmic] Xorg 100% CPU utilization -- only after first login

I was going to attach an Xorg.log, but strangly enough the problem hasn't appeared yet after three or four reboots.

I've just added an SSD to my existing Dell XPS M1330, installed a fresh karmic and it started happening.
It did *not* happen with my previous setup, and if I add my previous disk back, it does not occur.
Other than SSD vs HD, one is an upgrade from Jaunty, and the other one is a fresh karmic install.
Danilo, sitting next to me, has the exact same problem on similar hardware (ssd, intel graphics).

The issue goes away after logging out and logging back in a few times, and occurs as well if I log into xterm.
I can reproduce it 100% of the time:

- Boot/reboot
- Log in
- 100% CPU usage constant, never goes down

To work around it I:
- Log out
- Log back in with the same user
- Sometimes, log out/in *again*

Not sure what I can provide to debug, will see of apport-collect provides anything interesting.

This is also happens with my ordinary HDD, so it's not an SSD-exclusive bug.

Seph, *exact* same symptoms?
Boot, log in, 100% CPU used by X, log out, log back in, problem solved?

What hardware do you have?

I have the same one. start gdm solves the problem.

 have a Samsung P60 (Radeon Mobile X1600,intel centrino duo, boot from USB)

Same bug: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/437607

That is, happens also here, with Nvidia proprietary drivers on Karmic, GeForce 7600 GS. No SSD drives.

I have same problem but on Hard Drive. Using liveusb of beta. 100% CPU of xorg upon startup. Logout and back in and xorg no longer using the CPU.

Intel core2duo
g965 x3000

Stil happens after updating today to the latest kernel and libmesa.

It looks like a duplicate of #407309

This one doesn't make the system slow and unresponsive at all -- it's barely noticable at all, except for the fan ramping up. But I agree, some of the 'me too' replies are clearly instances of this bug.

Same problem here. Clean installation of Karmic beta:
HDD
GF 8600GS (no Nvidia drivers)

This is significant issue for notebook users - it "eats" battery.

Bryce, Could you please take a look and advise?

I can confirm this bug, 100% usage on 1 core, log out and back in solves it
no ssd, but I do have a raid 10 config

Started after installing the nvidia restricted drivers (version 185)

btw, I have a amd phenom II X4 9100 cpu
GA-MA790XT-UD4P mobo
and nvidia 6600gt graphics card

Exactly same symptoms: xorg at 100% after first login. logout than login again is ok. I have a very ordinary configuration with nvidia restricted drivers. Latest updates applied.

This happens to me with the nvidia, the nv, and the nouveau driver.
Here's another thing I noticed: when I have the issue, xorg is not able to open the acpid socket:

(WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)

If I log out and log back in, things go back to normal:

(II) Open ACPI successful (/var/run/acpid.socket) and cpu usage is normal.

I'm having this issue using the intel driver. My system is nearly unusable because of it.

In general, xorg 100% cpu bugs are rarely actually X bugs. X is a server process that serves client requests. Client applications can send X an endless series of requests, and this will drive the X cpu utilization through the roof, but it is the client application which is bugged; the X server is just doing its job.

I don't know if that is the case here, as insufficient information has been gathered so far, but the circumstantial evidence points this way. People are reporting the same issue on a wide variety of different video drivers (the difference between -nvidia and -intel is HUGE; it's quite unusual for a particular X bug to affect both.) The original report says that both the 1.6 server in Karmic and the 1.7 server upstream were tested and saw the same behavior, and that rules out a lot of possibilities of it being an X bug. The behavior that logging out and logging back in also sounds suspicious. Marc's last comment regarding the acpid socket being unavailable also sounds like a strong clue (X doesn't manage acpi stuff anymore, but acpi includes keyboard handling stuff, so I could imagine a broken acpi daemon could get stuck in a loop querying X a lot.)

Anyway, for the case that it is a client application causing the problem, the troubleshooting process is straightforward: Just start killing user processes until the X CPU drops, and when that happens you have your culprit.

Or, if you find that no process killing reduces the X CPU, the next step would be to use gdb and strace to get an idea on what section of X code is being triggered here.

Another approach would be to bisect the problem by booting earlier versions of Karmic to find one where the problem did *not* occur, and then identify the one where it first started occurring, and then look at all the packages that changed between those two points.

Oh, given how many people have 'me-too'd on this bug, it feels like a regression that maybe occurred pretty recently. Check your /var/log/dpkg.log to see what packages were changed. I don't think there were any notable changes in X around the end of Sept when this was first reported, so that again makes me suspect this is actually not an X bug.

Thomas emailed me off-bug with some additional insights:

"I'd like to bring your attention to bug #439138 [1], which I think
affects a large group of people and is important to get fixed before the
final release. The issue seems to be that on fast systems (for example
systems with an SSD in it), X is started "too early" during the boot
precess and this somehow results in the tty fd being in an error state,
which causes select() to return immediately, but there's no code in X to
recover from the error, leading to 100% CPU utilization."

(Fwiw, it's preferable to post info to the bug report than to email me directly.)

The behavior of VT switching points toward a low-level bug, rather than an application bug (cf. #437607):

0. After first login: X consumes 100% CPU
1. Alt+SysRQ+R (release KB, the VT switching seems to be disabled in default configuration?)
2. Alt+F1 (switch to VT1)
3. Something (Xorg?) causes the VT to switch immediately back to VT7
3b. The "Switch user" functionality in Gnome doesn't work either: VT switches always back to VT7
4. Log out from X, log then back in
5. X cpu consumption low
6. Alt+F1
7. Now the VT does not switch immediately back
7b. Also "Switch user" functionality works again.

It could be useful if the past/future me-tooers verified if they see this same behavior vs. VT switching. There may be multiple causes for 100% cpu consumption, but to me the above seems too much of a coincidence to be accidental.

The problem appears to be localized to the new upstart boot stuff. X is trying to call tcflush() to flush the console of any unwritten output, but is getting an EIO error now. Since the console doesn't get flushed, that's leaving stuff there and makes the console fd appear to still be readable all the time, so X never gets a chance to sleep. Since it's never sleeping, the CPU goes to 100%.

jcristau found the EIO error is being returned at this point in tcflush():

        if (is_current_pgrp_orphaned()) {
                 ret = -EIO;
                 goto out;
         }

So next question is, why is is_current_pgrp_orphaned() failing?

Question's to you keybuk... why is X not able to tcflush() during bootup, and what's the right way to deal with the error?

What's this got to do with Upstart?

Why *should* X be able to tcflush() ?

the switch of gdm to upstart seemed to be a possible reason for this behaviour change. maybe it's something else though..
anyway, the use of tcflush() in X was added by:

commit 446d9443cea31e493d05c939d0128a8116788468
Author: Adam Jackson <email address hidden>
Date: Wed Nov 5 11:51:06 2008 -0500

    linux: Drain the console fd of data when using evdev for keyboards

    Works around a silly bug in the kernel that causes wakeup storms after
    too many keypresses. Should fix the kernel bug too, but this at least
    keeps the idle wakeup count below 1000/sec.

On Tue, 2009-10-06 at 14:36 +0000, Julien Cristau wrote:

> the switch of gdm to upstart seemed to be a possible reason for this behaviour change. maybe it's something else though..
> anyway, the use of tcflush() in X was added by:
>
> commit 446d9443cea31e493d05c939d0128a8116788468
> Author: Adam Jackson <email address hidden>
> Date: Wed Nov 5 11:51:06 2008 -0500
>
> linux: Drain the console fd of data when using evdev for keyboards
>
> Works around a silly bug in the kernel that causes wakeup storms after
> too many keypresses. Should fix the kernel bug too, but this at least
> keeps the idle wakeup count below 1000/sec.
>
But what is meant here by "the console" ?

Scott
--
Scott James Remnant
<email address hidden>

See xf86OpenConsole at http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/os-support/linux/lnx_init.c
"the console" is /dev/ttyN, where N is the vt X runs on.

Scott James Remnant wrote:
> What's this got to do with Upstart?

X is started too early during bootup when the console isn't "ready" yet.
 Where we don't know yet what "ready" means. There's also this:

(WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)

So we need a dependency for acpid.

>
> Why *should* X be able to tcflush() ?

This problem has nothing to do with tcflush(). Even with commit
446d9443cea31e493d05c939d0128a8116788468 reverted, we still have
the same issue. Since the fd is in an error state, select() will always
return right away.

acpid doesn't matter, X will run just fine without it. Not sure what "the console isn't ready" means...

I'm also affected by this bug. It make my system completely unusable. I have no SSD, only a HDD, and logging out and in again does not fix the issue for me.

I have no idea what hardware I have, but as that is apparently not relevant, I can try to give any other info you need.

I had similar problems (100% cpu load, no console switching possible) after kdm start had been ported to upstart. I solved the problem by modifying the upstart configuration file for kdm:

       start on (filesystem
++ and stopped udev-finish
      and started hal)

This ensures that the virtual console devices are set up properly before the X server starts.

Still nothing to do with Upstart.

I would like to know *what* X is doing with that tcflush() and why it is apparently unable to cope with it returning an error. What is that trying to access, why isn't there a graceful fallback for it not existing, etc.

Let's figure this out, rather than just trying to work around it. Our whole fast boot plans are contingent on getting X up early - right now you're saying that's impossible - and I want you to prove that.

The kdm fix from jsiebold works also for gdm (/etc/init/gdm.conf)

On Tue, 2009-10-06 at 18:31 +0000, Rob van Vliet wrote:

> The kdm fix from jsiebold works also for gdm (/etc/init/gdm.conf)
>
This fix is wrong.

Just so you know.

Let's work out what the real fix should be.

Scott
--
Scott James Remnant
<email address hidden>

It has *nothing* to do with tcflush(). As I said above, If I revert the
patch that introduced the tcflush() call, I can still reproduce this
problem. This is just the semantics of select(): If a fd is in an error
state, then a subsequent read() or write() won't block (since they will just
return an error), so select() returns right away. So what we need to figure
out is why the console fd dies.

On Tue, Oct 6, 2009 at 2:26 PM, Scott James Remnant <email address hidden>wrote:

> Still nothing to do with Upstart.
>
> I would like to know *what* X is doing with that tcflush() and why it is
> apparently unable to cope with it returning an error. What is that
> trying to access, why isn't there a graceful fallback for it not
> existing, etc.
>
> Let's figure this out, rather than just trying to work around it. Our
> whole fast boot plans are contingent on getting X up early - right now
> you're saying that's impossible - and I want you to prove that.
>

I'm not saying this is impossible, but clearly there's something we need to
wait for before we can start X (and not for a very long time, since we don't
seem to see this problem on slower systems at all).

I'm not sure this is the same bug - but the timing and symptoms are the same. In my case though DRM is failing. It says:

[ 1.698032] [drm:drm_fill_in_dev] *ERROR* Cannot initialize the agpgart module.
[ 1.698157] [drm:intelfb_restore] *ERROR* Failed to restore crtc configuration: -22
[ 1.698216] DRM: Fill_in_dev failed.

If I logout from X, modprobe -r i915 drm, modprobe i915 and then restart X it's fast again. For the record: I'm an SSD user.

It still happens. "Package: usplash; Architecture: i386; Version: 0.5.42"
Pleas write if you need additional logs or tests run.

On Tue, 2009-10-13 at 15:46 +0000, Tom Jaeger wrote:

> ** Also affects: cryptsetup (Ubuntu)
> Importance: Undecided
> Status: New
>
> ** Changed in: cryptsetup (Ubuntu Karmic)
> Status: New => Confirmed
>
> ** Changed in: usplash (Ubuntu Karmic)
> Status: Confirmed => Invalid
>
> ** Changed in: upstart (Ubuntu Karmic)
> Status: Invalid => Confirmed
>
Why have you made these changes?

Please provide an explanation - do you have a proposed fix for the bug
that fits these status changes - or do you have detailed debugging that
proves that they are correct.

If not, please don't randomly reassign packages.

Scott
--
Scott James Remnant
<email address hidden>

This was in response to your (!) comment #106:

> The right fix is to eliminate all uses of "console owner" (which is
> clearly wrong) and get rid of it.

usplash clearly has nothing to do with this bug, cryptsetup is
responsible for taking away the console from X, and the place where you
would get rid of "console owner" is upstart, right?

Now if someone familiar with the cryptsetup package could explain why it
needs console ownership, we could actually get anywhere.

Scott James Remnant wrote:
> On Tue, 2009-10-13 at 15:46 +0000, Tom Jaeger wrote:
>
>> ** Also affects: cryptsetup (Ubuntu)
>> Importance: Undecided
>> Status: New
>>
>> ** Changed in: cryptsetup (Ubuntu Karmic)
>> Status: New => Confirmed
>>
>> ** Changed in: usplash (Ubuntu Karmic)
>> Status: Confirmed => Invalid
>>
>> ** Changed in: upstart (Ubuntu Karmic)
>> Status: Invalid => Confirmed
>>
> Why have you made these changes?
>
> Please provide an explanation - do you have a proposed fix for the bug
> that fits these status changes - or do you have detailed debugging that
> proves that they are correct.
>
> If not, please don't randomly reassign packages.
>
> Scott

On Tue, Oct 13, 2009 at 07:05:18PM -0000, Tom Jaeger wrote:
> Now if someone familiar with the cryptsetup package could explain why it
> needs console ownership, we could actually get anywhere.

Because it needs to be able to prompt users for passphrases. How does
knowing that bring us any closer to solving this bug?

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

On Tue, Oct 13, 2009 at 07:05:18PM -0000, Tom Jaeger wrote:
> usplash clearly has nothing to do with this bug,

There are some interesting interactions between usplash and 'console
owner'. It would do no harm to leave that task open.

> cryptsetup is responsible for taking away the console from X, and the
> place where you would get rid of "console owner" is upstart, right?

Not really. cryptsetup's upstart job is the one that actually uses
'console owner'. The jobs upstart itself ships doesn't use it any more,
except on some error paths where X isn't started. Removing support for
'console owner' from upstart would only be feasible if no jobs needed it
any more, so I don't see how it could block this bug.

Having this same issue of high cpu usage since this morning after several updates including misc x stuff such as libmesa and also some linuxheaders.

Tried the logout, log back in. Nothing.
Read about this being only for Intel chipset/graphics, I have a weird ATI chipset/Nvidia graphics combo, so no dice. Also no SSD.
Read about cryptdisk having something to do about it but I dont have it installed (nor was it ever installed), so nothing again.

One thing in common with others, been having some issues with splash in boot for a couple of days now, first it would give me some garbage and stop the boot process. Then after some updates it apparently got better, still garbage but would eventually get GDM.
Disabled it from the kernel boot line and everything seemed ok, until this mornings updates.

So I can login, did a workaround, started in recovery mode, logged console style, no gdm. Startx gives me my desktop, but again with the high cpu usage, as far as I know GDM is not around so I would dare say is not GDM but X.

Something funny happened in one of my attempts to fix this. I was browsing, looking for alternatives, reading this thread, spent some minutes working while enduring the high cpu usage.
Went to reboot and Gnome asked -via a dialog- if I was sure, because an unknow program was working. The moment this dialog showed up CPU usage dropped to normal. Click cancel, go back to desktop and for a couple of seconds everything remained nominal, but after a couple of clicks here and there CPU usage went back to high.
Tried to repeat the whole reboot process but this time I didnt get a question and so the computer went ahead with the reboot.

Very funky stuff.

Steve Langasek wrote:
> On Tue, Oct 13, 2009 at 07:05:18PM -0000, Tom Jaeger wrote:
>> Now if someone familiar with the cryptsetup package could explain why it
>> needs console ownership, we could actually get anywhere.
>
> Because it needs to be able to prompt users for passphrases. How does
> knowing that bring us any closer to solving this bug?

Okay, so the job must complete before X is started then anyway[*]. Can
someone please remind me again why making gdm/kdm depend on cryptsetup
or even executing cryptsetup before anything else is not a solution?

[*] actually, this is true only in the minority of cases where that
there are encrypted disks that need to be mounted on startup.

Making the gdm and kdm jobs depend on cryptsetup is not a solution because cryptsetup is optional and depending on an optional job doesn't DTRT.

This is the same problem for "executing cryptsetup before anything else" - you can't ensure it's executed serially if you can't depend on it being executed at all.

Bryce suggested back in 23 to take a look at updated packages, heres the list of packages that brought on the epic fail in my system:

mountall 0.2.1 0.2.2
linux-image-2.6.31-13-generic 2.6.31-13.44 2.6.31-13.45
libpython2.6 2.6.4~rc1-0ubuntu1 2.6.4~rc1-0ubuntu2
python2.6 2.6.4~rc1-0ubuntu1 2.6.4~rc1-0ubuntu2
python2.6-minimal 2.6.4~rc1-0ubuntu1 2.6.4~rc1-0ubuntu2
xkb-data 1.6-1ubuntu2 1.6-1ubuntu3
command-not-found-data 0.2.38ubuntu3 0.2.38ubuntu4
command-not-found 0.2.38ubuntu3 0.2.38ubuntu4
update-manager 1:0.126 1:0.126.2
update-manager-core 1:0.126 1:0.126.2
acpi-support 0.127 0.129
gdm 2.28.0-0ubuntu14 2.28.0-0ubuntu15
libgdu-gtk0 2.28.0-1karmic1 2.28.0+git20091012-0ubuntu1
libgdu0 2.28.0-1karmic1 2.28.0+git20091012-0ubuntu1
libgl1-mesa-dri 7.6.0-1ubuntu2 7.6.0-1ubuntu3
libgl1-mesa-glx 7.6.0-1ubuntu2 7.6.0-1ubuntu3
linux-headers-2.6.31-13 2.6.31-13.44 2.6.31-13.45
linux-headers-2.6.31-13-generic 2.6.31-13.44 2.6.31-13.45
mesa-common-dev 7.6.0-1ubuntu2 7.6.0-1ubuntu3
xserver-xorg-input-evdev 1:2.2.5-1ubuntu1 1:2.2.5-1ubuntu2
libglu1-mesa 7.6.0-1ubuntu2 7.6.0-1ubuntu3

so there, the breakage occurred after the upgrade of these packages, hope this helps somehow.

So.... theres no -downgrade option in apt-get, right?

Steve Langasek, le Tue 13 Oct 2009 22:40:44 -0000, a écrit :
> Making the gdm and kdm jobs depend on cryptsetup is not a solution
> because cryptsetup is optional and depending on an optional job doesn't
> DTRT.

insserv's Should-Start is exactly that and works exactly as would be
expected here.

On Tue, Oct 13, 2009 at 09:44:04PM -0000, Askalaral wrote:
> Read about cryptdisk having something to do about it but I dont have it
> installed (nor was it ever installed), so nothing again.

The package name is cryptsetup, not cryptdisk. Do you have this package
installed?

If not, you appear to have a separate bug. Please open a separate bug
report.

If so, you're following up to a bug that has already been triaged and the
problem is understood, and no further information is needed to help fix this
bug. Please refrain from unnecessary follow-ups, they're a distraction to
the developers who are working on fixing this bug.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

On Tue, Oct 13, 2009 at 11:00:14PM -0000, Samuel thibault wrote:
> Steve Langasek, le Tue 13 Oct 2009 22:40:44 -0000, a écrit :
> > Making the gdm and kdm jobs depend on cryptsetup is not a solution
> > because cryptsetup is optional and depending on an optional job doesn't
> > DTRT.

> insserv's Should-Start is exactly that and works exactly as would be
> expected here.

And? We're not using insserv. Telling us about features of boot systems
we're not using doesn't help us with solving this bug.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Steve Langasek, le Tue 13 Oct 2009 23:14:50 -0000, a écrit :
> On Tue, Oct 13, 2009 at 11:00:14PM -0000, Samuel thibault wrote:
> > Steve Langasek, le Tue 13 Oct 2009 22:40:44 -0000, a écrit :
> > > Making the gdm and kdm jobs depend on cryptsetup is not a solution
> > > because cryptsetup is optional and depending on an optional job doesn't
> > > DTRT.
>
> > insserv's Should-Start is exactly that and works exactly as would be
> > expected here.
>
> And? We're not using insserv. Telling us about features of boot systems
> we're not using doesn't help us with solving this bug.

It helps in showing that it's not insane and actually probably helpful
to request the feature from upstart.

Scott was kind enough to provide some background on this bug in the #upstart channel:

<Keybuk> in Linux, we have consoles
<Keybuk> but really we mean Virtual Terminals (VTs)
<Keybuk> and we have TTYs too
<Keybuk> not to mention Pseudo-Terminals
<Keybuk> (PTYs)
<Keybuk> it's all a bit of the kind of jumble sale you get after 40 years of different solutions to different problems
<Keybuk> we can lump them together under the description "terminals" for the next bit
<Keybuk> we also have processes
<Keybuk> now, processes have a lot of odd little details
<Keybuk> they have a parent
<Keybuk> they have a session
<Keybuk> and a session has a foreground process group
<Keybuk> and a background process group
<Keybuk> now Stevens devotes an entire chapter for this
<Keybuk> and nobody but me apparently understands it ;)
<Keybuk> (and hopefully the guy who maintains the kernel side)
<Keybuk> but it works something like that
<Keybuk> each process is part of a session
<Keybuk> a process may begin a new session by calling setsid()
<Keybuk> every process that init creates is in its own session
<Keybuk> the process is also then the leader of the foreground process group of that session
<Keybuk> new processes are also in that session
<Keybuk> and in that process group
<Keybuk> unless otherwise placed into a new process group
<Keybuk> (setpgrp)
<Keybuk> any new process group is a background process group
<Keybuk> so now, you have a bunch of sessions
<Keybuk> each session has a bunch of process groups, one of which is the foreground process group
<Keybuk> each process group has a bunch of processes, one of which is the leader
<Keybuk> so this all has to do, fundamentally, with terminals
<Keybuk> and who gets the signals
<Keybuk> when the leader of the foreground process group of a session opens a terminal device (without O_NOCTTY) that becomes the CONTROLLING TERMINAL of that process group
<Keybuk> (in fact of that session)
<Keybuk> the terminal and the session become bound to each other
<Keybuk> you can fake this another way by opening a terminal device without O_NOCTTY (or having one passed to you) and then calling the TIOCSCTTY ioctl
<Keybuk> ok
<Keybuk> so
<Keybuk> terminals, controlling terminals and processes
<Keybuk> here's where this gets fun
<Keybuk> if the controlling terminal is hung up, SIGHUP is sent to the foreground process group
<Keybuk> if ^C is pressed on the controlling terminal, SIGINT is sent to the foreground process group
<Keybuk> if ^Z is pressed on the controlling terminal, SIGTSTP is sent to the foreground process group
<Keybuk> (you're getting the idea here I guess)
<Keybuk> so this is how the relationship between magic key presses and signals gets established
<Keybuk> shells care about this a lot
<Keybuk> (and yes, when you use & that becomes a background process group :p)
<Keybuk> (and when you use | they are all in the same process group)
<Keybuk> now
<Keybuk> this controlling terminal business applies to all terminals
<Keybuk> whether they be true terminals (which linux doesn't have)
<Keybuk> or virtual terminals
<Keybuk> or pseudo terminals
<Keybuk> so this is as true for your ssh login as VT1
<Keybuk> you can always access your *co...

This bug was fixed in the package cryptsetup - 2:1.0.6+20090405.svn49-1ubuntu6

---------------
cryptsetup (2:1.0.6+20090405.svn49-1ubuntu6) karmic; urgency=low

  [ Steve Langasek ]
  * Move the Debian Vcs- fields aside.

  [ Scott James Remnant ]
  * debian/cryptdisks-enable.upstart: Don't overcompensate for my idiocy,
    cryptsetup should not need a controlling terminal, just a terminal
    is fine. May fix LP: #439138.

 -- Scott James Remnant <email address hidden> Wed, 14 Oct 2009 04:52:16 +0100

I did an aptitude safe-upgrade today.
Since then I have the problem, that xorg eats 100% cpu (1 core) and the system is very unresponsive.

I use en encrypted root partition and my gpu is "00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)".

This bug was NOT FIXED in cryptsetup - 2:1.0.6+20090405.svn49-1ubuntu6 because i have
2:1.0.6+20090405.svn49-1ubuntu7 installed and the problem still existes!

I attached my aptitude log, please read it, as the bug was introduced in on of the upgraded packages. Before the upgrade today everything was fine.

PS: we need some functionality to undo an upgrade!
I first thought that it was an xorg failure so i tied to downgrade but apt cannot find the version before the upgrade anymore

~/ apt-show-versions xserver-xorg -a
xserver-xorg 1:7.4+3ubuntu7 install ok installed
xserver-xorg 1:7.4+3ubuntu7 karmic archive.ubuntu.com
xserver-xorg/karmic uptodate 1:7.4+3ubuntu7

~/ sudo apt-get install xserver-xorg=1:7.4+3ubuntu5
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Lese Status-Informationen ein... Fertig
E: Version »1:7.4+3ubuntu5« für »xserver-xorg« konnte nicht gefunden werden
translation: Version »1:7.4+3ubuntu5« for »xserver-xorg« could not be found

Please fix this soon! I cannot use my computer like that and like i said i also cannot undo the upgrade.

I did an aptitude safe-upgrade today.
Since then I have the problem, that xorg eats 100% cpu (1 core) and the system is very unresponsive.

I use en encrypted root partition and my gpu is "00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)".

This bug was NOT FIXED in cryptsetup - 2:1.0.6+20090405.svn49-1ubuntu6 because i have
2:1.0.6+20090405.svn49-1ubuntu7 installed and the problem still exists!

I attached my aptitude log, please read it, as the bug was introduced in on of the upgraded packages. Before the upgrade today everything was fine.

PS: we need some functionality to undo an upgrade!
I first thought that it was an xorg failure so i tried to downgrade but apt cannot find the version before the upgrade anymore

~/ apt-show-versions xserver-xorg -a
xserver-xorg 1:7.4+3ubuntu7 install ok installed
xserver-xorg 1:7.4+3ubuntu7 karmic archive.ubuntu.com
xserver-xorg/karmic uptodate 1:7.4+3ubuntu7

~/ sudo apt-get install xserver-xorg=1:7.4+3ubuntu5
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Lese Status-Informationen ein... Fertig
E: Version »1:7.4+3ubuntu5« für »xserver-xorg« konnte nicht gefunden werden
translation: Version »1:7.4+3ubuntu5« for »xserver-xorg« could not be found

Please fix this soon! I cannot use my computer like that and like i said i also cannot undo the upgrade.

EDIT: Please delete my first comment.
Due to my system being so unresponsive I accidentally did a double post.

Turns out, my issue looked like this bug, but was not related after all.

While fixing another bug in laptop-mode-tools I wrote "-X" instead of "-x" causing the xorg process to spike to 100% cpu usage.
I apologize for the confusion.

I upgraded to karmic a couple of days ago, since Synaptic announced that it was possible to upgrade to 9.10

My system is unusable because of this bug.

1) What's the actual situation about this bug?
2) Which informations can I provide in order to contribute to the solution?

Thanks

Hi manolo

The actual situation of this bug is documented in the status column of this bug. It shows either invalid or fix released. This means this bug has been declared dead. You can in general trust that declaration. You would have to bring some pretty solid evidence that this bug has somehow risen from the dead in order to make anyone doubt it. Including detailed documentation of how the tests went that differentiate this bug from all other bugs that make X max the CPU out.

Trust the status, especially if it has seen such high caliber attention as this bug :-)

Same problem here.

As manolo said, I just upgraded to 9.10 (from a 9.04), network upgrade, and Xorg cpu consumption rises to almost 100%. The machine is an Acer 5810T laptop (with an Intel graph card). With 9.04 went really well.

So, it isn't solved?

Can I help attaching some logs? Which ones?

Can you attach the output of "grep -r ^console /etc/init"?

Ride wrote:
> Same problem here.
>
> As manolo said, I just upgraded to 9.10 (from a 9.04), network upgrade,
> and Xorg cpu consumption rises to almost 100%. The machine is an Acer
> 5810T laptop (with an Intel graph card). With 9.04 went really well.
>
> So, it isn't solved?
>
> Can I help attaching some logs? Which ones?
>

Hi Wolfgang Kufner.

Thanks for your reply. At the moment I can provide the following video showing my tests made in order to confirm that Xorg still goes crazy, at least on my system:

http://www.youtube.com/watch?v=skuog28ZnoM

Then, please show me any other way to demonstrate wheter we are talking about the same bug or not.
Please tell me if I can provide any other infos about the bug or about the system.

Also, since Ride seems to have the same problem, I suppose it's worth to consider turning it as still an open bug.

Thank you.

Acer Aspire 5730z
Mobile Intel(R) 4 Series Express Chipset Family

Obviously, I remark the problem persists each time I start my system.

manolo@manolo-laptop:~$ grep -r ^console /etc/init
/etc/init/rcS.conf:console owner
/etc/init/mountall-shell.conf:console owner
/etc/init/mountall.conf:console output
/etc/init/ufw.conf:console output

manolo@manolo-laptop:~$ sudo grep -r ^console /etc/init
[sudo] password for manolo:
/etc/init/rcS.conf:console owner
/etc/init/mountall-shell.conf:console owner
/etc/init/mountall.conf:console output
/etc/init/ufw.conf:console output
manolo@manolo-laptop:~$

manolo wrote:
> Hi Wolfgang Kufner.
>
> Thanks for your reply. At the moment I can provide the following video
> showing my tests made in order to confirm that Xorg still goes crazy, at
> least on my system:
>
> http://www.youtube.com/watch?v=skuog28ZnoM
>
> Then, please show me any other way to demonstrate wheter we are talking about the same bug or not.
> Please tell me if I can provide any other infos about the bug or about the system.

It's not the same bug. This bug will prevent the X server from ever
sleeping, so you'll get (as the title says) 100% CPU utilization on one
core. Your video shows ~25% CPU utilization.

Also, if this were the same bug, restarting the X server would fix the
issue.

Hi again,

this is the output of the command grep -r ^console /etc/init

/etc/init/mountall.conf:console output
/etc/init/ufw.conf:console output
/etc/init/mountall-shell.conf:console owner
/etc/init/rcS.conf:console owner

Killing Xorg process doen't work for me. It seems that Xorg doen't get all the cpu for a couple of seconds, then cpu consumption rises again.

It's very annoying, even writting this post becomes a nightmare.

Any other log will help?

Ride wrote:
> Hi again,
>
> this is the output of the command grep -r ^console /etc/init
>
> /etc/init/mountall.conf:console output
> /etc/init/ufw.conf:console output
> /etc/init/mountall-shell.conf:console owner
> /etc/init/rcS.conf:console owner
>
> Killing Xorg process doen't work for me. It seems that Xorg doen't get
> all the cpu for a couple of seconds, then cpu consumption rises again.
>
> It's very annoying, even writting this post becomes a nightmare.
>
> Any other log will help?
>

This is a different issue then. Please file a new bug report.

Tom, thanks for your reply.
Actually that video showed the "best performing" session I've had with karmic :(

Anyway, the CPU consuming is ** at least 25% ** when no other programm is running, beside system daemons. Executing Firefox, for example, maked Xorg consume up to 80% till 100% of CPU.

I would exclude any Firefox influence: the problem persist even if I run Goolge Chromium, just installed it.

So, what to do? Open a new bug report? Declare this as duplicate of another bug?

Thanks for your attention.

manolo wrote:
> Tom, thanks for your reply.
> Actually that video showed the "best performing" session I've had with karmic :(
>
> Anyway, the CPU consuming is ** at least 25% ** when no other programm
> is running, beside system daemons. Executing Firefox, for example, maked
> Xorg consume up to 80% till 100% of CPU.
>
> I would exclude any Firefox influence: the problem persist even if I run
> Goolge Chromium, just installed it.
>
> So, what to do? Open a new bug report? Declare this as duplicate of
> another bug?

Since your issue has nothing to do with this bug, please file a new bug
report.

Opened a new gug report:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/472406

@Ride, please joint to it just in case your bug coincides.

I'm having the same symptoms. I'm on the 9.10 release.

Hi Brian.

Which symptoms do you have? The ones that desappear just killing Xorg (in this case this launchpad page is the right place) or the ones described in this recently open bug report:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/472406

?

In this case this is not the right place. So please refer to the above link, trying to exopse your problem more in detail.

Thank you.

I tracked my issue to Vino. When I turned off the remote sharing the problem went away.

The symptoms I had were when I first logged in, Xorg consumed much of the cpu. After logging out and logging back in, the cpu went down.

As I mentioned in my previous comment, it seems like Vino is the culprit.

Also, the issue is not present when I start Vino once logged in. It seems like it happens when Vino is on when logging in.

Just hit this bug today in my Karmic 9.10. I have a Dell Latitude e6500 with intel graphics. It happened once today, first time, after rebooting it was gone.

100% CPU usage, if you need any other data, please tell me. Ç

Thanks

@Miguel: As said to other people above: this bug has been marked as fixed with a good reason, and you are probably encountering a different issue -- there are more than one possible reason for 100% CPU usage. Please file a new bug report.

Sorry about that, I will try to find the right bug and if not open a new one.

Thanks Pauli

FYI I just saw this bug in Xubuntu 10.04, running as a VM under Virtualbox 4.2 and OSX.

top showed 100% for Xorg process. Attaching strace to it gave the attached screenshot. After a few seconds of this scrolling up the whole graphic system froze, but I can still ssh to the VM happily, and CPU utilisation has dropped back down to zero.

From the ssh session:

brian@gateway:~$ ps auxwww | grep X
root 739 77.7 5.7 116344 29136 ? Ts 15:17 18:07 /usr/bin/X :1 -br -verbose -auth /var/run/gdm/auth-for-gdm-6yRsVu/database -nolisten tcp
brian 1129 0.0 0.1 4108 632 ? Ss 15:18 0:00 /bin/sh /etc/xdg/xfce4/xinitrc -- /etc/X11/xinit/xserverrc
brian 1325 0.0 2.8 232464 14516 ? Sl 15:18 0:00 /usr/lib/xfce4/panel-plugins/xfce4-menu-plugin socket_id 37748789 name xfce4-menu id 1 display_name Xfce Menu size 24 screen_position 1
brian 1682 0.0 0.1 7644 980 pts/4 S+ 15:41 0:00 grep --color=auto X
brian@gateway:~$ ps auxwww | grep strace
root 1669 0.0 0.1 4348 760 pts/1 S+ 15:37 0:00 strace -p 739
brian 1684 0.0 0.1 7640 920 pts/4 S+ 15:41 0:00 grep --color=auto strace
brian@gateway:~$ uptime
 15:41:41 up 23 min, 6 users, load average: 0.01, 0.42, 0.52