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

[Tom Jaeger]

On my system, Xorg takes up 100% of (one of the) CPUs after startup. The problem goes away once the X server is restarted. This happens both with the xserver from the archive and the latest 1.7 snapshot. This might be a race related to the fact that ubuntu is installed on an SSD. It seems to be the same problem that is discussed in this ubuntuforums thread:

http://swiss.ubuntuforums.org/showthread.php?t=1272691

Here is what I could find out about the problem:

strace reports repeated (failing) calls to

ioctl(5, TCFLSH, 0x2) = -1 EIO (Input/output error)

where fd 5 is /dev/tty7. This translates to a tcflush call in drain_console(). Backtrace:

Breakpoint 6, drain_console (fd=5, closure=0x0) at ../../../../../hw/xfree86/os-support/linux/lnx_init.c:89
89 ../../../../../hw/xfree86/os-support/linux/lnx_init.c: No such file or directory.
        in ../../../../../hw/xfree86/os-support/linux/lnx_init.c
(gdb) bt
#0 drain_console (fd=5, closure=0x0) at ../../../../../hw/xfree86/os-support/linux/lnx_init.c:89
#1 0x000000000046ecd1 in xf86Wakeup (blockData=<value optimized out>, err=<value optimized out>, pReadmask=<value optimized out>)
    at ../../../../hw/xfree86/common/xf86Events.c:285
#2 0x0000000000443c7b in WakeupHandler (result=7, pReadmask=0x7d8440) at ../../dix/dixutils.c:413
#3 0x00000000004609d5 in WaitForSomething (pClientsReady=<value optimized out>) at ../../os/WaitFor.c:232
#4 0x0000000000440ef2 in Dispatch () at ../../dix/dispatch.c:381
#5 0x00000000004265fc in main (argc=9, argv=0x7d7228, envp=<value optimized out>) at ../../dix/main.c:285
o

So we have a fd in some kind of error state that causes select() to always return right away. I don't know enugh about how select() works to identify the problem, though.

[Tom Jaeger (thjaeger)]

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

[Martin Albisetti (beuno)]

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.

[Nicholas Christian Langkjær Ipsen (ncli)]

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

[Martin Albisetti (beuno)]

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

What hardware do you have?

[chrigu (ch-ba)]

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

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

[Pauli Virtanen (pauli-virtanen)]

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

[Pauli Virtanen (pauli-virtanen)]

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

[Andrew (andrewabc)]

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

[Martin Albisetti (beuno)]

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

[Vinicius Seixas (vipseixas)]

It looks like a duplicate of #407309

[Tom Jaeger (thjaeger)]

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.

[Andriy Tsykholyas (andriy-tsykholyas)]

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

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

[Rick Spencer (rick-rickspencer3)]

Bryce, Could you please take a look and advise?

[Jens (jens.timmerman)]

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)

[Jens (jens.timmerman)]

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

[aldebx (aldebx)]

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.

[Marc Deslauriers (mdeslaur)]

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.

[Michael Lustfield (michaellustfield)]

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

[Bryce Harrington (bryce)]

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.

[Bryce Harrington (bryce)]

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.

[Bryce Harrington (bryce)]

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.)

[Pauli Virtanen (pauli-virtanen)]

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.

[Bryce Harrington (bryce)]

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?

[Bryce Harrington (bryce)]

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?

[Scott James Remnant (Canonical) (canonical-scott)]

What's this got to do with Upstart?

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

[Julien Cristau (jcristau)]

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.

[Scott James Remnant (Canonical) (canonical-scott)]

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>

[Julien Cristau (jcristau)]

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.

[Tom Jaeger (thjaeger)]

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.

[Julien Cristau (jcristau)]

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

[Steveire (steveire)]

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.

[jsiebold (jsi150)]

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.

[Scott James Remnant (Canonical) (canonical-scott)]

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.

[Rob van Vliet (rob-van-vliet)]

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

[Scott James Remnant (Canonical) (canonical-scott)]

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>

[Tom Jaeger (thjaeger)]

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).

[Teodor Milkov (tm-del)]

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.

[Julien Cristau (jcristau)]

Tom, I can't see anything besides this tcflush() thing adding the console fd to the set we select() on. What do you mean by "the console fd dies"?

Teodor, it's not the same bug.

[Tom Jaeger (thjaeger)]

You're right, I actually forgot to install the package, so you don't
have 100% CPU anymore after reverting the commit. But this really
doesn't fix the underlying problem, we still have an invalid console fd
floating around, which for example is preventing us from switching
virtual terminals.

Julien Cristau wrote:
> Tom, I can't see anything besides this tcflush() thing adding the
> console fd to the set we select() on. What do you mean by "the console
> fd dies"?
>
> Teodor, it's not the same bug.
>

[Samuel thibault (samuel-thibault)]

Tom Jaeger, did you actually notice switching VT not working? Could
you get an strace of that happening?

Could people getting the error check /proc/`pidof X`/status? Here I
have

SigIgn: 0000000010301000

The important part is the 3. If the 3 is not there it's normal that
tcflush() return EIO for the console: because X starts its own session
alone, it is an orphaned group.

A good fix could be to just re-enable the TIOCNOTTY part from
xserver/hw/xfree86/os-support/linux/lnx_init.c which got dropped for no
apparent good reason, while here we have a good reason to ignore all
the controlling terminal semantic.

[Tom Jaeger (thjaeger)]

Samuel thibault wrote:
> Tom Jaeger, did you actually notice switching VT not working? Could
> you get an strace of that happening?
Yes, I did. The issue comes and goes; and unfortunately I can't
reproduce it right now. This is the system call that failed, though
(hw/xfree86/common/xf86Events.c:212):

if (ioctl(xf86Info.consoleFd, VT_ACTIVATE, vtno) < 0)
    ErrorF("Failed to switch consoles (%s)\n", strerror(errno));

The error was EIO as well, IIRC.

[Samuel thibault (samuel-thibault)]

Mmm, ok, this can only happen when the ioctl handler is
hung_up_tty_ioctl, i.e. the tty got hung up after Xorg opened it, most
probably because with the parallel start in upstart the console may
get tinkered with after Xorg gets started. After an Xorg restart (or
equivalently, login/logout), no problem since no hung-up.

[Bryce Harrington (bryce)]

Try this out:

https://edge.launchpad.net/~bryceharrington/+archive/yellow

[Tom Jaeger (thjaeger)]

Samuel thibault wrote:
> Could people getting the error check /proc/`pidof X`/status? Here I
> have
>
> SigIgn: 0000000010301000
>
> The important part is the 3. If the 3 is not there it's normal that
> tcflush() return EIO for the console: because X starts its own session
> alone, it is an orphaned group.

SigIgn: 0000000000301000

It seems that I can reproduce the issue again, let me know if I should
run some more tests.

[Samuel thibault (samuel-thibault)]

Tom Jaeger, le Wed 07 Oct 2009 00:29:13 -0000, a écrit :
> Samuel thibault wrote:
> > Could people getting the error check /proc/`pidof X`/status? Here I
> > have
> >
> > SigIgn: 0000000010301000
> >
> > The important part is the 3. If the 3 is not there it's normal that
> > tcflush() return EIO for the console: because X starts its own session
> > alone, it is an orphaned group.
>
> SigIgn: 0000000000301000
>
> It seems that I can reproduce the issue again, let me know if I should
> run some more tests.

Ok, so the issue is really not tcflush() itself only, but a tty hungup,
with no other real solution than just making Xorg depend on the console
setup.

[Brian McGillion (brian-mcgillion)]

Ok this is by no means scientific and is far from technical but here are some findings.

Only got a new machine yesterday and installed the latest on it. I noticed that my new laptop was sluggish and unresponsive to the point of being unusable. Launched top to see 100% Xorg load. Found this bug on the top of a google search and tried the logout / login, switch VT's but nothing seemed to work, then the windows training kicked in if in trouble/doubt reboot :) It was then that I noticed that the install CD was in the drive. I removed it and choose to boot from the HDD. I have HDD encryption on the drive and I noticed the password prompt text was tiny, had not been that small last time I started the machine, the text on the pre-splash screen was also tiny. Logged in and opened xterm (saw that desktop effects were on, had not seen this before either). top showed Xorg load was 1 or 2 % launched firefox, Xorg load rose to ~9%.

Put the install cd back in rebooted, choose to boot from HDD, the HDD encryption password text was larger, opened xterm, Xorg load is 21->24% launch firefox and meltdown !! unresponsive !! when xterm finally shows up again 100% Xorg load. I then noticed that I can't remove the cd from the drive at all. As soon as I click restart and the screen goes black "* Will restart now" message is shown I can eject the cd.

I am using an Intel ThinkPad T500 standard model with Centrino 2 (all specs on line) if further hardware info is required.

This is reproducible 100% of the time.

[Bohrer (fjbohrer)]

Same problem here with a old Acer Aspire 3690

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

[Michael Lazarev (milaz)]

Same problem on ASUS M50VC with GeForce 9300M G Videocard.

[Данило Шеган (danilo)]

On уто, 2009-10-06 at 23:25 +0000, Bryce Harrington wrote:
> Try this out:
>
> https://edge.launchpad.net/~bryceharrington/+archive/yellow
>

I have rebooted once with the updated xorg-server from above PPA and it
seems to have helped.

[Martin Albisetti (beuno)]

Bryce's GDM fixes the issue for me as well.

[Samuel thibault (samuel-thibault)]

Bryce: please also add a dependency on the console configuration
scripts, as while waiting for acpi probably helps to wait for the
console configuration, it'd be better to really make sure gdm doesn't
start before it.

[Bryce Harrington (bryce)]

On Wed, Oct 07, 2009 at 09:56:10PM -0000, Martin Albisetti wrote:
> Bryce's GDM fixes the issue for me as well.

Could you clarify? The fix I posted was to xorg-server, not GDM. Are
you referring to that, or to the GDM changes proposed by someone else in
this thread?

Bryce

[Bryce Harrington (bryce)]

On Wed, Oct 07, 2009 at 10:13:20PM -0000, Samuel thibault wrote:
> Bryce: please also add a dependency on the console configuration
> scripts, as while waiting for acpi probably helps to wait for the
> console configuration, it'd be better to really make sure gdm doesn't
> start before it.

Hi Samuel, would mind proposing a patch? I'm a bit of a novice with
upstart scripting, and fairly distracted by mesa at the moment.

[Martin Albisetti (beuno)]

On Wed, Oct 7, 2009 at 7:21 PM, Bryce Harrington
<email address hidden> wrote:
> On Wed, Oct 07, 2009 at 09:56:10PM -0000, Martin Albisetti wrote:
>> Bryce's GDM fixes the issue for me as well.
>
> Could you clarify?  The fix I posted was to xorg-server, not GDM.  Are
> you referring to that, or to the GDM changes proposed by someone else in
> this thread?

Sorry, I meant xorg-server.

--
Martin

[Bryce Harrington (bryce)]

On Wed, Oct 07, 2009 at 01:01:57PM -0000, Michael Lazarev wrote:
> Same problem on ASUS M50VC with GeForce 9300M G Videocard.

It is not necessary for further confirmations on this bug.

If you do decide to add confirmations anyway, please at least attach
your Xorg.0.log from your failed session, the confirmations really
don't add any useful info to the discussion otherwise.

From this point on what we need to see is feedback on the various
proposed solutions. In particular I would appreciate it if people could
test the xserver patch I posted earlier to disable acpi entirely, so we
can get that option ruled in or out.

[Bryce Harrington (bryce)]

On Wed, Oct 07, 2009 at 01:03:46PM -0000, ???????????? ?????????? wrote:
> On ??????, 2009-10-06 at 23:25 +0000, Bryce Harrington wrote:
> > Try this out:
> >
> > https://edge.launchpad.net/~bryceharrington/+archive/yellow
> >
>
> I have rebooted once with the updated xorg-server from above PPA and it
> seems to have helped.

Thanks; could you be more specific? "seems to help" suggests that
there is still some uncertainty? Did some other issues crop up? Please
post your Xorg.0.log.

[Samuel thibault (samuel-thibault)]

Bryce Harrington, le Wed 07 Oct 2009 22:30:13 -0000, a écrit :
> On Wed, Oct 07, 2009 at 10:13:20PM -0000, Samuel thibault wrote:
> > Bryce: please also add a dependency on the console configuration
> > scripts, as while waiting for acpi probably helps to wait for the
> > console configuration, it'd be better to really make sure gdm doesn't
> > start before it.
>
> Hi Samuel, would mind proposing a patch? I'm a bit of a novice with
> upstart scripting, and fairly distracted by mesa at the moment.

It should just be a matter of adding keymaps.sh and console-setup to the
Should-Start field of the /etc/init.d/gdm,kdm,xdm scripts

[Bryce Harrington (bryce)]

On Wed, Oct 07, 2009 at 10:44:02PM -0000, Samuel thibault wrote:
> Bryce Harrington, le Wed 07 Oct 2009 22:30:13 -0000, a ??crit :
> > On Wed, Oct 07, 2009 at 10:13:20PM -0000, Samuel thibault wrote:
> > > Bryce: please also add a dependency on the console configuration
> > > scripts, as while waiting for acpi probably helps to wait for the
> > > console configuration, it'd be better to really make sure gdm doesn't
> > > start before it.
> >
> > Hi Samuel, would mind proposing a patch? I'm a bit of a novice with
> > upstart scripting, and fairly distracted by mesa at the moment.
>
> It should just be a matter of adding keymaps.sh and console-setup to the
> Should-Start field of the /etc/init.d/gdm,kdm,xdm scripts

That sounds like it's getting a bit out of the scope of this bug
report.

[Tom Jaeger (thjaeger)]

Bryce Harrington wrote:
> On Wed, Oct 07, 2009 at 09:56:10PM -0000, Martin Albisetti wrote:
>> Bryce's GDM fixes the issue for me as well.

I'm still seeing the issue after disabling ACPI in the X server. The
only thing it does is get rid of the warning in xorg.conf, since the
acpi initialization code failed before anyway.

The tricky thing about those Intel SSDs is that, after installing new
packages, they seem to take some time to reorganize before their
performance bounces back to normal.

[Samuel thibault (samuel-thibault)]

Bryce Harrington, le Wed 07 Oct 2009 23:31:46 -0000, a écrit :
> On Wed, Oct 07, 2009 at 10:44:02PM -0000, Samuel thibault wrote:
> > Bryce Harrington, le Wed 07 Oct 2009 22:30:13 -0000, a ??crit :
> > > On Wed, Oct 07, 2009 at 10:13:20PM -0000, Samuel thibault wrote:
> > > > Bryce: please also add a dependency on the console configuration
> > > > scripts, as while waiting for acpi probably helps to wait for the
> > > > console configuration, it'd be better to really make sure gdm doesn't
> > > > start before it.
> > >
> > > Hi Samuel, would mind proposing a patch? I'm a bit of a novice with
> > > upstart scripting, and fairly distracted by mesa at the moment.
> >
> > It should just be a matter of adding keymaps.sh and console-setup to the
> > Should-Start field of the /etc/init.d/gdm,kdm,xdm scripts
>
> That sounds like it's getting a bit out of the scope of this bug
> report.

? It's precisely in scope: as I said, Xorg gets EIO because the tty gets
a hung up after Xorg is started, most probably because the console
initialization scripts may get started after Xorg is started.

[Kaarel Saal (kaarel-saal)]

Thought I'd give my input. I have a five year old laptop with intel graphics. On Monday October 5th (...to be fair I believe it was this Monday) I made the brave move to upgrade from 9.04 to 9.10 beta. Things worked fine. It was after one of the later updates from the default repositories when I started experiencing the 100% CPU load issue described here. I also noticed when before the said update the text size of the log messages during boot were fairly small then after the update the text was much bigger. In case this is relevant at all.

Anyways logout/login does not work for me and neither does https://edge.launchpad.net/~bryceharrington/+archive/yellow

Hope this helps.

Kaarel

[Bryce Harrington (bryce)]

On Wed, Oct 07, 2009 at 11:46:20PM -0000, Samuel thibault wrote:
> Bryce Harrington, le Wed 07 Oct 2009 23:31:46 -0000, a ??crit :
> > On Wed, Oct 07, 2009 at 10:44:02PM -0000, Samuel thibault wrote:
> > > Bryce Harrington, le Wed 07 Oct 2009 22:30:13 -0000, a ??crit :
> > > > On Wed, Oct 07, 2009 at 10:13:20PM -0000, Samuel thibault wrote:
> > > > Hi Samuel, would mind proposing a patch? I'm a bit of a novice with
> > > > upstart scripting, and fairly distracted by mesa at the moment.
> > >
> > > It should just be a matter of adding keymaps.sh and console-setup to the
> > > Should-Start field of the /etc/init.d/gdm,kdm,xdm scripts
> >
> > That sounds like it's getting a bit out of the scope of this bug
> > report.
>
> ? It's precisely in scope: as I said, Xorg gets EIO because the tty gets
> a hung up after Xorg is started, most probably because the console
> initialization scripts may get started after Xorg is started.

No, patching gdm and kdm is well outside the scope of xorg-server, which
is what this bug is filed against. If you believe this to be the only
way to solve it, the bug should be refiled against those packages.

[Samuel thibault (samuel-thibault)]

Bryce Harrington, le Thu 08 Oct 2009 00:39:09 -0000, a écrit :
> On Wed, Oct 07, 2009 at 11:46:20PM -0000, Samuel thibault wrote:
> > Bryce Harrington, le Wed 07 Oct 2009 23:31:46 -0000, a ??crit :
> > > On Wed, Oct 07, 2009 at 10:44:02PM -0000, Samuel thibault wrote:
> > > > Bryce Harrington, le Wed 07 Oct 2009 22:30:13 -0000, a ??crit :
> > > > > On Wed, Oct 07, 2009 at 10:13:20PM -0000, Samuel thibault wrote:
> > > > > Hi Samuel, would mind proposing a patch? I'm a bit of a novice with
> > > > > upstart scripting, and fairly distracted by mesa at the moment.
> > > >
> > > > It should just be a matter of adding keymaps.sh and console-setup to the
> > > > Should-Start field of the /etc/init.d/gdm,kdm,xdm scripts
> > >
> > > That sounds like it's getting a bit out of the scope of this bug
> > > report.
> >
> > ? It's precisely in scope: as I said, Xorg gets EIO because the tty gets
> > a hung up after Xorg is started, most probably because the console
> > initialization scripts may get started after Xorg is started.
>
> No, patching gdm and kdm is well outside the scope of xorg-server, which
> is what this bug is filed against. If you believe this to be the only
> way to solve it, the bug should be refiled against those packages.

Yes I do, see my comments: I believe Xorg just gets started too early,
before the console is setup, and that's gdm/xdm/kdm's responsibility.

[Martin Pitt (pitti)]

Reassigning to gdm for now, thanks Samuel for the analysis!

Scott, can upstart scripts depend on init script? console-setup is currently an init.d script, and gdm's upstart script just triggers on "filesystem" and "hal", but not "console-setup" (or "keyboard-setup"). Would it work to emit a "console-setup-done" signal in the init.d scripts and have xorg wait on that?

[Scott James Remnant (Canonical) (canonical-scott)]

X does not need a dependency on console-setup, this is a red herring

[Martin Pitt (pitti)]

So Scott says that something in the boot process steals vt7 (where X.org starts up). /etc/init.d/console-setup does not touch vt7, so that's not it. So we need to find what it is.

Do all of the reporters have cryptsetup installed? If you don't need it for encrypted hard disk partitions, could you uninstall it and see if you can still reproduce this? Does any of the reporters have this problem but does not have had cryptsetup installed in the first place?

[Marc Deslauriers (mdeslaur)]

I use cryptsetup and have an encrypted swap file.

[Martin Albisetti (beuno)]

On Thu, Oct 8, 2009 at 7:35 AM, Martin Pitt <email address hidden> wrote:
> Do all of the reporters have cryptsetup installed? If you don't need it
> for encrypted hard disk partitions, could you uninstall it and see if
> you can still reproduce this? Does any of the reporters have this
> problem but does not have had cryptsetup installed in the first place?

I have cryptsetup.

--
Martin

[Marien Zwart (marienz)]

I use cryptsetup to encrypt my swap file. I can try disabling that, but I'm not hitting this bug consistently (I haven't hit it across the last couple of reboots) so I'm not the most useful tester for this.

[Thierry Carrez (ttx)]

I hit that bug and use cryptsetup to encrypt disk partitions and swapfile.

[Tom Jaeger (thjaeger)]

Martin Pitt wrote:
> So Scott says that something in the boot process steals vt7 (where X.org
> starts up). /etc/init.d/console-setup does not touch vt7, so that's not
> it. So we need to find what it is.
>
> Do all of the reporters have cryptsetup installed? If you don't need it
> for encrypted hard disk partitions, could you uninstall it and see if
> you can still reproduce this? Does any of the reporters have this
> problem but does not have had cryptsetup installed in the first place?

Since uninstalling cryptsetup, I haven't been able to reproduce this
problem.

[Pauli Virtanen (pauli-virtanen)]

I had cryptsetup installed, but no encrypted disks or swap. Removed cryptsetup, and now the problem has not surfaced in two boots.

[Bryce Harrington (bryce)]

[Sounds like pitti has found the source of the problem, doesn't seem to be an X bug.]

[Rick Spencer (rick-rickspencer3)]

Ok, but this bug needs to stay assigned to someone responsible for resolving it quickly. Assigning to foundations team. Please reassign if this is not the right assignee. Thanks.

[Kaarel Saal (kaarel-saal)]

apt-get purge cryptsetup
restart
no change

remove https://edge.launchpad.net/~bryceharrington/+archive/yellow from sources
apt-get update
apt-get upgrade (installed a bunch of packages and reconfigured a bunch of stuff)
restart
all systems seem to be back to normal

[Robbie Williamson (robbiew)]

Scott, could this be related to some of the recent changes made to cryptsetup for upstart compatibilty?

[Joao Teixeira (joaomrt)]

This problem of 100% CPU usage from Xorg occurs while I'm running Ubuntu 9.10 beta on a live session from a USB pen in a laptop without any encryption.
Does karmic come with cryptsetup starting by default?
Sorry in advance for the noob question.

[Steve Langasek (vorlon)]

My understanding is that this is a problem in usplash which is started when cryptsetup is installed, not a problem in cryptsetup?

[Robbie Williamson (robbiew)]

Assigning to Canonical Foundations, with Colin Watson looking into the cryptsetup.

[chrigu (ch-ba)]

LiveUSB (persistent) 9 oct. 6:30 UT. Boot -> Uninstall cryptsetup -> reboot

[Marc Deslauriers (mdeslaur)]

Today's updates seemed to have resolved this for me.

[Steve Langasek (vorlon)]

Seeing how cryptsetup wasn't updated and usplash was, sounds like this was indeed fixed in usplash, then. :) Marking as fixed; if anyone is still seeing this with usplash 0.5.41, please reopen (and yell).

[Tom Jaeger (thjaeger)]

I can still reproduce the issue after the latest updates.

Steve Langasek wrote:
> Seeing how cryptsetup wasn't updated and usplash was, sounds like this
> was indeed fixed in usplash, then. :) Marking as fixed; if anyone is
> still seeing this with usplash 0.5.41, please reopen (and yell).

[Steve Langasek (vorlon)]

(re-closing the cryptsetup task, this is an Ubuntu-specific bug so there's no reason to have an upstream task open)

[Tom Jaeger (thjaeger)]

Sorry, I didn't realize this was an upstream task.

The last thing I noticed before my shiny new SSD died a horrible death
today was that the problem would go away if I commented out the line
"console owner" in /etc/init/cryptdisks-enable.conf.

Steve Langasek wrote:
> (re-closing the cryptsetup task, this is an Ubuntu-specific bug so
> there's no reason to have an upstream task open)
>
> ** Changed in: cryptsetup
> Status: Confirmed => Invalid
>

[Scott James Remnant (Canonical) (canonical-scott)]

On Sat, 2009-10-10 at 04:58 +0000, Tom Jaeger wrote:

> The last thing I noticed before my shiny new SSD died a horrible death
> today was that the problem would go away if I commented out the line
> "console owner" in /etc/init/cryptdisks-enable.conf.
>
That precisely fits the problem definition.

"console owner" while X is running while forcibly take the ownership of
tty7 away from X. It doesn't like that so much (cf. this bug)

Scott
--
Scott James Remnant
<email address hidden>

[Joao Teixeira (joaomrt)]

Thanks for the tip, I've just also commented out "console owner" in cryptdisks-enable.conf and for the first time my 9.10 beta managed a clean boot with xorg working at a nice 2% max CPU usage.
Updating usplash and some xorg, ati-radeon drivers a couple of hours ago (10-Oct) didn't solve the problem. Neither apt-get removing crypsetup... what a mess.

I was wondering if anyone lacks this problem without tweaking their system or is it a generalized situation.
Thanks again.

[Cybjit (cybjit)]

I have had seen 100% CPU from X on some logins.
Now I tried commenting "console owner" and rebooted, and CPU is back to normal, hopefully for good.

[Tom Jaeger (thjaeger)]

Scott James Remnant wrote:
> That precisely fits the problem definition.
>
> "console owner" while X is running while forcibly take the ownership of
> tty7 away from X. It doesn't like that so much (cf. this bug)
>
> Scott

So this is essentially bug #60487 (!). Any thoughts on a solution? X
really needs its console fd.

[Samuel thibault (samuel-thibault)]

Tom Jaeger, le Sun 11 Oct 2009 03:39:24 -0000, a écrit :
> Scott James Remnant wrote:
> > That precisely fits the problem definition.
> >
> > "console owner" while X is running while forcibly take the ownership of
> > tty7 away from X. It doesn't like that so much (cf. this bug)
>
> So this is essentially bug #60487 (!). Any thoughts on a solution? X
> really needs its console fd.

I don't know cryptsetup and slash, but can't Xorg just wait for the
termination of that?

Samuel

[David Norman (deekayen)]

I confirmed the console owner change in #91 makes Xorg stop consuming an entire CPU.

[Steve Langasek (vorlon)]

On Sun, Oct 11, 2009 at 07:37:09AM -0000, Samuel thibault wrote:
> I don't know cryptsetup and slash, but can't Xorg just wait for the
> termination of that?

The problem is that cryptsetup isn't guaranteed to be installed, and upstart
doesn't give a straightforward way for gdm to wait on cryptsetup if it's
installed but ignore it otherwise.

Scott, do you have any thoughts on how to fix this, given that cryptsetup
does need to be able to prompt? Should we assume that any disks that
cryptsetup hasn't had a chance to set up by the time the DM starts aren't
going to be set up at the console anyway, and leave it to users to set them
up by hand...? (cryptdisks-enable -> stop on starting-dm)

I wonder if there's a bug in the cryptsetup job anyway, that it's running so
late for people. Is it likely/plausible that gdm is going to be started
before the udevtrigger job has stopped?

--
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>

[Samuel thibault (samuel-thibault)]

Steve Langasek, le Sun 11 Oct 2009 08:46:37 -0000, a écrit :
> On Sun, Oct 11, 2009 at 07:37:09AM -0000, Samuel thibault wrote:
> > I don't know cryptsetup and slash, but can't Xorg just wait for the
> > termination of that?
>
> The problem is that cryptsetup isn't guaranteed to be installed, and upstart
> doesn't give a straightforward way for gdm to wait on cryptsetup if it's
> installed but ignore it otherwise.

?! I'm surprised because insserv does support that easily and it's very
much used in Debian.

Samuel

[Tom Jaeger (thjaeger)]

Does upstart ensure that only one 'console owner' job can run at the same time? I assume it would also be a problem if one 'console owner' job took away the console from another one. In this case, couldn't we just make gdm/kdm 'console owner' jobs as well?

[maxstirner (philipp-d)]

Is there a workaround? I get this on every single boot and it's really annoying..

[Mikael Frykholm (mikael)]

#92 fixed it for me as well.

[Scott James Remnant (Canonical) (canonical-scott)]

On Sun, 2009-10-11 at 03:39 +0000, Tom Jaeger wrote:

> Scott James Remnant wrote:
> > That precisely fits the problem definition.
> >
> > "console owner" while X is running while forcibly take the ownership of
> > tty7 away from X. It doesn't like that so much (cf. this bug)
> >
> > Scott
>
> So this is essentially bug #60487 (!). Any thoughts on a solution? X
> really needs its console fd.
>
Yup! :-)

All the best bugs are old ones.

Scott
--
Scott James Remnant
<email address hidden>

[Scott James Remnant (Canonical) (canonical-scott)]

On Sun, 2009-10-11 at 14:49 +0000, Tom Jaeger wrote:

> Does upstart ensure that only one 'console owner' job can run at the
> same time? I assume it would also be a problem if one 'console owner'
> job took away the console from another one. In this case, couldn't we
> just make gdm/kdm 'console owner' jobs as well?
>
gdm isn't "console owner" though ;-) in fact, it can't be because the X
job it creates has to be the console owner - and you'd cause the same
bug with gdm/X that you have with cryptsetup/X now

Scott
--
Scott James Remnant
<email address hidden>

[Samuel thibault (samuel-thibault)]

Scott James Remnant, le Mon 12 Oct 2009 12:38:20 -0000, a écrit :
> On Sun, 2009-10-11 at 14:49 +0000, Tom Jaeger wrote:
>
> > Does upstart ensure that only one 'console owner' job can run at the
> > same time? I assume it would also be a problem if one 'console owner'
> > job took away the console from another one. In this case, couldn't we
> > just make gdm/kdm 'console owner' jobs as well?
>
> gdm isn't "console owner" though ;-) in fact, it can't be because the X
> job it creates has to be the console owner - and you'd cause the same
> bug with gdm/X that you have with cryptsetup/X now

Mmm, except that gdm keeps the console open throughout its execution,
doesn't it? In such case there wouldn't be any hangup.

Samuel

[Scott James Remnant (Canonical) (canonical-scott)]

On Mon, 2009-10-12 at 12:49 +0000, Samuel thibault wrote:

> Scott James Remnant, le Mon 12 Oct 2009 12:38:20 -0000, a écrit :
> > On Sun, 2009-10-11 at 14:49 +0000, Tom Jaeger wrote:
> >
> > > Does upstart ensure that only one 'console owner' job can run at the
> > > same time? I assume it would also be a problem if one 'console owner'
> > > job took away the console from another one. In this case, couldn't we
> > > just make gdm/kdm 'console owner' jobs as well?
> >
> > gdm isn't "console owner" though ;-) in fact, it can't be because the X
> > job it creates has to be the console owner - and you'd cause the same
> > bug with gdm/X that you have with cryptsetup/X now
>
> Mmm, except that gdm keeps the console open throughout its execution,
> doesn't it? In such case there wouldn't be any hangup.
>
gdm would get the hangup

The whole "ownership of the console" thing is really a Linux bug,
because X is never the owner of /dev/console - it's the owner
of /dev/tty7

You could start a "console owner" job on a different tty, but then when
you switched back to VT7, X would get then hangup again.

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

Scott
--
Scott James Remnant
<email address hidden>

[Marc Deslauriers (mdeslaur)]

I spoke too soon, I still have this issue.

[I'M YourOnly.One 🔏 (techmagus)]

Hmm. just to add if it will help any..

Still happening to me. My setup:
1) Dual-boot with BIOS HDD primary as SATA 160GB = WinXP and Fresh install of Karmic (via LiveCD)
2) Upon first login xorg goes 100% or 101% and eats up my CPU2.
3) Karmic detects my HDDrives based on the cable and not via my BIOS setup, which doesn't happen pre-Karmic (if this will help)
4) My 2nd HDD is a PATA 80GB drive
5) GFX Card: nVIDIA 7300LE
6) GFX Driver: 185
7) Processor: Intel Core2Duo

(Temporary) solution that works for me: Relog-in every (re)-boot.

Latest xorg CPU eat-up - today, Oct 13th (with system updated).

[chrigu (ch-ba)]

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

[Scott James Remnant (Canonical) (canonical-scott)]

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>

[Tom Jaeger (thjaeger)]

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

[Steve Langasek (vorlon)]

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>

[Colin Watson (cjwatson)]

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.

[Askalaral (askalaral)]

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.

[Tom Jaeger (thjaeger)]

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.

[Steve Langasek (vorlon)]

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.

[Askalaral (askalaral)]

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?

[Samuel thibault (samuel-thibault)]

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.

[Steve Langasek (vorlon)]

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>

[Steve Langasek (vorlon)]

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>

[Samuel thibault (samuel-thibault)]

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.

[Tom Jaeger (thjaeger)]

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...

[Launchpad Janitor (janitor)]

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

[Kwinz (ldm)]

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.

[Kwinz (ldm)]

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.

[Kwinz (ldm)]

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

[Kwinz (ldm)]

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.

[manolo (mac-man2005)]

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

[Wolfgang Kufner (wolfgangkufner)]

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 :-)

[Ride (acpride)]

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?

[Tom Jaeger (thjaeger)]

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?
>

[manolo (mac-man2005)]

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

[manolo (mac-man2005)]

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:~$

[Tom Jaeger (thjaeger)]

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.

[Ride (acpride)]

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?

[Tom Jaeger (thjaeger)]

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.

[manolo (mac-man2005)]

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.

[Tom Jaeger (thjaeger)]

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.

[manolo (mac-man2005)]

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.

[Brian Takita (brian-takita)]

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

[manolo (mac-man2005)]

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.

[Brian Takita (brian-takita)]

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

[Brian Takita (brian-takita)]

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.

[Brian Takita (brian-takita)]

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.

[Miguel (muchochini)]

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

[Pauli Virtanen (pauli-virtanen)]

@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.

[Miguel (muchochini)]

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

Thanks Pauli

[Brian Candler (b-candler)]

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