Since the last x.org update (126.96.36.1992-2 -> 1.13.1-1) the X process periodically uses a LOT of cpu time, slowing the whole system down. I upgraded the kernel at the same time (3.6.11-1 -> 3.7.3-1), so I'm not too sure where exactly the problem lies.
As of yet I've downgraded the kernel (back to 3.6.11-1 again), but I'm unable to downgrade xorg, since somehow the xf86-video-ati package won't work, even if I downgrade that, too.
Some odd things:
- This happens no matter what software runs
- /usr/bin/X -nolisten tcp vt07 -auth /var/run/slim.auth eats about 95% CPU, according to htop.
- When using opera, X tends to eat exactly one of my 8 cores. When running firefox, it tends to smear itself over 4 cores.
- Windowmanager is Fluxbox, and this happens with or without xcompmgr running
- Happens roughly every 5 minutes and lasts for a minute or two.
Software I'm usually running:
- opera (about 8-10 tabs, no flash)
- rdesktop (between 1 and 4 sessions, usually 2)
- 1 or 2 urxvt windows
xrestop shows nothing of note. Highest processes there are xcompmgr (if running) or fluxbox (if xcompmgr isn't running).
Sometimes windows start disappearing. Not being closed, but simply vanishing from view, although the process is still alive and the window is shown in the window manager bar.
I doubt it's a fluxbox bug, since that one hasn't had an update in quite a while.
- Downgraded fluxbox (1.3.3-1 -> 1.3.2-1) and opera (12.12.1707-1 -> 12.11.1661-1). Still no dice.
Last edited by Whoracle (2013-01-24 09:37:57)
Similar issue here...
More or less the same system:
# yaourt -Q | egrep "fluxbox|firefox|roxterm|xorg-server" local/bin32-firefox 18.0.1-1 extra/firefox 18.0.1-1 extra/fluxbox 1.3.3-1 local/fluxbox-styles dayly-1 community/roxterm 2.6.5-1 extra/xorg-server 1.13.1-1 (xorg) extra/xorg-server-common 1.13.1-1 extra/xorg-server-utils 7.6-3
I've noticed that sometimes while running firefox (either with or without flash), I get a new feature like oldies windows and then the X goes 100% of one of the cpucores.
Just pressing alt+tab it stops... but the fluxbox banner remains there (wherever I have the mouse while I'm pressing alt+tab).
Is strange that We're using fluxbox...
I've seen this new feature on my laptop and on my desktop with Nvidia & intel cards (everything else on the Arch system is the same)....
I'll launch the xrestop and see if there's something there...
Also I've tryed to build&use fluxbox from sources and I get the same feature.
After a few hours of running the downgraded fluxbox, the problem still persists, but the interval has been getting longer. So maybe it's somewhere in fluxbox after all. I'll try going down one more flux version later.
Also, I'm getting the oldies artifact, too.
What graphics driver do you use?
Instead of downgrading, why not testing another WM?
Because I like my fluxbox and don't want another WM on my (work/production) system?
I've been having the same problem described here by Whoracle and franziskaner.fan
# yaourt -Q | egrep 'xorg-server|fluxbox|intel'
extra/xf86-video-intel 2.20.19-1 (xorg-drivers xorg)
extra/xorg-server 1.13.1-1 (xorg)
I just updated the intel drivers today and haven't given them a try, but it's been a few updates since this started happening and it wasn't fixed by the new drivers.
I can't see anything relevant in /var/log/Xorg.0.log either.
just before I went home there was another update for ati-dri. I'll report if that changed anything tomorrow. Further downgrading of fluxbox brought no changes, so I'm back to 1.3.2-1 for the time being. It's the most current version that doesn't have the problems too much.
I'm having very similar problem on my Lap, it's an old Compaq with AMD V160 Processor, mobility radeon HD 4200 series and 3GB ram. I'm running xf86-video-ati Driver and not using Flubox.
My software list:
- Epiphany (even with only one open tab problem comes)
I currently have installed all the updates on available but nothing seems help to solve the issue.
After the last update to Xorg-server released today (xorg-server 1.13.2-1) the problem still persist even is noticeable less frequent.
I confirm that the problem persists with the new release of xorg-server. Took it a day or so, but it happened in the end.
I found the bug that is affecting me at the fluxbox bugtracker:
https://sourceforge.net/tracker/?func=d … tid=413960
It is confirmed to work, the patches are already in GIT, so using fluxbox-git is supposed to solve the problem
I'm just building it, so I'll report asap I don't see the problem again :-)
Edit: No fail in +4hrs :-)
Last edited by franziskaner.fan (2013-01-28 14:13:24)
@franziskaner.fan: What do you mean by "no fail"? Did the "window tooltip"-bug go away or the CPU usage bug?
Built fluxbox-git and using xorg-server 1.3.2 right now. As of yet I don't know if the CPU usage bug persists.
Tried LXDE and OpenBox yesterday, and they both had the same problem.
Edit: And there's the bug again.
[anthrax@armageddon ~]$ yaourt -Q | egrep 'xorg-server|fluxbox|ati' [8:58] extra/ati-dri 9.0.2-1 archlinuxfr/fluxbox-git 20110207-1 extra/xf86-video-ati 1:7.0.0-1 (xorg-drivers xorg) extra/xorg-server 1.13.2-1 (xorg) extra/xorg-server-common 1.13.2-1 extra/xorg-server-utils 7.6-3
Last edited by Whoracle (2013-01-29 08:00:16)
I compiled it from the git repository on the 28th and this annoying bug seems to be fixed, it hasn't happened since.
@Whoracle: It seems like you didn't compile it but installed a precompiled package from archlinuxfr.
You're right. I now installed it from AUR and the error still persists. Will try manually compiling it and report back.
I'm running cinnamon 1.7.2-2 with xorg 1.13.3-1 and I have the same issue, specifically
/usr/bin/X -nolisten tcp vt07 -auth /var/run/slim.auth
drawing heavily on CPU and RAM.