Xorg process freezes, uses 100% of CPU. Can be killed by remote terminal.

Bug #51991 reported by phillywize
56
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux-restricted-modules-2.6.15 (Ubuntu)
Invalid
Medium
Unassigned

Bug Description

I am running Dapper on a Dell Inspiron 8200 with an Nvidia GE Force 2 graphics card, and using the nvidia driver. The system will lock randomly -- anywhere from one or twice a week to once or twice a day.

When it locks, the following happens:

- the Xorg process uses 100% of the cpu;
- the mouse pointer still operates
- nothing else in that session works -- no keyboard, no clicking, nothing.
- machine is still accessible remotely. I can log in using, e.g., ssh or even nx
- when I log in remotely, I can kill the xorg process, and regain control of the machine. I can log back in, and everything works fine
- the logs don't seem to tell me what happened.

There is a discussion of this in the forums here:

http://www.ubuntuforum.org/showthread.php?t=193283&highlight=xorg+freezes

Revision history for this message
Eric Musgrove (voiddesign) wrote :

I experience what I believe to be the same, however mine is characterized by a complete and total lock of the system. Mouse and Keyboard are not responsive, Xorg completely locks up. I cannot switch to another terminal, so I have no way of knowing what the actual CPU usage is. It seems to occur, however, whenever I have FireFox open.

Using 6.06, with a Nvidia Card, and a K7 kernel.

Revision history for this message
ketsugi (spamtastic) wrote :

I'm experiencing a similar problem (see this thread: http://www.ubuntuforums.org/showthread.php?t=193283) wherein after anything between 30 mins and 2 hours of using Ubuntu Dapper, Xorg's CPU usage will increase and hit 100%, whereupon the only thing I can do reliably is to hit Ctrl-Alt-Bksp and login again.

I've noticed that when using Xgl instead of Xorg, the same thing happens with the Xgl process.

I'm using the 2.6.15-25-686 kernel, with Nvidia drivers from repos.

Revision history for this message
Shane Par-Due (shanepardue) wrote :

same issue here. my problem didn't arise til i installed my nvidia video card. used a month before that with no problem.

dapper, recently installed nvidia, k7 kernel

Revision history for this message
phillywize (rmurken) wrote :

I should add to what I wrote in the original bug report that I am using the 686 kernel, 2.6.15-25, but I had the problem with prior kernels in 6.06. For me, ctrl-alt-backspace does nothing. The only way to get my computer back, that I have found, is to login remotely, find the xorg process at 100% CPU, and kill it. I don't know whether sound works.

Revision history for this message
William Coleman (william-inditecircle) wrote :

My wife's computer has the same problem. She is using the k7 kernel and nvidia driver from repos. Her computer started crashing randomly after updating to Dapper.

On her last crash, I logged on to her computer via ssh, ran 'top', 'xorg' was running at 99.9% of her cpu speed.

It has happed while running Firefox, Gimp, and serval other standerd apps.

Revision history for this message
IanC (icatton) wrote :

I have a Dell Inspriron 4100:
- PIII Mobile CPU 1.2GHz
- 640 MB RAM
- 30GB HDD
- ATI Mobility Radeon graphics card

The main difference is that my laptop hard locks i.e. I am unable to use the keyboard or the mouse. Ctrl-Alt-Bksp does not work, the only thing I can do reliably is is switch off the machine. Since I don't have a second machine, I am unable to test whether or not I can log in remotely.

This has happened most often while running Firefox, but has occurred with other apps as well.

Revision history for this message
James Jones (jamesjones01) wrote :

I have a homebrew system with

Sempron 2400+
512 MB RAM
160 GB hard drive
ECS KT600A motherboard

I had difficulties with the nVidia MX400 AGP graphics card I was using, and upgraded to an MX4000 card. (This was with Breezy Badger.) I then started to have the bug reported here: display locks, x.org uses 99+% of the CPU, keyboard unresponsive, the mouse cursor still moves, but the system can be accessed via ssh and x.org killed. Using the nv driver corrected the problem, but gave lousy graphics performance.

I switched to an ATI card, but couldn't get decent performance from it. I switched back to the MX400 card.

I now run Dapper Drake. I recalled that I have an MX4000 PCI card that I could try... and installed it and switched to it. I got glx to work...and boom. After a bit of trying out the GL screensavers to check that they were working nicely, I went on to do some other stuff and bang... the screen froze, but the mouse could still move. This time it was slightly different: after about five minutes or so delay, x.org finally paid attention to ctrl-alt-bs and restarted.

If you look on the nvidia Linux forum you will find that people have had this problem with the nvidia proprietary driver for YEARS. See http://www.nvnews.net/vbulletin/showthread.php?t=31858 and http://www.nvnews.net/vbulletin/showthread.php?t=73231 for more info.

I have another system with an Athlon 2100, and a K7S5A motherboard. I used the MX4000 card that made the KT600A system freeze...and had no trouble whatsoever. That system now runs Dapper Drake just fine. (OK, compiz dies on it, but compiz is still highly experimental. If I go back to metacity, all is well.)

Revision history for this message
phillywize (rmurken) wrote : xorg.conf

Here is the xorg.conf file I have been using; note, it has NVAGP enabled; I have since disabled it to see if that fixes the problem.

Revision history for this message
Marius B. Kotsbak (mariusko) wrote :

Same problem here. Seems to be triggered by firefox as the problem disappears if I am able to stop that (when the system is very little responsive because of all RAM used and using the swap heavy).

I have tried both "nv" and "nvidia" x server drivers...

I did not have any problems running xorg and firefox with debian unstable on the same box before, and it has 0.7 gb of ram.

Revision history for this message
Katherine Koba (kokoba) wrote :

Having a similar problem with Kubuntu: complete freeze-up and lack of response to mouse. Sometimes the keyboard still works and sometimes it doesn't. Doesn't seem to be a memory leak (looking at top doesn't reveal anything unsual). Only way to fix it seems to be to restart X and log back in.

Revision history for this message
Aurimas B (a-barcevicius) wrote :

I can confirm the original bug description, the symptoms are 100% the same. I have experienced it by using either Opera, Varicad or Yakuake.
System info: Kubuntu Dapper 6.06.1; KDE 3.5.3; 2.6.15-26-686; nvidia proprietary drivers.

Revision history for this message
fahad (fahad-ifthkar) wrote :

I have just installed xubuntu on my old laptop, I seem to be having a similar problem as the rest of you guys. My system starts to slow down and i am not sure why when I ran top, the Xorg process was eating wat to much cpu time. Slowly the cpu time got higher and higher until my machine was no longer useable.

I tried to track down the problem, the xubuntu installation did not recognise my laptops graphics card so I went through the process of manually putting in the correct video driver details.

I thought this would have solved the problem but no, for some reason, Xorg process just starts to eat cpu cycles until I cant use my system

Revision history for this message
alan53 (alan-binaryarts) wrote :

I too, have freezing problem. Completely un-responsive to all but a hard boot.

Dell Inspiron 640m Dual core centrino processors. 686 architecture. 1 gb ram 1 gb swap. I use vmware, but freeze occurs if running or not. Sound has been sporadic. All seems fine if I only use 1 workspace.

Alan53

Revision history for this message
grahams1 (gps1539) wrote :

Similar problem.

Freezing happens within minutes on a Compaq n610c laptop with an external monitor attached at high screen resolutions (1600x1200 external), (1450x1050 laptop LCD), while running firefox or Thunderbird. Lower either monitors resolution reduces the freezing rate, but does not stop it happening.

recently updated to 2.6.15-27-686 and the problem is noticably worse.

Revision history for this message
Peter Feger (peter-feger) wrote :

After doing an upgrade from 6.06 to 6.10 the system randomly locks up. I have made no changes to the system.

System Specs are

  CPU AMD Athlon XP
  Chipset nVidia nForce2 IGP [Crush 18G]
  nVidia MCP Super I/O
  ntegrated in Chipset
  Main Memory Dual Channel Mode (128 bit)
  DDR266
  DIMM Type : 1GB X 3 (3 Gigs RAM total installed)
  Integrated VGA Engine in chipset (Integrated Geforce4 MX Graphics)
 8X AGP slot (not in use)

1 Western digital 80 gig ATA Hard drive
1 Maxtor 80 Gig Hard Drive
1 Seagate 200G Hard Drive
1 DVD/CD Combo R/W drive

This is not a heat issue as each time the cpu temp is at a stable 104 f system temp 91 f

CPU fan speed at 4200 rpm
Nvidia fan speed ( yeah i added a fan) 4400 rmp
Case fan speed 4400 (2")

THe only way to gain control is to reboot the system. There is no patteren to this that I can tell. this will happen even if the machine is booted up and no other programs are run.

Any advice on this would be great guys.

Pete

Revision history for this message
wert613 (wert613) wrote :

I have this EXACT PROBLEM

i too have an

NVIDIA GeForce 2 Pro

my system periodically locks up with mouse movement but no responce from the keyboard or screen the only solution is a hard reboot.

i am eagerly waiting for a solution

thanks

wert613

Revision history for this message
Brett A. Taylor (realbt) wrote :

Same problem here.

NVIDIA GeForce 6200TC (PCI-e)
2.6.17-11-generic kernel on Edgy with all updates
nvidia binary drivers from Ubuntu repository

If I don't bang on the keyboard too much, I am usually able to alt-ctrl-f1 and kill Xorg that way, which is consuming 100% cpu time. I didn't have this problem until I upgraded my packages sometime in January. I suspect the previous version of xserver-xorg didn't have this issue. (Either that or am/was I extremely un/lucky.)

Frequency varies from once a week to three times in one day (today).

I am willing to help debugging or providing any information necessary to help with this problem.

Revision history for this message
LKRaider (paul-eipper) wrote :

I have the same problem, using nvidia-glx-legacy on two of my computers, both of which have a geforce 2 , one being a GTS Pro (Asus), the other one is a MX 400. I am using Dapper.

Whenever I use the nvidia driver with Xorg, I get lockups.

Note that this ONLY HAPPENS on Xorg. If I use XGL, the system remains perfectly stable.

----
/proc/driver/nvidia/version
NVRM version: NVIDIA Linux x86 NVIDIA Kernel Module 1.0-7174 Tue Mar 22 06:44:39 PST 2005
GCC version: gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)

Revision history for this message
Brad Peters (thefubar) wrote :

Unfortunately this is happening on Feisty as well to me. I'm using the latest Nvidia drivers with a GeForce 6800 PCI-express Nvidia card. System specs are below:

Intel Pentium D 830 (3.0gHz dual core)
2GB RAM
Nforce chipset

I experience the exact symptoms as above, at random times, using random applications. For example, last night's lockup occurred while I was surfing around using Firefox, while another one occurred while I was listening to tunes in Amarok. The Windows side of this box works fine. I'm thinking this may be a kernel / xorg issue as it's happened to me on other distributions with this box as well, so I don't think it's Ubuntu-specific.

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Brad:
What is the output of
lsmod | grep cpu
?

Revision history for this message
Brett A. Taylor (realbt) wrote :

I'm still having this problem with Feisty as well. I note that when I use Beryl with Xorg (using nvidia native rather than Xgl), Xorg runs stable without lockups previously seen.

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

If the output of
dmesg | tail
while this is happening contains NVRM: Xid messages there is a small chance you might be seeing Bug #109643

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

(the previous comment also only applies to people using Feisty)

Revision history for this message
Brett A. Taylor (realbt) wrote :

I ditched Beryl because it's a little too unstable for my liking at this time, especially with dual displays. Back to getting frequent hangs in X. I ran gdb and did a couple back traces:

(gdb) bt
#0 0x0809c8d4 in DeletePassiveGrabFromList ()
#1 0x08092cc5 in ProcUngrabButton ()
#2 0x08142531 in ?? ()
#3 0x0858c858 in ?? ()
#4 0x0858c858 in ?? ()
#5 0xbfa96808 in ?? ()
#6 0x081c7fa8 in ?? ()
#7 0x00000000 in ?? ()

(gdb) cont
(gdb) bt
#0 0x0809c428 in GrabMatchesSecond ()
#1 0x0809c5cc in AddPassiveGrabToList ()
#2 0x08092f5d in ProcGrabButton ()
#3 0x08142531 in ?? ()
#4 0x0858c858 in ?? ()
#5 0x0858c858 in ?? ()
#6 0xbfa96808 in ?? ()
#7 0x081c7fa8 in ?? ()
#8 0x00000000 in ?? ()

(gdb) cont
(gdb) bt
#0 0x0809c33e in ?? ()
#1 0x0809c522 in GrabMatchesSecond ()
#2 0x0809c5cc in AddPassiveGrabToList ()
#3 0x08092f5d in ProcGrabButton ()
#4 0x08142531 in ?? ()
#5 0x0858c858 in ?? ()
#6 0x0858c858 in ?? ()
#7 0xbfa96808 in ?? ()
#8 0x081c7fa8 in ?? ()
#9 0x00000000 in ?? ()

I did this many times, and each trace showed roughly one of the two above stacks.

This never happens when the system is in use. Occasionally, when I sit down at the system, the cpu is fluctuating in usage for no reason (I have a cpu monitor on my desktop so I notice this right away). For example, it will be constant 25%, 0%, 25%, 0%, etc. Once I start using the system, this behaviour usually goes away and X calms down and returns to normal with no noticeable usage. No freeze here.

The unrecoverable hanging usually occurs after I lock the system. In KDE, I have the habit of locking it whenever I leave the system for an extended period of time (don't ask me why). At this point, I have to switch to a terminal and kill X. I want to make it clear that this is not always the case -- sometimes the lockup occurs without the session locked when I've left the computer alone for a while (usually many hours).

The dmesg showed no signs of NVRM: Xid messages as suggested above when X is going crazy.

When it is frozen and X is eating the cpu, I can see all the windows I had running fine, but interestingly, none of them have any window decorations -- they're all gone. The mouse moves fine but I can't click on anything or use the keyboard, except to switch terminals.

Anything else I can try? I'm thinking about starting to look at ATI cards as this is awfully annoying.

Revision history for this message
Brad Peters (thefubar) wrote :

Hi Sitsofe,

Sorry it's been a bit since I've responded. I'm not in front of that machine right now to provide you withe the info you want, but I have a copy of the nvidia-bug-report.log file which may contain what you are looking for. I checked into the other bug you mentioned and went a step further and uninstalled powernowd, however, I still get the random lockups. Nvidia themselves aren't much help; I need to follow up with them. I'll post the other info you've asked about when I get back in front of that machine.

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Brad:
You're getting NVRM: XId messages according to your nvidia-bug-report. These happen for a variety of reasons (sharing interrupts with other devices, hardware conflicts, driver bugs...) that the NVIDIA folks are better placed to talk to you about...

Revision history for this message
nukedathlonman (areginato) wrote :

Same issue here - Acer Aspire 5002WLMi notebook with (really crappy) SiS video adapter. If I let the laptop idle for 30 minutes then Xorg starts eating CPU cycles and maxes out the CPU. If left maxed more then 15 minutes, the only recovery is to kill the X.org process from another terminal (X.org will take down the whole system if I try anything else). This problem did not exist with Drapper or Edgy, and I've been studying this phenomenon since upgrading to Feisty. As long as the computer is in use it fine however (thankfully so). The problem also does not exist on my desktop. I've been through all the system logs (no error messages to trace), so I then disabled all screen savers, and disabled all device drivers I could in xorg.conf - nothing seems to work outside leaving the notebook in a terminal with a sudo'd top so that I can kill xorg.

Revision history for this message
nukedathlonman (areginato) wrote :

Did some more investigating, it appears that I'm experiencing bug 109507, not this bug - my bad. I unloaded superkaramba and the problem has completely disappeared.

Revision history for this message
Brett A. Taylor (realbt) wrote :

This is crazy. After unloading SuperKaramba, my problem has also gone away. I guess bug 109507 is the key. At least I have a work-around for the time being with that bug...

Thanks for updating this bug with the details. I bet there are a lot of people suffering from this not realising the relationship between the problem and SuperKaramba.

Revision history for this message
Sandwich (sandwich) wrote :

I am using gnome and the fglrx driver, and experience an identical lock up. Xorg gradually consumes more and more cpu and memory until eventually I have a locked up machine that I must ssh to and kill X to restore it. People in the gentoo forums had originally suspected superkaramba, and several even said that it fixed their Xorg memory leaking/freezing only to renig and repost saying it is still a problem and disabling superkaramba merely slowed it.

Revision history for this message
Patrick Salami (pat-entitycom) wrote :

this problem seems to be identical to bug 120347.

I'm running Kubuntu Feisty and I have an nvidia geforce 6200. I encounter the exact same problem: after leaving the computer running over night, I come back and xorg is at 100% (on one of my CPUs) and the window decorations have disappeared. Since I have a dual CPU system, my guess is that it is more tolerant towards this, so although X is completely frozen (only the mouse moves), I can ctrl+alt+F1 to a console and take down the system cleanly. (however, if I switch back to the X server before rebooting, the window decorations are gone)

After a reboot everything is fine. I also ran strace on xorg when it goes berserk, but the only thing that was noteworthy that I came up with was also the SIGALRT message. Comparing it to an strace of xorg in normal conditions (when it's not going berserk), however, revealed that the SIGALRT message also comes up during normal operation, and neither that nor any other calls that xorg makes while it's berserk indicate anything out of the ordinary.

Further, I have taken advantage of the dual CPUs to examine all logs in detail as the problem occurs: nothing out of the ordinary, in fact, since the system has been sitting idle, hardly any activity is logged. I checked the KDE settings and they are showing the screen saver to be off. I do have kpowermanager installed (because I had a problem where my network card would stop working after a while otherwise), but it's set to "Performance" and the screen saver, auto-suspend for the screen, and in fact all other power-saving options are unchecked. My screens do turn blank, however, after a period of inactivity, so it's possible that this is related.
On a side note, I have three monitors on two nvidia cards, running on xinerama with the 9755 nvidia binary drivers. All signs point to this not being a driver problem, however, unless nvidia and intel use some of the same libraries in their drivers.

I also wanted to point out that I usually don't lock my screen when I leave, so that might not be relevant to this particular problem.

In addition, my GLX does not work for some reason. Whenever I try to run a glx-enabled app, the app crashes, although it is installed, because the glxinfo command outputs a grid with the glx info.

I haven't tried disabling superkaramba yet, instead I've been investigating the possible role that power management might play. If no other fix is offered, however, I will try disabling superkaramba and see if the problem recurs.

Revision history for this message
Brad Peters (thefubar) wrote :

I've noted in Gutsy Tribe 4 (and now 5) that I have not had a single lockup in any situation where I normally had a lockup. I think this is most likely due to the newer version of Xorg being used. If any of you have the spare space, I'd try testing out Gutsy and see how your results are, or at least upgrade when the actual release hits. It's very possible this might be solved.

Revision history for this message
pierpytom (pierpaolo-tommasi) wrote :

Some problem but with compiz! Mouse still move but keyboard, click, killing xorg, ctrl+alt+Fx, etc... doesn't work! The only way is hard boot!
My configuration:
   Ubuntu 7.04
   kernel 2.6.20-16-generic
   ati x700 with driver open
   compiz-fusion 0.5.2
It seems to happen after 5 minutes with firefox opened with a flash video inside!

Revision history for this message
Breuil Cyril (cyrilb856) wrote :

i got exactly the same problem on kubuntu.
I had the same problem on my old computer and now i got a new computer with a totally different hardware, a fresh installation and it does the same thing.
I can tell that it only happens when i don't use the computer during some time (at least one hour).
My old configuration :
Pentium 4
Motherboard MSI 865 PE neo2
graphic card ati radeon 9600

My new configuration :
intel core 2 duo
Motherboard MSI P35 neo
graphic card nvidia 8600

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

Is this issue still occurring on Gutsy-final for anyone?

For those able to reproduce this problem on Feisty, could you follow the steps on https://wiki.ubuntu.com/DebuggingXorg to try getting some gdb information about what Xorg is doing at the time of the 100% usage? Perhaps Xorg is stuck in a loop, which could be made evident by stepping through the code for a bit and see how it's looping. Sending the Xorg process a `sudo kill -5` might also be of interest.

Also, Eric says he is seeing this only when he has Firefox open - can anyone confirm having this issue when Firefox was *not* running?

On bug 104481, it said the issue was particularly noticeable for websites like http://derstandard.at/ and http://www.blogger.com, which use javascript to do dynamic image stuff. Can anyone else who is seeing this 100% cpu issue confirm this?

Changed in xorg:
assignee: nobody → bryceharrington
importance: Undecided → Critical
Revision history for this message
Bryce Harrington (bryce) wrote :

Also, I've heard of a vaguely similar bug that went away after rotating the screen 90 degrees via `xrandr -o right`.

Could someone who is able to reproduce this issue try rotating the screen and see if it behaves itself better?
(Yes, I know this is a long shot, but if it's not too much trouble, it could help eliminate this possibility...)

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

Another thing to check - according to comments on http://ubuntuforums.org/showthread.php?t=193283&highlight=xorg+freezes, it sounds like the issue correlates with having swap turned off. Can those who experience this issue indicate if swap is on? `swapon -s`

Revision history for this message
Matt (mmmurf) wrote : Re: [Bug 51991] Re: Xorg process freezes, uses 100% of CPU. Can be killed by remote terminal.

Swap is on on my system and the problem still occurs.

I have been travelling and have not been able to have the time to do
the debugging steps (having only one computer with me) but I will do
so as soon as possible once I return (next week)...

On 10/24/07, Bryce Harrington <email address hidden> wrote:
> Another thing to check - according to comments on
> http://ubuntuforums.org/showthread.php?t=193283&highlight=xorg+freezes,
> it sounds like the issue correlates with having swap turned off. Can
> those who experience this issue indicate if swap is on? `swapon -s`
>
> --
> Xorg process freezes, uses 100% of CPU. Can be killed by remote terminal.
> https://bugs.launchpad.net/bugs/51991
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Revision history for this message
PeterK (p-koek2) wrote :

I was searching the web to get an clue what was happening and I found this website.

I have exactly the same problem, Xorg takes 100% CPU time, and system is not responding to keyboard or mouse (mouse is however visible).
With ssh I can login into the system and kill Xorg, after this I get a login screen, and all is normal again.

The fun part is that I don't have Ubuntu, but I am using Fedora 7. Therefore it is not distro related.

I have Fedora 7 with Nvidia drivers, Superkaramba, and Kpowersave.

Revision history for this message
Pierpaolo Follia (pfollia) wrote :

It seems a Superkaramba related problem. Try disabling it.

Regards,
Pierpaolo

On 10/26/07, PeterK <email address hidden> wrote:
> I was searching the web to get an clue what was happening and I found
> this website.
>
> I have exactly the same problem, Xorg takes 100% CPU time, and system is not responding to keyboard or mouse (mouse is however visible).
> With ssh I can login into the system and kill Xorg, after this I get a login screen, and all is normal again.
>
> The fun part is that I don't have Ubuntu, but I am using Fedora 7.
> Therefore it is not distro related.
>
> I have Fedora 7 with Nvidia drivers, Superkaramba, and Kpowersave.
>
> --
> Xorg process freezes, uses 100% of CPU. Can be killed by remote terminal.
> https://bugs.launchpad.net/bugs/51991
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Pierpaolo Follia
http://madchicken.altervista.org/tech

Revision history for this message
Pierpaolo Follia (pfollia) wrote :

It seems a Superkaramba related problem (see comment 30). Try disabling it.

Revision history for this message
icechen1 (houyuchen66) wrote :

Same problem here with Gutsy but i can reboot by taping SYSRQ+ALT AND REISUB.
Gateway MX6214 with compiz-fusion enabled.

Revision history for this message
ser_bur (ser-bur) wrote :

After upgrade to Gutsy I am also experiensing this problem :(
I am using KDE (without Superkaramba) on Toshiba SA10 laptop (Intel 855 video). I have tried to disable screensaver, ACPI, etc, etc - no result, after some time (~30 min) Xorg freezes, music (Amarok) stops, Xorg is using 100% CPU, but system is available via SSH. Seems it is an Xorg bug...

Revision history for this message
Kat (atul-kamat-deactivatedaccount) wrote :

I have had this problem on fiesty as well as gutsy both clean install. No SuperKaramba. I have a Toshiba Satellite ProA120 (intel 945). To reproduce this buy

1. Open firefox
2. Select some text in the firefox window( with an http link) and click on the link and the system freezes.

you might want to do this 3-4 times.

Revision history for this message
Kat (atul-kamat-deactivatedaccount) wrote :

More info:

1. OS: Gutsy 7.10
uname -r
2.6.22-14-generic

2.

swapon -s
Filename Type Size Used Priority
/dev/sda3 partition 610460 15084 -1

2. The bug can be reproduced in Evince (Pdf reader) as well

3. gnome-screensaver uninstalled

4. powernowd uninstalled

Revision history for this message
Hani (hani17) wrote :

I have the same problem on my Dell Inspiron 5100, with ATI Radeon Mobility M7. The problem started after upgrading to Gutsy. I noticed that everyday around 10 mins after I turn on my laptop, the keyboard becomes unresponsive, the mouse cursor still moves, but the clicks do not register. CTRL+ALT+Backspace doesn't work either. I checked syslog for a pattern and I noticed that I always get the crash a few minutes after cron.daily is executed. I then ran the tasks in /etc/cron.daily one by one, and I realized that the process /etc/cron.daily/slocate is the culprit. It runs for a few mins then crashes the system as explained before. Is this considered the same bug, or should I file a new one. Can other users experiencing the crash try out the following command to confirm?:
sudo /etc/cron.daily/slocate

Revision history for this message
Hani (hani17) wrote :

I traced my problem to having bad sectors on an NTFS partition made slocate cause the total system freeze.
My problem went away after booting to XP and running chkdsk to fix the NTFS errors.
Another way to fix this is to add the NTFS mount path to the PRUNEPATH variable in /etc/updatedb.conf. This way slocate will never scan the NTFS folder.
This problem might not be what's causing all the freezes reported in this bug, but I thought I'd share my findings in case it helps someone in the same boat as I am.

Revision history for this message
ser_bur (ser-bur) wrote :

On my laptop slocate works without any freezes, and there is no Windows partitions at all :) So, this version is wrong for me... Laptop still freezes after ~20-30 min of idle state. But, it seems that it does not freeze without KDE running (only with KDM prompt), but I need to check this, and also check situation with another window managers (IceWM, for example).

Revision history for this message
ser_bur (ser-bur) wrote :

OK, let's go on with this little investigation :)
I've just discovered that Xorg freezes only with WM running - KDE, Gnome or IceWM in my case. If system stays with KDM prompt on the screen, nothing happens after 30 minutes, 1 hour and more. Really strange...

Revision history for this message
hyuned (info-ehab) wrote :

Excacly the same problem as Hani here. trying now to resolve it.

Revision history for this message
ser_bur (ser-bur) wrote :

I have found a temporary solution for my problem. I've noticed than Xorg does not freeze when running a fullscreen application like video player (in fullscreen mode), game, etc. So i just set up an OpenGL screensaver with 5 minutes delay, which prevents freezing. Actually, this is not a solution, but at least I do not worry about my data and my nerves :)

Revision history for this message
ser_bur (ser-bur) wrote :

It was an early celebration... Two times it did not freeze, but third it did... so, screensaver is not a solution too :(

Revision history for this message
Pierre Cassimans (cazzeml) wrote :

I had the same problems with xorg on XUBUNTU going to 100%. Yesterday i installed e17 as a window manager and today i didn't have 1 lockup. I don't know what xfce, gnome or kde does more with xorg then e17, but what they do more is the cause of the problem.

Revision history for this message
Pierre Cassimans (cazzeml) wrote :

Ok, if i put on power management, i have the problem too under e17. if i turn it off, all goes well. Can someone test it with some other Window manager?

Revision history for this message
Holger (hroesing) wrote :

Hi,

i'm experiencing the same problem: Xorg freezes after some time (might be about 30 mins, however i'm not sure), the keybord does not respond and even the mouse is completely frozen. I'm not sure about the remote access but the SYSRQ+ALT and REISUB shortcut works.

i'm using gutsy with gnome on my old acer travelmate (it's some 4000er model, but i forgot the exact name) with an ati mobility radeon 9700 graphics card (i'm using the open-source driver, not the proprietary one from ati)

i noticed that the error only occured after i turned on desktop effects. When i turn off all effects everything works absolutely fine and there's no freeze up at all. I didn't have much time to investigate into this direction, but maybe this can be a useful hint.

Regards,
Holger

Revision history for this message
ser_bur (ser-bur) wrote :

Holger, please try another window managers (especially lite ones, soch as IceWM, *box etc) - because in my case this problem appears with any of them, not only in KDE. Maybe these are two different bugs?... :(

Revision history for this message
Holger (hroesing) wrote :

i'm currently at work, but i can try another window manager as soon as i got home tonight.

anyway, can anybody else check whether the issue occures with enabled desktop effects only, or even when the effects are turned off?

Revision history for this message
Holger (hroesing) wrote :

alright, i shortly tested another window manager (xfce) yesterday evening. it seemed to work alright, at least it didn't freeze after one hour. however, i did not turn on desktop effects on this manager (stupid question: is xfce supporting compiz effects?)

after one hour i switched back to gnome...

Revision history for this message
ser_bur (ser-bur) wrote :

Holger, did you use your computer during that hour? Because, in my case, if I am performing any actions on desktop (at least moving mouse), there is no any problems, but if I leave laptop alone...

Revision history for this message
Holger (hroesing) wrote :

okay, i didn't use it extensively (except a bit web browsing, but not very much) during that hour and maybe the result got distorted... i can give it another shot tonight and tell you about the result afterwards.

Revision history for this message
Matt (mmmurf) wrote :

Just wanted to mention that I turned off desktop effects after reading
some messages about this ticket yesterday, and X did not lock up last
night at all. Typically it would lock up after 30 minutes or so. I'm
using the updated deb that was posted on this ticket.

On Nov 13, 2007 2:03 AM, Holger <email address hidden> wrote:
> okay, i didn't use it extensively (except a bit web browsing, but not
> very much) during that hour and maybe the result got distorted... i can
> give it another shot tonight and tell you about the result afterwards.
>
>
> --
> Xorg process freezes, uses 100% of CPU. Can be killed by remote terminal.
> https://bugs.launchpad.net/bugs/51991
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Revision history for this message
Holger (hroesing) wrote :

i gave the xfce another try last night and it worked fine for me (means it did not freeze or anything), although i worked with some programs during that time (firefox, eclipse, mplayer, etc). i did not turn on desktop effects in xfce since i actually don't know how to do that and i didn't have the time to read about it.

Revision history for this message
ser_bur (ser-bur) wrote :

Yesterday I also discovered that problem does not appear if I switch to another console (Ctrl+Alt+F1) before leaving computer idle.

Revision history for this message
bubbalouie (ryan-gossink) wrote :

I too have this problem, Xorg will sit at >80% after my media PC has been sitting idle for a while. I have noticed however that if the mouse is moved around a bit (and clicked), the system will recover, even if there was no response to the initial input.

All the same, if a machine is getting maxed out all night, that translates to a massive waste of energy.

It looks like a common factor is the machine sitting untouched, I know it sounds like a stretch, but does anyone know of a program or method to randomly generate a small mouse jitter (just a pixel or 2) every few minutes (it must look like real input to Xorg I think). I am happy to do this and log the Xorg usage over a day or two and see if it is a suitable 'work around' until the real issue is fixed. If anyone has some suggestions on how to generate the input please let me know.

My relevant (hopefully) sepcs Below:

 - Kubunutu
 - Celeron Pentium D (3ghz, underclocked to 2.3ghz)
 - 1gb RAM
 - Nvidia Geforce FX 5600
 - Logitech PS/2 Wireless mouse + keyboard

Revision history for this message
bubbalouie (ryan-gossink) wrote :

*Edit: if I SSH into the media PC and "killall superkaramba" Xorg drops back down to zero percent again.

In my case at least, this looks like a superkaramba bug :)

Revision history for this message
Breuil Cyril (cyrilb856) wrote :

oki maybe i've finally found a solution :
i've try to let my pc without aero aio working and now it works perfectly. If i launch it again Xorg start to stop working again. The most strange thing is that it aero aio was the only thing wich could respond (not every time) when it happend.
So to me it's solve by removing aero aio applet.

Revision history for this message
ser_bur (ser-bur) wrote :

Hey, sounds good, but what to do if I do not use neither Superkaramba nor Compiz? And, what applets should I disable in IceWM? ;)

Revision history for this message
Markus Schlager (m-slg) wrote :

The freeze after 30/60 minutes of inactivity might be a different problem, caused by the 'console-tools'-package. I ran into this problem with several multiseat-systems a year ago already. It turned out, that mouse and keyboard were still active, only the monitor wouldn't wake up again. You just have to work blindly - for example you're still able to log out as long as you know the keyboard-shortcuts to do so.

Our solution is the following:

Edit /etc/console-tools/config and change these two entries:

# screen blanking timeout. monitor remains on, but the screen is cleared to
# range: 0-60 min (0==never) kernels I've looked at default to 10 minutes.
# (see linux/drivers/char/console.c)
#BLANK_TIME=30
BLANK_TIME=0

# Powerdown time. The console will go to DPMS Off mode POWERDOWN_TIME
# minutes _after_ blanking. (POWERDOWN_TIME + BLANK_TIME after the last input)
#POWERDOWN_TIME=30
POWERDOWN_TIME=0

Revision history for this message
ser_bur (ser-bur) wrote :

Well, yesterday I have made these changes and left laptop playing music. Nothing happened after one hour, and there was noone in this world more happy than me :). But today problem has returned - after ~30 min. of inactivity :(. One more brainstorm...

Revision history for this message
Mircea Deaconu (mirceade) wrote :

Hello! First of all let me say I am truly regretting doing this. This is a spam message sent to all critical bug message lists. It's purpose: making this (https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695) bug critical too. This is a long standing bug and has a very serious impact on laptop type of hardware. It's priority is set to "wishlist" and I just cannot take this anymore. I DO NOT CARE if my account gets suspended. I am doing what's right for all my friends using Ubuntu on their laptops.

Revision history for this message
Antti P Miettinen (apm) wrote :

The symptoms described in this bug might have multiple causes. I just noticed that I can lock up my xorg quite repetably by executing a little GL test program remotely, either tunneled over ssh or not. The mouse pointer is responsive, but the system does not respont to keyboard and mouse clicks. Xorg is spinning. I can log in remotely, kill X and start another. I guess this specific issue should have a separate bug?

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

phillywize, are you still experiencing your issue with the Gutsy release?

Has anyone had a chance to test Hardy? It's got a new version of xserver and all the trimmings, so may behave differently. Hardy Alpha-1 should be out some time later this week.

Revision history for this message
pureblood (freeseek) wrote :

I would like to say that I have the same problem since I upgraded to Gutsy from Feisty a couple of days ago. Freeze-ups are very irregular and only the mouse is working after. Can't access the console with Ctrl+Alt+F1. I can log remotely from another machine. Xorg is taking 100% of the CPU but since the machine is dual processor it is still pretty responsive. I don't have superkaramba running so that fix doesn't apply to me. I am using the ati driver and the graphic card is a "ATI Technologies Inc RV280 [Radeon 9200 SE]". Also, I try to kill Xorg with "killall -9 Xorg" but this doesn't seem to help. Xorg is still there running. I wonder if mine could be a different bug. I am using the standard Gutsy kernel for i686.

Revision history for this message
pureblood (freeseek) wrote :

The administrator of the machine that was freezing-up suggested me that it could be that the graphic card of the machine was flawed. I am thinking that maybe the card was broken but the problem didn't show up with the older version of X for mysterious reasons. Now he changed the graphic card and everything seems to run fine. So maybe this is not a software problem? This is the old graphic card (as of lspci -v):
01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (Secondary) (rev 01)
        Subsystem: ABIT Computer Corp. Unknown device 6190
        Flags: bus master, 66MHz, medium devsel, latency 32
        Memory at e0000000 (32-bit, prefetchable) [size=128M]
        Memory at ff4e0000 (32-bit, non-prefetchable) [size=64K]
        Capabilities: <access denied>
And this is the new one (as of lspci -v):
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] (prog-if 00 [VGA])
        Subsystem: ATI Technologies Inc Unknown device 1b8a
        Flags: bus master, stepping, 66MHz, medium devsel, latency 32, IRQ 16
        Memory at e8000000 (32-bit, prefetchable) [size=128M]
        I/O ports at b800 [size=256]
        Memory at ff4f0000 (32-bit, non-prefetchable) [size=64K]
        Expansion ROM at ff4c0000 [disabled] [size=128K]
        Capabilities: <access denied>
As you see they are not the same but this change seems to have fixed the problem.

Revision history for this message
ser_bur (ser-bur) wrote :

Pureblood, I do not think this is hardware problem, because most of this topic writers have different videocards. This is my one, for example:

00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 01)
        Subsystem: Toshiba America Info Systems Unknown device 0002
        Flags: fast devsel
        Memory at 20000000 (32-bit, prefetchable) [disabled] [size=128M]
        Memory at 2c000000 (32-bit, non-prefetchable) [disabled] [size=512K]
        Capabilities: [d0] Power Management version 1

Moreover, if this is not Ubuntu specific problem, then why it appears after upgrade to Gutsy (in most cases), and cannot be reproduced with other distro (at least in my case)? I have tried to boot with an old kernel, but Xorg freezes with that too, that's why I suppose that it's a bug of current Xorg build...

Revision history for this message
Martin Garton (martingarton) wrote :

I am getting the same problem. Xorg goes into an apparent cpu loop, nothing at all response except for mouse pointer movement. The only way to get back is a "kill -9" sshd from another machine.

My hardware is ati radeon 9200se. From the other reports though, it doesn't seem graphics card specific.

I've tried to find patterns to when it locks, but can't. It happens usually after about 20 minutes of desktop use, but has been much less and much more on occasion.

Revision history for this message
pierpytom (pierpaolo-tommasi) wrote :

Solved with Ubuntu 7.10, I installed the ati proprietary driver with aiglx support and enabled manually compiz! Anyway, the problem seems to happen with the unsopported plugin for compiz!

Revision history for this message
Pedro (pedro-inacio) wrote :

I had this same problem. I am running hardy.
Having read it was a superkaramba problem I disabled it and everything worked fine.
Later I tried again with superkaramba on, and find out it as superkaramba widget, wich monitors system activity was freezing the system. I can run superkaramba themes like LiquidWeather but not system activity monitors.
Hope this helps someone.

Revision history for this message
Diego Foglino (biker84) wrote :

I'don't know is superkaramba problem, because I don't have superkaramba but I have the freeze too.
My freeze are when compiz is active. (gutsy)

Revision history for this message
Luis Davila (luisfer) wrote :

Kubuntu Gutsy
AMD Sempron +3100 1.8GHz 512MB ram
Nvidia GeForce 6100 (nvidia drivers)

hi, like Pedro, after I disabled superkaramba everything works fine. I tried reinstall xserver-xorg but was the same thing. I will test if it's only with system's monitor themes or with all kind of theme.

Revision history for this message
Kristian Barek (kb-barek) wrote :

Ubuntu 7.10
Toshiba Satellite A50-512
Intel Celeron M, 1GB RAM (also tested with 512MB)
Intel 855GM video controller

Error occurs when closing screen lid or putting the system in suspend mode. X server goes into 100% CPU usage. System is still operational and the X server can be killed remotely.
System is otherwise 100% stable - has never had a crash apart from this problem.

This bug happened after upgrading to 7.10, there was never a problem with previous Ubuntu releases.

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

This bug has gathered a lot of noise during all this time. The original report was about issues with the nvidia binary drivers (which we can't fix). Then there were people reporting similar issues with other drivers. Please check the driver bug page for your driver. GPU soft locks should be driver specific.

Changed in xorg:
assignee: bryceharrington → nobody
importance: Critical → Medium
status: Confirmed → Invalid
Revision history for this message
fahad (fahad-ifthkar) wrote :

Ok I have been having this problem on many version of linux, from Fedora to SUSE to Ubuntu, I am now using Suse 10.1

I did some investigation into why my system was using 100% cpu after about 19-20 mins of the system being on, this is what would have with fedora and suse and ubuntu.

in the directory /proc/acpi/processor/CPU0/performance the cpu state kept getting slower and slower, as this became slower the more processor power started to get used. after 20mins my laptop was at 100% cpu as soon as i changed cpu state to state P0 cpu cycles went down to normal levels and i could start using by system again.

so i wrote a script (not very good at this) but it worked for my system, the script would check my cpu state every 3 mins and change it if it was above a certain condition. been doing this now for a good few months no more lock ups.

so for all you people out there check to see if you are having the same problem with the cpu performance.

Revision history for this message
Pierpaolo Follia (pfollia) wrote : AW:FW: *--.

Dear, I have tried to purchase some products from a business company,
I have attracted by high quality products, low price and enthusiastic
services, I think if you are free, you can go to see: styleele.com
,picking your interesting. r--.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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