You are not logged in.
Exactly as the topic title says. Using either chromium, or chrome from the AUR, the cinnamon desktop becomes progressively slower and more unresponsive until chrome is closed (if the ability to run in background is checked, pkill chrome* is needed to end the slowdown). This is especially noticable dragging windows around the desktop resulting in sluggish movement.
I'm running the latest cinnamon as of the writing of this, system is fully up to date, it's a fairly vanilla and by the book install. Other than base and base-devel I use cinnamon, xorg-server, vim, virtualbox, (with a windows 7 guest), a few extra perl modules, thunderbird, firefox, chrome and chromium. I've tested the following things.
- Intel integrated graphics using xf86-video intel, still slows down.
- Latest nVidia drivers using GTX580 card, still slows down.
- Blacklist accelleration in chrome via command line switch, still slows down.
- Disable acceleration and ability to run in background via chrome settings, still slows down.
- Disable desktop effects in cinnamon, still slows down.
- Use firefox instead of chrome, works good, never slows down.
Now firefox is fine for most things and I have it set up to be pretty chrome like anyway, but I do have to use google docs for work so I end up using chrome for that and firefox for everything else right now. Kind of cumbersome as I like to keep things extremely minimal especially in terms of how many browsers I have installed.
(Additional note), Just remembered to add that I also use the infinality bundle via repos, set in ms render style, and also the full windows 7 ttf fonts.
Last edited by TheWretched (2014-12-03 17:39:39)
Offline
Have you checked the logs (journalctl -f)? Maybe also redirect xorg output (exec startx -- -keeptty -nolisten tcp > ~/.xorg.log 2>&1 in .xinitrc)
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
I found these errors in relation to Cinnamon with journalctl -p 0..3 -xn
gtk_progress_bar_set_text: assertion 'GTK_IS_PROGRESS_BAR (pbar)' failed
gtk_progress_bar_set_fraction: assertion 'GTK_IS_PROGRESS_BAR (pbar)' failed
gtk_progress_bar_set_show_text: assertion 'GTK_IS_PROGRESS_BAR (pbar)' failed
gtk_progress_bar_set_text: assertion 'GTK_IS_PROGRESS_BAR (pbar)' failed
pam_tally(cinnamon-screensaver:auth): Error opening /var/log/faillog for update
pam_tally(cinnamon-screensaver:auth): Error opening /var/log/faillog for read
pam_tally(cinnamon-screensaver:setcred): Error opening /var/log/faillog for update
pam_tally(cinnamon-screensaver:setcred): Error opening /var/log/faillog for update
I'm using SLIM as a login manager for what it's worth.
Last edited by TheWretched (2014-12-03 22:42:04)
Offline
SLiM is broken in Arch, try if LightDM or xinitrc makes a difference.
Are these messages "spammed" or just single occurences? (google for them anyway)
Last edited by Alad (2014-12-04 10:36:32)
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Offline
No they aren't spammed, those appear to be coming up on restart. Also I did see the screensaver creating a gtk error that was similar on resume from the lock screen.
What's broken in SLiM? The wiki lists it as supported and speaks really highly of it so that's why I chose it. What about GDM is that good to use with cinnamon? I know when I first switched from KDE and had both KDM seemed to be starting it up fine.
Actually scratch that, I just checked the wiki, I hadn't looked since I first switched to slim and cinnamon and since then they added a big red warning that it was abandoned. I guess I'll try out this lightdm, it sounds interesting.
Last edited by TheWretched (2014-12-04 14:39:35)
Offline
All those GTK errors went away with lightdm.
However things had been getting worse. Before I installed lightdm today my system was frozen completely. Xorg crashed. Since then it's frozen completely twice in the last hour with xorg crashing both times. Only chrome was open. First with render accell on, and then with it off.
*Think I found the reason for the hard freeze... I installed the flashplugin for firefox, which also added it to chrome. Disabling it in chrome *seems* to be alleviating the freeze.
Last edited by TheWretched (2014-12-04 17:09:30)
Offline
I've been having issues with high CPU utilization since Cinnamon 2.4 came out, and I am not a Chromium user ... I use Firefox almost exclusively (Chromium has not been run since this issue arose, though Chromium is installed for those 'just-in-case' circumstances).
I never really associated the high CPU usage with a single piece of software other than Cinnamon itself (or the underlying Gnome components). I suspect that it is having a hard time rendering the desktop windows, and the issue is just more noticeable when resource hungry apps like browsers are running. But it is certainly, in my case, not limited to resource hungry apps. Moving the very small 'gnome-calculator' window around the screen causes the Cinnamon process to spike above 80% CPU usage. Even simply moving the mouse around the open windows, especially quickly moving over menu bars or over animations (e.g., the CPU-utilization animation in QPS) cause spikes in the process to over 50%. Perhaps 'spike' is the wrong word because recovery from the 'spike' once the activity stops is not instantaneous (i.e., the high CPU load slowly declines over several seconds before settling at its abnormally high idle load of ~7-20%).
Like the OP, this behavior is not evident at first-startup and gradually worsens the longer the Cinnamon session has been ongoing, with Cinnamon's CPU utilization at startup being around 0.5%. This gradually rises to the 7-20%+ utilization at idle, and 'spiking' to above 80% becomes more frequent as tasks are performed on the PC. Restarting Cinnamon clears the issue for the most part, but only to have the process repeat until it must be restarted again.
This particular system:
- has Cinnamon 2.4 installed;
- is otherwise up-to-date;
- uses the radeon driver;
- has direct rendering ON;
- has all desktop effects turned off (as is normally the case for me);
- uses startx / xinit (no login manager).
Other:
- I have tried the system with no screensaver, with Cinnamon's screensaver and with Xscreensaver (the latter being my usual screensaver), and it had no effect, good or bad, on the behavior described above.
- I've disabled Conky and Cairo-Dock, and it had no effect.
- Journal shows nothing out of the ordinary.
- Nothing was added or modified between the time Cinnamon was behaving normally and the onset of high-CPU utilization, other than normal system upgrades (which of course included upgrading Cinnamon to 2.4).
- I have run the PC without a Xorg conf file, and I have run the PC with a Xorg conf file which is basically the same as the one posted in the ATI wiki article (I have also experimented with accel-methods in the conf file; nothing made a difference other than 'glamor' caused a no-start issue when that option was tried).
- I have had no complete lock-ups or crashes resulting from this issue, just the frustration of a bogged-down machine.
I'm somewhat surprised that few people are discussing this topic, but I did find these two similar cases (one more similar than the other) at the Cinnamon forums. I am not a member there and have not participated. Here are the links:
http://forums.linuxmint.com/viewtopic.p … 93ec411084
http://forums.linuxmint.com/viewtopic.p … 3020bb3439
Edit:
I forgot to mention:
- that I rebuilt Cinnamon and Muffin (but no other Cinnamon components) and reinstalled to see if that was helpful, but it did not change anything.
- that I am using default themes, icon set, etc. Tried a couple of downloaded themes and a different icon set: no difference.
Edit:
Corrected typo misstating version of currently installed Cinnamon package.
Last edited by MrWeatherbee (2014-12-10 13:11:16)
Offline
Well, I had to give up on nVidia for now. I was messing around trying a fresh image of arch and having a bunch of problems (mostly system freezing) and said to hell with it, I'll just roll back to my backup image.
So I booted from a usb stick, wiped my drive, rsynced my backup image back to it and walked away to go home for the evening. I come back this morning and what do I find? Well it finished, that's good, problem is the screen is actually on, and it's completely frozen just sitting there in the latest arch linux install media terminal.
So I got mad, ripped out the gtx580, expunged all traces of nVidia drivers from my image, put it back to intel integrated with the xf86-video-intel package and appropriate extras and here I sit back at square one on my original image. But at least intel video doesn't freeze the system. The only thing I can figure is this entry level asus motherboard has some issue with that card, because it was working in another arch system, albeit of a slightly older kernel.
In the process of sitting there watching journalctl I came across something unrelated but curious. My primary mouse button on my Razer death adder was starting to flake out (as they do eventually, and it's many years old). So I pulled it out took it in the lab, removed the old switches and soldered on two nice new ones. Came back plugged in my mouse and I see a bunch of weird usb errors relating to sane. So googling that led only to something about a guy having charging issues with his iphone, and usb power issues. So I plugged in a fresh microsoft poverty edition mouse. No usb errors, and lo and behold a long time issue I had with USB thumb drives vanished. Used to be if I did large file transfers or write levelled a USB drive the entire system would become horribly unresponsive. I had played with that and some settings that were reputed to fix usb transfer issues but never could figure it out, but it seems it was something involving the razer mouse all along. How strange is that?
Offline
Just a question for Mr Weatherbee, (Not relating to how amusing it is that Mr Weatherbee uses "arch" linux).
Do you run thunderbird in the background all the time while you're using your system? Because one thing I found that was of some help, which was also adding system slowdown for me was the mail.db.idle_limit setting under preferences>advanced>config editor, the default value is 30000, and bumping it to 30000000 at least eliminates thunderbird as one source of system slow down via excessive cpu usage.
Offline
... Do you run thunderbird in the background all the time while you're using your system? ...
No, I don't use Thunderbird at all on Linux. I was also fairly careful when trying to isolate possible causes of the high CPU issue, so even if TB had been running in the background under normal circumstances, I would have shut it down during testing.
But thanks for the tip; I try things all the time, and Thunderbird on my Arch system may be a possibility at some point (I have used it on a Windows 8.1 machine).
Anyway, hopefully I'll get the Cinnamon issues worked out sooner than later. Headed back to Riverdale for now. ![]()
Offline