Well, that’s not it - the nouveau driver produces the same result, Xorg shot up to 99% and I had to restart X.
LewsTherin
Hi,
just to try
To the op are you on a wired internet connection?
Are you using bluetooth?
If you are on a wired internet try disabling the Network manager setting service
If you are not using blue tooth disable the bluedevil
Disable apper monitor if you are not using it in
systemsettings-start-up and shutdown-servicemanager
In the kde extra repository you can install the
kcm-qt-graphicssystem
After you install it go to systemsettings and configure it to
raster
don’t choose opengl and then logout and login.
I haven’t actually tried that. However, since FF tends to crash by itself fairly frequently - especially when in Google Image Search - I tend to restart it fairly frequently (by “frequently” I mean maybe daily).
I’ve been running FF yesterday and today so far with no crash. I just saved this page and Firefox hit 50% CPU and Xorg 30-40%.
I DO suspect Firefox is the culprit but I’m not sure WHY that would be the case. What I’m suspecting is that somehow Firefox is causing a condition that causes Xorg (or more precisely the NVidia driver) to consume large amount of CPU even after Firefox is closed.
I suppose I’ll have to test that case explicitly.
I’ll try the service disabling in my case, too.
What is the effect of changing from opengl to raster?
The native is X11/xrender not opengl, that will be changed to raster.
opengl in qt-graphicssystem is experimental and in my machine
it crashes kde4 at start-up. However you can use opengl on per application bases
in your qt application like so:
app -graphicssystem opengl
There are documentations in the web regarding and you can just google it
to see how it work.
On 2012-11-29 18:56, richardstevenhack wrote:
> I DO suspect Firefox is the culprit but I’m not sure WHY that would be
> the case. What I’m suspecting is that somehow Firefox is causing a
> condition that causes Xorg (or more precisely the NVidia driver) to
> consume large amount of CPU even after Firefox is closed.
I see that frequently, but not after it closes.
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
Well, the other night Firefox did its usual crashing during Google Image Search (this has been a fairly frequent occurrence, almost daily if I’m doing an Image Search that day. I’ve submitted dozens of crash reports to Mozilla - they’ve done nothing about it for three version now - major PITA.)
Anyway, both before and after Firefox restarted, Xorg continued to jump around from 3% to 50% or more. So just closing or restarting Firefox doesn’t help. However, it doesn’t seem to have affected the Firefox dialogs much. I guess it needs to be much higher CPU usage before it becomes noticeable.
I also disabled all the services listed in the previous post, including Bluetooth, Apper, etc. No change.
I have been up six days now without a reboot and while xorg keeps bouncing around as high as 50%, it hasn’t really slowed the dialogs down much.
I haven’t tried changing from opengl to raster yet. I don’t particularly care about opengl as long as changing it doesn’t break something. I only do normal desktop functions including video playback. I don’t do image or video editing or play games or fancy desktop effects, so I suspect opengl isn’t necessary for my use.
I suppose I’ll try that next and see if it makes a difference.
UPDATE: I installed the Qt graphics config tool - guess what - default was already raster. I may have deselected opengl earlier since it is listed as experimental on the config screen. Anyway, I’ll log out and in and see it anything changes.
Wireless
Just disabled bluedevil and apper monitor
Installed kcm-qt-graphicssystem
qt-graphicssystem-prober reports its already in raster
I’ve been continuing to see 50-80% Xorg usage, we’ll see if this makes a difference.
Thank you,
LewsTherin
OK, I give up. There’s apparently no solution except just rebooting every once in a while. Maybe with the next openSUSE upgrade or NVidia driver there’ll be a fix.
Or maybe I just don’t understand how much CPU Xorg is SUPPOSED to take. When I do a simple Alt-Tab from my Firefox window to my terminal window with top running, I see Xorg jump to anywhere from 25-50% CPU. When I switch between Firefox tabs, it hits 30-50%. Is it SUPPOSED to take that much CPU for Xorg to switch windows? It seems excessive to me. I know window management is a lot of work, but…
I don’t understand why the numbers keep creeping up from low after a reboot to increasingly higher and higher percentages.
In my case, using the following improved 2d performance dramatically:
$ nvidia-settings -a InitialPixmapPlacement=2 -a GlyphCache=1 -a PixmapCache=1
Now my desktop responsiveness is still not ideal, but very usable. I have put this into my ~/.profile file. I think you can just run this command and it will be applied immediately so you (hopefully) can see the difference right away.
Please see:
http://forums.opensuse.org/english/get-technical-help-here/applications/403322-unresponsive-gui-slow-firefox-nvidia-card-explained.html
nVidia 8000/9000 Series Performance Issues - Page 62 - nV News Forums
Best,
Joon
I did - and then did a Google search, only to find, as usual, a dozen different interpretations of those settings - and an indication in one post that in the later drivers, all of them are IGNORED! In any event I made the change described in that post, rebooted and so far I haven’t noticed any improvement. For one thing, the NVidia settings GUI still shows “adaptive” - setting to “Maximum Performance” does nothing as you can’t save the config file from there. Someone on one site suggested disabling the PowerMizer completely but apparently a lot of people can’t even get that to actually happen. This all indicates to me that no one outside of NVidia knows what the hell is going on with their drivers.
I’m afraid NVidia integration with Linux is just pathetic. I found a post on their Dev site saying that KWin doesn’t work well when moving windows and they submitted patches to KDE to fix that. So that suggests to me that the problem I’m having could be anywhere in either NVidia or KDE.
I’m back to wanting to give up and just reboot whenever Firefox dialogs get slow until some day either NVidia or KDE gets their heads out of their butts and documents what they’re doing. It’s impossible to solve a problem if you can’t even begin where to look.
On 2012-12-09 10:16, richardstevenhack wrote:
> I’m back to wanting to give up and just reboot whenever Firefox dialogs
> get slow until some day either NVidia or KDE gets their heads out of
> their butts and documents what they’re doing. It’s impossible to solve a
> problem if you can’t even begin where to look.
I don’t remember if you tried some other desktop? Like gnome, for instance.
–
Cheers / Saludos,
Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)
i too have three week old new install of 12.2 and i’m witnessing xorg with high cpu along with a sluggish desktop. i have also felt this was firefox related.
when xorg cpu is running with over 60% and i kill firefox, it drops to zero.
however, i have a new wrinkle. at three days of up time the following starts to show up in the messages log:
Dec 25 12:39:19 acan kernel: [TTM] Out of kernel memory
Dec 25 12:39:19 acan kernel: [drm] nouveau 0000:0f:00.0: ntfy -12
Dec 25 12:39:54 acan kernel: [TTM] Out of kernel memory
Dec 25 12:39:54 acan kernel: [drm] nouveau 0000:0f:00.0: ntfy -12
Dec 25 12:41:05 acan kernel: [TTM] Out of kernel memory
Dec 25 12:41:05 acan kernel: [drm] nouveau 0000:0f:00.0: ntfy -12
i’m also running vmware workstation 9 with several vm’s running all the time. should i not catch this log message in time, the kernel begins to kill off
processes, usually starting with the vmware-vm processes.
this is an hp z600 workstation and this is the first install of linux on it, so nothing to compare with. it has an FX1800 graphics card with the default
nouveau driver. desktop effects are disabled. it is mostly current with patches (as of about 10 days ago.)
the glamoregl issue offered earlier in this thread does not seem to be an issue:
24.503] (II) LoadModule: “glamoregl”
24.503] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so
24.504] (II) Module glamoregl: vendor=“X.Org Foundation”
24.504] compiled for 1.12.3, module version = 0.4.0
24.504] ABI class: X.Org ANSI C Emulation, version 0.4
does anyone have any suggestions? anything from the logs to look for?
(should i have opened a new thread?)
Looks like similar issues over in Ubuntu land since 12.10
https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/1077616
The person who opened that ticket appears to be using the same card as I am (GT240, device ID 10de:0ca3)
And in our case we are similar EQ overflow errors in Xorg.log
[502879.050] [mi] EQ overflowing. Additional events will be discarded until existing events are processed.
[502879.050]
[502879.050] Backtrace:
[502879.160] 0: /usr/bin/Xorg (xorg_backtrace+0x36) [0x564686]
[502879.160] 1: /usr/bin/Xorg (mieqEnqueue+0x26b) [0x54594b]
[502879.160] 2: /usr/bin/Xorg (0x400000+0x4c422) [0x44c422]
[502879.160] 3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f93eb438000+0x6234) [0x7f93eb43e234]
[502879.160] 4: /usr/bin/Xorg (0x400000+0x73347) [0x473347]
[502879.160] 5: /usr/bin/Xorg (0x400000+0x97780) [0x497780]
[502879.160] 6: /lib64/libpthread.so.0 (0x7f93f4623000+0xf140) [0x7f93f4632140]
[502879.160] 7: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7f93f1419000+0xf10eb) [0x7f93f150a0eb]
[502879.160] 8: /usr/lib64/libpixman-1.so.0 (0x7f93f439c000+0xf41f) [0x7f93f43ab41f]
[502879.160] 9: /usr/lib64/libpixman-1.so.0 (0x7f93f439c000+0x1563e) [0x7f93f43b163e]
[502879.160] 10: /usr/lib64/libpixman-1.so.0 (0x7f93f439c000+0x14956) [0x7f93f43b0956]
[502879.160] 11: /usr/lib64/libpixman-1.so.0 (0x7f93f439c000+0x42607) [0x7f93f43de607]
[502879.160] 12: /usr/lib64/libpixman-1.so.0 (pixman_image_composite32+0x3d6) [0x7f93f43a6466]
[502879.160] 13: /usr/lib64/xorg/modules/libwfb.so (wfbComposite+0x1d8) [0x7f93f120c5b8]
[502879.160] 14: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7f93f1419000+0x4e78f3) [0x7f93f19008f3]
[502879.160] 15: /usr/bin/Xorg (0x400000+0xf6759) [0x4f6759]
[502879.160] 16: /usr/bin/Xorg (0x400000+0xbf5d5) [0x4bf5d5]
[502879.160] 17: /usr/bin/Xorg (0x400000+0xc0426) [0x4c0426]
[502879.160] 18: /usr/bin/Xorg (0x400000+0xbeddc) [0x4beddc]
[502879.160] 19: /usr/bin/Xorg (0x400000+0x5f9e6) [0x45f9e6]
[502879.160] 20: /usr/bin/Xorg (MapWindow+0x17c) [0x46271c]
[502879.160] 21: /usr/bin/Xorg (0x400000+0x331e0) [0x4331e0]
[502879.160] 22: /usr/bin/Xorg (0x400000+0x388c1) [0x4388c1]
[502879.160] 23: /usr/bin/Xorg (0x400000+0x27965) [0x427965]
[502879.160] 24: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7f93f34d1455]
[502879.160] 25: /usr/bin/Xorg (0x400000+0x27c3d) [0x427c3d]
[502879.160]
[502879.160] [mi] These backtraces from mieqEnqueue may point to a culprit higher up the stack.
[502879.160] [mi] mieq is *NOT* the cause. It is a victim.
[502881.240] [mi] Increasing EQ size to 512 to prevent dropped events.
[502881.240] [mi] EQ processing has resumed after 95 dropped events.
[502881.240] [mi] This may be caused my a misbehaving driver monopolizing the server's resources.
(However, this is not always logged when CPU usage spikes to 100%)
I’ve been unable to locate a newer VBIOS for the card, the one at the link below was the same version:
VGA Bios Collection: EVGA GT 240 512 MB | techPowerUp
Sigh. This issue essentially renders an affected system unusable when it strikes, requiring an X restart. Hardly convenient.
I may try emailing evga support to see if perhaps there is a newer vbios, it would be interesting to see if that made a difference. Certainly newer kernels, nouveau or latest nvidia drivers do nothing.
This problem (XORg using 20-80% CPU) has persisted since opening this thread last November. In fact its persisted long before, and from OpenSuse 12.1 to 12.2 to 12.3 and with all nvidia stable drivers from ~304.51 to 319.23 - and the nouveau driver as well.
It is so very annoying to have to restart X at random intervals. I’d love any suggestions on how to zero in on, and resolve, this issue.
I’ve tried:
Fresh install of 12.3 (with btrfs, new partitions and full reformat)
Using kcm-qt-graphicssystem to set to raster mode
Updating system BIOS
Replaced the original GT240 card with a GTX 650
Every new stable release of the Nvidia driver
The Nouvea driver
Nvidia Settings PowerMizer to “Prefer Maximum Performance”
Nepomuk is not running
No ConnectedMonitor option used in XOrg.conf
XOrg.log has nothing helpful - only Failed to load /usr/lib64/xorg/modules/libglamoregl.so which
per previous discussion appears very unrelated. (Though I can certainly post XOrg.log.old newly, to date it provides little insight.)
xrestop does not seem to indicate any culprits
strace on X might show some clues, but deciphering it eludes me (though I can post)
Interestingly, I took the GT240 card out of this 12.3 system and put it in an other OpenSuse 12.3 system, same kernel, with the same version of X, and the same Nvidia driver and it runs great - no high CPU at all, not even once. There is something unique to this environment that seems to cause this issue - I only wish I could determine what.
The only solution richardstevenhack and I seem left with is to restart X whenever this happens. Not exactly the best user experience. After three versions of OpenSuse, many versions of Xorg and Nvidia driver and a fresh 12.3 install it’s a bit amazing to see this persisting.
I appreciate suggestions anyone may have on this.
LewsTheirn
here are my findings.
it does not seem to be graphics vendor related. my first problems manifested
with an fx-1800. it was replaced with an ati mv2250 card. problems persisted.
it is not browser related. same issues with firefox and chromium.
from research, X11 seems to be getting the blame. perhaps because X seems to
fail first. on my failing system, when the problems arise simply restarting X
does not completely cure the problem. with only an X restart, the problems will
return in less than 24 hours.
with only empirical evidence, i believe this to be an undetermined kernel issue
related to the ratio of physical cpu cores to physical memory. the problem seems
to be exacerbated by applications that can make use of multiple cpu’s (ie. vmware
workstation.)
my problem machine has 12 physical cores (2 x X5650) and 12gb memory. it
reliably and consistently fails after 72 hours of uptime.
the problems do not present on a machine with 4 physical cores (2 x X5160), 8gb
memory and nvidia graphics. problems are not presented on a machine with 4 physical
cores (1 x L5335), 8gb memory and intel graphics.
in the “for what it’s worth” department, my day job has me maintaining about 100
servers. most, unfortunately, are windows. hardware is mostly hp. so i’m well
acquainted with my hp field support. they tell me they frequently see issues with
the large machines with multiple 6-core cpu’s. the cure, for windows, seems to be to
greatly increase the amount of physical memory. to the tune of 96GB or more.
(i had a vax once with only 96MB…)
will increasing the memory solve anything? don’t know. but it is either that or
chunk the machine.
The system that is showing this issue has single socket i7 (HT enabled, 8 logical cores) with 12GB. The problem has been present on this systems in 8GB and 12GB configurations. Yet on another workstation, also an i7 with 8GB and Nvidia (my old GT 240 card) the problem is not present. Both systems are running the same kernel, version of Xorg and Nvidia driver.
Interestingly now, the issue just happened again. This time when I ran xrestop the highest resource user was plasma-deskop.
I killed the process, and restarted it (maintaining the same Xorg session)
CPU usage instantaneous dropped to < 1%.
Researching further lead to: https://bugs.kde.org/show_bug.cgi?id=314919
That bug relates to systray icon animations, and Dropbox specifically - I also use Dropbox, and on this particular system the Dropbox icon does like to spin forever.
If I pause Dropbox, its mem usage as show in xrestop stops growing. Unsuspend Dropbox, it starts using more memory - every time. Clearly, there is a leak.
This may not be the only issue to blame for the high CPU usage, but some far its the only thing I’ve ever discovered which had any effect on resolving this issue.
Woot - this might be it.
LewsTherin
A KDE patch (from Andreas Hartmetz) has been pushed that appears to resolve this issue
LewsTherin