Description of problem: X has a constant high CPU usage (varies from 10%CPU to 40%CPU. This happens only on a physical machine, not virtual. It has an nvidia driver. The problem is that it feels slow, and every click is just a little delayed. but since it's an Intel Quad Core machine with 4GB RAM, it should not feel this slow. I've never seen this behavior under mdv 2010.1 ( that was for an AMD X2 ).
What driver ?
err... quoting from original comment: "It has an nvidia driver"
Did you use KDE or Gnome ? When switching in a light theme in KDE or Gnome, did this happen again ? (Known bug of bad performances from Nvidia drivers and KDE)
CC: (none) => sfietkonstantin
KDE
(In reply to comment #3) > Did you use KDE or Gnome ? > When switching in a light theme in KDE or Gnome, did this happen again ? > > (Known bug of bad performances from Nvidia drivers and KDE) (In reply to comment #4) > KDE @ Lucien I don't manage to find the known bug you are talking about, which one is it? @ AL13N Is this bug still valid? If so: * from another bug report I understood you always use the default theme, so Ia_Ora, here... is that correct? * is the problem also there when using IceWM instead of KDE? * what does "top" say that uses so much cpu? (using "htop" instead of "top" would be even better)
Keywords: (none) => NEEDINFOCC: (none) => balcaen.john, marja11
I think this is a KDE thing. I'm seeing the same - htop shows /etc/X11/X soaking up every bit of CPU not in use, typically 70-80%. This is with default theme. In LXDE, this doesn't happen. And I'm using the ATI fglrx driver, not nvidia.
CC: (none) => ftg
As a follow-up htop shows that while the CPU spens a lot of time at 100%, it isn't pinned there. It does fluctuate down into the 90s off and on. The next highest user is kwin, at about 10%-20% of what X is using. It seems like kwin is churning X with some relatively CPU-intensive calls.
It is known (posts in KDE forum and mailing lists) that Nvidia has bad performances when drawing 2D things. The best way to optimize is to turn off any animation (oxygen-settings), and use a "light" widget theme like plastique. Then this should be better. And, by experience, rebooting X display after some hours also helps. This is a really annoying bug, and upstream nvidia don't seems to be interested in fixing that, so the best way is to use nouveau, which is more efficient with KDE ...
(In reply to comment #7) > > The next highest user is kwin, at about 10%-20% of what X is using. > @ AL13N Is that the same for you?
i still need to reproduce with alpha2 or cauldron, handn't had time to test yet, but it's on my list... i'll reply soon iirc, i had when doing idle, 20% CPU on X, and if you switch to other desktops, or draw anything, it would get near 100%CPU this was on mga1 for me. and mdv2010.1 didn't have this extra CPU, it's minimum was 0% and went up to 5% or something
I've tested a bit further, and I find that this occurs only on my laptop, not on my desktop. Both use the fglrx driver, and have very similar video card chips: RS780D (Radeon HD 3300) for the desktop, RS780M/RS780MN (Mobility Radeon HD 3200 Graphics) for the laptop. I've started and stopped cpufreq with no effect. And I was wrong about it being KDE-related. The LXDE desktop I tested was on the desktop machine. When I tried "top" on the laptop under LXDE, X was also pinning the CPU. I attached strace to X, and most of the output seems to be the following: setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 select(256, [1 3 4 5 8 9 11 12 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35], NULL, NULL, {0, 495000}) = 1 (in [9], left {0, 494980}) ioctl(9, TCFLSH, 0x2) = -1 EIO (Input/output error) select(256, [1 3 4 5 8 9 11 12 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35], NULL, NULL, {0, 494000}) = 1 (in [9], left {0, 493993}) ioctl(9, TCFLSH, 0x2) = -1 EIO (Input/output error) select(256, [1 3 4 5 8 9 11 12 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35], NULL, NULL, {0, 494000}) = 1 (in [9], left {0, 493992}) ioctl(9, TCFLSH, 0x2) = -1 EIO (Input/output error) select(256, [1 3 4 5 8 9 11 12 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35], NULL, NULL, {0, 494000}) = 1 (in [9], left {0, 493973}) ioctl(9, TCFLSH, 0x2) = -1 EIO (Input/output error) I then googled TCFLSH EIO and found that others get this symptom: https://qa.mandriva.com/show_bug.cgi?id=63522 https://bugzilla.redhat.com/show_bug.cgi?id=475890 https://bugzilla.redhat.com/show_bug.cgi?id=619889 and that it has to do with the switch to running X on VT1 with the system starting mingetty on tty1 as well. Cauldron recently switched to doing just that. The odd thing is that "ps ax | grep getty" on the laptop shows that someone keeps starting mingetty on tty1, and just about every time I run that command, the PID of tty1 changes while the PIDs of tty2-tty6 stay the same. So something is repeatedly crashing tty1 and restarting it. On the desktop, there is no getty for tty1, just tty2-tty6.
I'm wrong again. While the desktop showed no tty1 through several ps commands, now it does, and the tty1 PID is changing just as on the laptop. However, the CPU is not being pinned by X. One possible difference is that the desktop is multi-core and quite more powerful than the single-core laptop.
@ AL13N I doubt the reason of Frank's X using so much CPU in his cauldron, is the same as the reason yours used so much in Mga 1. Because you couldn't yet confirm your bug is still there (in Mga 1 or Mga2a2), I suggest to clone this report if you find it is still valid, but must have another cause, and then put your new comment in the new report. Of course, if you find the same cause: comment here. @ Thierry Assigning to you, you'll assign back and tell me which package is the real culprit if I'm wrong to do this :) Is there a chance this is somehow related to bug 2775 ? @ Frank Please check whether your version of x11-server is the one I put in the rpm package field and change accordingly if it's not.
Keywords: NEEDINFO => (none)Version: 1 => CauldronAssignee: bugsquad => thierry.vignaudSource RPM: (none) => x11-server-1.11.2-3.mga2.src.rpm
I'm still on 1.10.4 because of upgrade conflicts involving x11-driver-input-vboxmouse. This was in the ML a while ago, and somebody said that it might be obsolete. I really wish people would pay more attention to properly obsoleting old packages so that this doesn't occur. I'll remove it, upgrade to 1.11.2-3, and test again.
That was it. X is now behaving nicely under 1.11.2-3. I had forced it onto the desktop a while ago because I got sick of vboxmouse blocking other packages there, so all is explained. @AL13N What x11-server version were you using in mga1 ?
Source RPM: x11-server-1.11.2-3.mga2.src.rpm => x11-server-1.10.4.mga2.src.rpm
this is all very nice :-( some hijacks my bug with a different issue (apparently), and i get locked out of it :-(. now, this bug is due to mga1, it uses arounds 20% when idle (not pinning), has an nvidia cpu on a desktop (laptop is also affected; unsure of vbox, i need to test) causing everything you do, including keyboard input to be just a little slower than i was used to under mdv, but still noticable. i will get around to testing on mga2a2/cauldron (not now, since my wife took my desktop away) to see if this improves, hold your horses, people... you only asked me this yesterday...
(In reply to comment #16) > this is all very nice :-( > > some hijacks my bug with a different issue (apparently), and i get locked out > of it :-(. > Now, now. I had originally missed that you were mga1, and you said that you were using a multi-engine CPU, so only one core would have been pinned, giving you less than 100%. And while I guess I did hijack it, I returned it to you safe and sound :-)
assigning back to the Bug Squad, since the problem got resolved for Frank by the update, and because it is unclear whether AL13N still has the issue @ AL13N This bug is all yours again. I'm leaving version Cauldron, because you said you'd test on Mga2a2 Please fill out the correct version of x11-server src.rpm BTW, what is your output of lspcidrake -v | fgrep Card And can you please test with another DE than KDE, too?
Keywords: (none) => NEEDINFOAssignee: thierry.vignaud => bugsquadSource RPM: x11-server-1.10.4.mga2.src.rpm => x11-server src.rpm
> Now, now. I had originally missed that you were mga1, and you said that you > were using a multi-engine CPU, so only one core would have been pinned, giving > you less than 100%. And while I guess I did hijack it, I returned it to you > safe and sound :-) 20% of one core, yes... any kind of movememnt brings it up to 100% (ie: one core) fairly quick though. but returning you did :-) (In reply to comment #18) > assigning back to the Bug Squad, since the problem got resolved for Frank by > the update, and because it is unclear whether AL13N still has the issue > > @ AL13N > This bug is all yours again. > I'm leaving version Cauldron, because you said you'd test on Mga2a2 np with that. > Please fill out the correct version of x11-server src.rpm > > BTW, what is your output of lspcidrake -v | fgrep Card > > And can you please test with another DE than KDE, too? i'll test locally here on a VBOX, but ideally i need my work machine to test all of this. but i am on holidays until 3rd Januari...
(In reply to comment #19) > > i'll test locally here on a VBOX, but ideally i need my work machine to test > all of this. but i am on holidays until 3rd Januari... If you find time, please test :)
(In reply to comment #20) > (In reply to comment #19) > > > > > i'll test locally here on a VBOX, but ideally i need my work machine to test > > all of this. but i am on holidays until 3rd Januari... > > If you find time, please test :) giving you 2 weeks extra time, you mentioned on IRC how busy you are :)
Source RPM: x11-server src.rpm => x11-server
the extra weeks have passed ;) Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as OLD.
Status: NEW => RESOLVEDResolution: (none) => OLD
unreproducable atm
Created attachment 2645 [details] Screenshot of htop showing the issue and some extra specs
I am having this issue with Mageia 2, Gnome 3, and Nvidia binary drivers on a Mac Mini (mid 2010). Can't think of much new information I can give you, but here's what I could come up with: [lietu@MacMini ~]$ rpm -qa | grep xorg xorg-x11-75dpi-fonts-7.6-6.mga2 x11-server-xorg-1.11.4-2.mga2 [lietu@MacMini ~]$ rpm -qa | grep nvidia nvidia-current-kernel-desktop-latest-295.49-4.mga2.nonfree dkms-nvidia-current-295.49-2.mga2.nonfree nvidia-current-doc-html-295.49-2.mga2.nonfree nvidia-current-kernel-3.3.6-desktop-2.mga2-295.49-4.mga2.nonfree x11-driver-video-nvidia-current-295.49-2.mga2.nonfree [lietu@MacMini ~]$ rpm -qa | grep gnome xine-gnomevfs-1.1.19-9.mga2.tainted gnome-power-manager-3.4.0-1.mga2 gstreamer0.10-gnomevfs-0.10.36-1.mga2 lib64gnome-media-profiles0-3.0.0-8.mga2 libgnome2-schemas-2.32.1-8.mga2 gnome-icon-theme-3.4.0-1.mga2 lib64gnomespeech7-0.4.25-7.mga2 gnome-python-bonobo-2.28.1-4.mga2 libgnomekbd-common-3.4.0.2-1.mga2 task-gnome-minimal-3.4.1-4.mga2 gnome-mime-data-2.18.0-9.mga2 libgnome-keyring-i18n-3.4.1-1.mga2 gnome-system-monitor-3.4.1-1.mga2 gnome-shell-3.4.1-1.mga2 gnome-vfs2-2.24.4-3.mga2 libgnome2-2.32.1-8.mga2 lib64gnomeui2_0-2.24.5-3.mga2 gnome-bluetooth-3.4.0-1.mga2 gnome-speech-driver-espeak-0.4.25-7.mga2 lib64gnome-keyring0-3.4.1-1.mga2 mageia-theme-gnome-1.5.0.28-4.mga2 gnome-session-bin-3.4.1-1.mga2 gnome-menus-3.4.0-1.mga2 gnome-search-tool-3.4.0-1.mga2 lib64proxy-gnome-0.4.7-6.mga2 gnome-panel-3.4.1-1.mga2 gnome-themes-extras-2.22.0-7.mga1 gnome-python-gnomekeyring-2.32.0-12.mga2 lib64gnome-bluetooth10-3.4.0-1.mga2 xchat-gnome-0.26.1-12.mga2 gnome-packagekit-common-3.4.0-1.mga2 gnome-video-effects-0.4.0-1.mga2 gnome-speech-0.4.25-7.mga2 gnome-terminal-3.4.1.1-1.mga2 lib64gnome-bluetooth-applet-gir1.0-3.4.0-1.mga2 lib64gnome-desktop3_2-3.4.1-1.mga2 gnome-session-3.4.1-1.mga2 openssh-askpass-gnome-5.9p1-5.mga2 gnome-color-manager-3.4.0-1.mga2 gnome-python-canvas-2.28.1-4.mga2 lib64gnome-menu3_0-3.4.0-1.mga2 python-gnome-menus-3.4.0-1.mga2 gnome-python-desktop-2.32.0-12.mga2 lib64gnome-keyring-gir1.0-3.4.1-1.mga2 gnome-themes-standard-3.4.1-1.mga2 lib64gnomekbd7-3.4.0.2-1.mga2 gnome-applets-3.4.1-1.mga2 lib64gnome-bluetooth-applet0-3.4.0-1.mga2 gnome-settings-daemon-3.4.1-1.mga2 polkit-gnome-0.105-1.mga2 lib64gnomecanvas2_0-2.30.3-4.mga2 gnome-python-2.28.1-4.mga2 gnome-screensaver-3.4.1-1.mga2 gnome-icon-theme-symbolic-3.4.0-1.mga2 gnome-tweak-tool-3.3.4-1.mga2 lib64gnome-vfs2_0-2.24.4-3.mga2 lib64ia_ora-gnome-1.0.25-1.mga1 gnome-control-center-3.4.1-2.mga2 gnome-desktop3-3.4.1-1.mga2 gnome-python-gconf-2.28.1-4.mga2 libgnomecanvas-2.30.3-4.mga2 gnome-doc-utils-0.20.10-1.mga2 gnome-keyring-3.4.1-1.mga2 lib64gnome-bluetooth-gir1.0-3.4.0-1.mga2 gnome-phone-manager-0.68-7.mga2 lib64gnome2_0-2.32.1-8.mga2 libgnomeui2-2.24.5-3.mga2 lib64gnomekbd-gir3.0-3.4.0.2-1.mga2 gnome-media-2.91.2-1.mga2 gnome-user-docs-3.4.1-1.mga2 [lietu@MacMini ~]$ lspci -k 00:00.0 Host bridge: nVidia Corporation MCP89 HOST Bridge (rev a1) 00:00.1 RAM memory: nVidia Corporation MCP89 Memory Controller (rev a1) 00:01.0 RAM memory: nVidia Corporation Device 0d6d (rev a1) 00:01.1 RAM memory: nVidia Corporation Device 0d6e (rev a1) 00:01.2 RAM memory: nVidia Corporation Device 0d6f (rev a1) 00:01.3 RAM memory: nVidia Corporation Device 0d70 (rev a1) 00:02.0 RAM memory: nVidia Corporation Device 0d71 (rev a1) 00:02.1 RAM memory: nVidia Corporation Device 0d72 (rev a1) 00:03.0 ISA bridge: nVidia Corporation MCP89 LPC Bridge (rev a2) Subsystem: Apple Computer Inc. Device cb89 00:03.1 RAM memory: nVidia Corporation MCP89 Memory Controller (rev a1) 00:03.2 SMBus: nVidia Corporation MCP89 SMBus (rev a1) Subsystem: nVidia Corporation Device cb89 00:03.3 RAM memory: nVidia Corporation MCP89 Memory Controller (rev a1) 00:03.4 Co-processor: nVidia Corporation MCP89 Co-Processor (rev a1) Subsystem: nVidia Corporation Device cb89 00:04.0 USB controller: nVidia Corporation MCP89 OHCI USB 1.1 Controller (rev a1) Subsystem: nVidia Corporation Device cb89 Kernel driver in use: ohci_hcd 00:04.1 USB controller: nVidia Corporation MCP89 EHCI USB 2.0 Controller (rev a2) Subsystem: nVidia Corporation Device cb89 Kernel driver in use: ehci_hcd 00:06.0 USB controller: nVidia Corporation MCP89 OHCI USB 1.1 Controller (rev a1) Subsystem: nVidia Corporation Device cb89 Kernel driver in use: ohci_hcd 00:06.1 USB controller: nVidia Corporation MCP89 EHCI USB 2.0 Controller (rev a2) Subsystem: nVidia Corporation Device cb89 Kernel driver in use: ehci_hcd 00:08.0 Audio device: nVidia Corporation MCP89 High Definition Audio (rev a2) Subsystem: nVidia Corporation Device cb89 Kernel driver in use: snd_hda_intel 00:0a.0 IDE interface: nVidia Corporation MCP89 SATA Controller (rev a2) Subsystem: Apple Computer Inc. Device cb89 Kernel driver in use: ata_generic 00:0b.0 RAM memory: nVidia Corporation Device 0d75 (rev a1) 00:0e.0 PCI bridge: nVidia Corporation Device 0d9a (rev a1) Kernel driver in use: pcieport 00:15.0 PCI bridge: nVidia Corporation Device 0d9b (rev a1) Kernel driver in use: pcieport 00:16.0 PCI bridge: nVidia Corporation Device 0d9b (rev a1) Kernel driver in use: pcieport 00:17.0 PCI bridge: nVidia Corporation MCP89 PCI Express Bridge (rev a1) 01:00.0 PCI bridge: Texas Instruments XIO2213A/B/XIO2221 PCI Express to PCI Bridge [Cheetah Express] (rev 01) 02:00.0 FireWire (IEEE 1394): Texas Instruments XIO2213A/B/XIO2221 IEEE-1394b OHCI Controller [Cheetah Express] (rev 01) Kernel driver in use: firewire_ohci 03:00.0 Network controller: Broadcom Corporation BCM43224 802.11a/b/g/n (rev 01) Subsystem: Apple Computer Inc. Device 0093 Kernel driver in use: wl 04:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM57765 Gigabit Ethernet PCIe Subsystem: Broadcom Corporation NetXtreme BCM57765 Gigabit Ethernet PCIe Kernel driver in use: tg3 04:00.1 SD Host controller: Broadcom Corporation NetXtreme BCM57765 Memory Card Reader Subsystem: Broadcom Corporation Device 0000 Kernel driver in use: sdhci-pci 05:00.0 VGA compatible controller: nVidia Corporation GT216 [GeForce 320M] (rev a2) Subsystem: Apple Computer Inc. Device 00c0 Kernel driver in use: nvidia
Status: RESOLVED => REOPENEDCC: (none) => janne.enbergResolution: OLD => (none)
CC: (none) => r.wobben, thierry.vignaud
@ Thierry : Can you shine a light on this matter. Roelof
(In reply to AL13N from comment #23) > unreproducable atm Thx for the feedback (In reply to Janne Enberg from comment #25) > I am having this issue with Mageia 2, Gnome 3, and Nvidia binary drivers on > a Mac Mini (mid 2010). > Hi Janne, sorry for the very late reply. Thanks for reporting this issue for Mageia 2. We are sorry, but we no longer maintain that version of Mageia. Please open a new bug report if this bug still exists in Mageia 3 or later (This report is getting too cluttered to reopen.) As a result we are setting this bug to CLOSED:WONTFIX
Keywords: NEEDINFO => (none)Status: REOPENED => RESOLVEDVersion: Cauldron => 2Resolution: (none) => WONTFIX