Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 375615 - >=x11-drivers/nvidia-drivers-275.19 breaks gtk+ / GNOME apps
Summary: >=x11-drivers/nvidia-drivers-275.19 breaks gtk+ / GNOME apps
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: All Linux
: Normal major with 6 votes (vote)
Assignee: Doug Goldstein
URL: http://www.nvnews.net/vbulletin/showt...
Whiteboard:
Keywords:
: 375881 376171 376805 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-07-19 05:26 UTC by Alexandre Rostovtsev (RETIRED)
Modified: 2012-03-22 08:36 UTC (History)
41 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandre Rostovtsev (RETIRED) gentoo-dev 2011-07-19 05:26:36 UTC
Upgrading to nvidia-drivers-275.19 completely broke gdm and gnome for me (note: I am using gnome 3 from the gnome overlay).

After I enter my password in gdm, the password entry screen disappears, the screen background stays at gdm's, and the CPU usage of gdm's gnome-session and gnome-settings-daemon processes spikes to 100%:

# top
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                
17515 gdm       20   0  415m  29m  17m R  100  0.4   3:49.47 gnome-session                                          
17522 gdm       20   0  548m  33m  22m R  100  0.4   3:49.65 gnome-settings-

The login process goes no further; no matter how long I wait, I do not get to my desktop session.

If I attach a debugger to the runaway gnome-{session,settings-daemon} processes and bt, I get the following backtraces:

# gdb -p `pidof gnome-session`
(gdb) bt
#0  0x00007f1fdcd17ba4 in _nv012tls () from //usr/lib64/opengl/nvidia/lib/libnvidia-tls.so.275.19
#1  0x00007f1fe06f46ed in ?? () from //usr/lib64/opengl/nvidia/lib/libGL.so.1
#2  0x00007f1fe06d3eb9 in ?? () from //usr/lib64/opengl/nvidia/lib/libGL.so.1
#3  0x00007f1fe54ca26d in _dl_fini () at dl-fini.c:249
#4  0x00007f1fe209b351 in __run_exit_handlers (status=0, listp=0x7f1fe23e64c8, run_list_atexit=true) at exit.c:78
#5  0x00007f1fe209b3d5 in exit (status=<value optimized out>) at exit.c:100
#6  0x00007f1fe2084fb4 in __libc_start_main (main=0x40cdc0 <main>, argc=4, ubp_av=0x7fffc3c59b28, 
    init=<value optimized out>, fini=<value optimized out>, rtld_fini=<value optimized out>, 
    stack_end=0x7fffc3c59b18) at libc-start.c:258
#7  0x000000000040d341 in _start ()

# gdb -p `pidof gnome-settings-daemon`
(gdb) bt
#0  0x00007f6e02816ba4 in _nv012tls () from //usr/lib64/opengl/nvidia/lib/libnvidia-tls.so.275.19
#1  0x00007f6e065fe6ed in ?? () from //usr/lib64/opengl/nvidia/lib/libGL.so.1
#2  0x00007f6e065ddeb9 in ?? () from //usr/lib64/opengl/nvidia/lib/libGL.so.1
#3  0x00007f6e09e6c26d in _dl_fini () at dl-fini.c:249
#4  0x00007f6e0843b351 in __run_exit_handlers (status=0, listp=0x7f6e087864c8, run_list_atexit=true) at exit.c:78
#5  0x00007f6e0843b3d5 in exit (status=<value optimized out>) at exit.c:100
#6  0x00007f6e08424fb4 in __libc_start_main (main=0x403d50 <main>, argc=1, ubp_av=0x7fff363b8b78, 
    init=<value optimized out>, fini=<value optimized out>, rtld_fini=<value optimized out>, 
    stack_end=0x7fff363b8b68) at libc-start.c:258
#7  0x0000000000404001 in _start ()


Note that with nvidia-drivers-275.09.07 (and all prior versions of the nvidia driver), the system worked perfectly.


Relevant information:
# emerge --info
Portage 2.2.0_alpha45 (default/linux/amd64/10.0/desktop/gnome, gcc-4.6.1, glibc-2.13-r4, 2.6.39-gentoo-r2.3 x86_64)
=================================================================
System uname: Linux-2.6.39-gentoo-r2.3-x86_64-Intel-R-_Core-TM-2_Quad_CPU_Q6600_@_2.40GHz-with-gentoo-2.0.3
Timestamp of tree: Tue, 19 Jul 2011 03:30:01 +0000
distcc 3.1 x86_64-pc-linux-gnu [disabled]
ccache version 3.1.5 [disabled]
app-shells/bash:          4.2_p10
dev-java/java-config:     2.1.11-r3
dev-lang/python:          2.4.6, 2.6.7, 2.7.2, 3.2
dev-util/ccache:          3.1.5
dev-util/cmake:           2.8.5-r2
dev-util/pkgconfig:       0.26
sys-apps/baselayout:      2.0.3
sys-apps/openrc:          0.8.3-r1
sys-apps/sandbox:         2.5
sys-devel/autoconf:       2.13, 2.68
sys-devel/automake:       1.4_p6-r1, 1.5-r1, 1.6.3-r1, 1.7.9-r2, 1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.1-r1
sys-devel/binutils:       2.16.1-r3, 2.18-r4, 2.19.1-r1, 2.20.1-r1, 2.21, 2.21.1
sys-devel/gcc:            3.3.6-r1, 3.4.6-r2, 4.1.2, 4.2.4-r1, 4.3.6, 4.4.5, 4.5.2, 4.6.1
sys-devel/gcc-config:     1.4.1-r1
sys-devel/libtool:        2.4-r1
sys-devel/make:           3.82-r1
sys-kernel/linux-headers: 2.6.38 (virtual/os-headers)
sys-libs/glibc:           2.13-r4
ACCEPT_KEYWORDS="amd64 ~amd64"

gdm-3.0.4-r1, gnome-session-3.0.2, gnome-settings-daemon-3.0.2-r2 from the gnome overlay.
Comment 1 Alexandre Rostovtsev (RETIRED) gentoo-dev 2011-07-19 05:35:11 UTC
Note: if I use kdm to log in, I can log in and get to my desktop successfully. However, I then cannot log out: my gnome-session process's CPU usage goes to 100% and it refuses to terminate.
Comment 2 Alexandre Rostovtsev (RETIRED) gentoo-dev 2011-07-19 05:46:46 UTC
Note: there is nothing of interest in dmesg, ~/.xsession-errors, or /var/log/Xorg.0.log
Comment 3 Dmitry Suloev 2011-07-19 08:29:09 UTC
A similar problem. I'm using LXDE and when closing a window terminal emulator process remains hanging in the memory and starts to eat off one processor core. Retrieved on lxterminal and sakura.
Comment 4 poncho 2011-07-19 08:40:35 UTC
(In reply to comment #3)
> A similar problem. I'm using LXDE and when closing a window terminal emulator
> process remains hanging in the memory and starts to eat off one processor core.
> Retrieved on lxterminal and sakura.

Same issue with gnome 2.32 and gnome-terminal
Comment 5 Yu Yuwei 2011-07-20 09:38:33 UTC
under gnome-2.32,

gnome-session, fusion-icons, and blueman also affected by this issue.
Comment 6 Justin Lecher gentoo-dev 2011-07-21 14:19:47 UTC
That one bit me too under latest gnome in tree.
Comment 7 Pacho Ramos gentoo-dev 2011-07-21 16:06:26 UTC
Can anyone report this to nvidia?
http://www.nvnews.net/vbulletin/forumdisplay.php?f=14

Thanks
Comment 8 Pacho Ramos gentoo-dev 2011-07-21 16:53:23 UTC
*** Bug 375881 has been marked as a duplicate of this bug. ***
Comment 9 Alexandre Rostovtsev (RETIRED) gentoo-dev 2011-07-21 16:54:35 UTC
(In reply to comment #7)
> Can anyone report this to nvidia?

Done: http://www.nvnews.net/vbulletin/showthread.php?p=2458342
Comment 10 Dabian 2011-07-23 15:05:55 UTC
Please mark the faulty version, so people don't install it by accident.

I can confirm the bug for amd64.  I need to manually kill gnome-session to log out from a gnome-session.
Comment 11 Dabian 2011-07-23 15:14:31 UTC
Workaround that works for me:

   emerge -av =x11-drivers/nvidia-drivers-275.09.07
Comment 12 Gilles Dartiguelongue gentoo-dev 2011-07-24 16:04:10 UTC
*** Bug 376171 has been marked as a duplicate of this bug. ***
Comment 13 Thomas Scheiblauer 2011-07-27 15:24:06 UTC
The nvidia certified version 275.21 also has this problem
Comment 14 Thomas Scheiblauer 2011-07-27 15:52:47 UTC
beta 280.11 is also broken (at least on my GTX-260)... so, as stated above, only 275.09.07 seems to be a usable "workaround" if you happen to have linux-3 installed (270 drivers and below won't "compile" in that case).
275.09.07 produces an error, though, when closing glxgears... which wasn't the case with the more recent driver versions:
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
      after 44 requests (44 known processed) with 0 events remaining.
Comment 15 tokiclover 2011-07-27 19:46:17 UTC
In my case even trying to kill gdm and its children process, or Xorg for that matter, did not workd at all. I hade to kill almost anything with an `init 1` to get back a working X session. The funniest thing is that, I slightly--I say slightly--read a related thread in the forum and I did not remember it when that version hit portage. So as there were nothing in Xorg.0.log nor in the various gdm logs that seemed peculiar enough, I restored my system with a stage4 with glibc-2.13-r2 because I suspected glibc-2.13-r4 which was included in the same `emerge -avDuN @world` update. I had weird issues with the r3 version to make it enough as a candidate to an enough 'weird' issue! only to found out later that... it was 275.19!
Comment 16 tokiclover 2011-07-27 19:58:37 UTC
I forgot something. And it's because I tried to open a session to e17/e17+ecomorph with gdm loging manager and get the same issue. I don't remember if starting an X session with a last line like `exec enlightenment_start' in a $HOME/.xinitrc had the same issue. I'd say yes because I tried several means to start an X session after that update.
Comment 17 Brian Dolbec gentoo-dev 2011-07-28 03:22:08 UTC
well, in my case I am in an xfce4 session from gdm login.  I had problems with gitg and the gnome-terminals gitg was started from.  

Oddly enough, I have downgraded nvidia-drivers to 275.09.07, but I have not logged out and reloaded the nvidia-drivers and restarted an x-session.  The problem has not been occurring with the same apps that were giving this problem.
Comment 18 Pacho Ramos gentoo-dev 2011-07-29 17:47:37 UTC
*** Bug 376805 has been marked as a duplicate of this bug. ***
Comment 19 Fabio Erculiani (RETIRED) gentoo-dev 2011-07-31 08:28:28 UTC
I can reproduce it too on my laptop.
Comment 20 Alexandre Rostovtsev (RETIRED) gentoo-dev 2011-08-01 10:00:04 UTC
Pinging maintainers of nvidia-drivers!

This bug was reported 2 weeks ago, and has received zero reaction from the package maintainers. Every day I see people in #gentoo-desktop asking why their gnome is broken, and inevitably it's because of nvidia-drivers-275.19 or 275.21 (which suffers from the same problem).

Please mask the broken drivers until the problem is resolved. Or at least add an ewarn to pkg_postinst of the affected versions. Because users have *no idea* that the driver is what's responsible for making it impossible to log into gnome.
Comment 21 Paul Jewell 2011-08-01 10:43:16 UTC
I can confirm this problem with gnucash in kde4.7. Supridingly, if I run "strace gnucash", it shuts down fine!
Comment 22 Kévin Petit 2011-08-01 17:32:16 UTC
"strace gnucash" works for me too (KDE 4.6.3) : I can close it properly
Comment 23 nE0sIghT 2011-08-02 03:09:30 UTC
New "official" nvidia-drivers 280.13 doesn't fix this bug
Comment 24 Doug Goldstein gentoo-dev 2011-08-03 21:31:49 UTC
(In reply to comment #20)
> Pinging maintainers of nvidia-drivers!
> 
> This bug was reported 2 weeks ago, and has received zero reaction from the
> package maintainers. Every day I see people in #gentoo-desktop asking why their
> gnome is broken, and inevitably it's because of nvidia-drivers-275.19 or 275.21
> (which suffers from the same problem).
> 
> Please mask the broken drivers until the problem is resolved. Or at least add
> an ewarn to pkg_postinst of the affected versions. Because users have *no idea*
> that the driver is what's responsible for making it impossible to log into
> gnome.

The reality of this is that just as many people that have an issue with the drivers will also rage as to why the drivers are masked. Until I get confirmation from NVIDIA on if the issue is a user configuration issue or if its really a bug in the releases they are making, the package typically remains unmasked.

Since masking this package approximately 48 hours ago, 14 Gentoo users have taken the time to send me an e-mail calling me either, incompetent, stupid, or crazy for masking the drivers. One even called me all 3 in the same e-mail. But I guess that balances out the 8 e-mails I got calling me names for not masking the package.

I'll take this time to encourage everyone who thinks that they can maintain this package better and have a better dialog with NVIDIA to become a Gentoo developer and take maintainership of this package from me.

To the polite users that e-mail me or contact me for help with this package or any package I maintain, and understand I am doing this in my free time to give myself and you a distro with nvidia-drivers that you love, I thank you.
Comment 25 Doug Goldstein gentoo-dev 2011-08-03 21:37:03 UTC
(In reply to comment #9)
> (In reply to comment #7)
> > Can anyone report this to nvidia?
> 
> Done: http://www.nvnews.net/vbulletin/showthread.php?p=2458342

Based on the information on this forum thread, I got NVIDIA to open a bug. Unfortunately the issue was not researched prior to 280.13 so it wasn't determined whether it was a blocker to making it official.

Once I have more details, I'll update this bug. More than likely though, once I do have a fix, I'll just add the update to the tree first and everyone can test it and report back.
Comment 26 Alexandre Rostovtsev (RETIRED) gentoo-dev 2011-08-03 22:04:23 UTC
(In reply to comment #24)
(In reply to comment #25)
Doug, thank you for your work and for the detailed reply. I can very well relate to the fact that maintaining a package in one's spare time can occasionally seem a thankless job. My suggestion, however, is to communicate a bit more in bugzilla. If the maintainer of a package does not make a single comment on a major bug report, it really gets the users worried. Did the maintainer forget about the existence of the bug? Is he writing his thesis, and can't spare a single minute for gentoo work for the next two months? Is he no longer interested in maintaining this package, and users need to find some other gentoo dev to help out? Or is he in fact working on addressing the bug, but simply doesn't have a satisfactory solution yet?

Without any communication from the maintainer, uses don't know, gradually grow frustrated, and eventually start assuming the worst.

A simple post saying that "I have asked my NVIDIA contact to open an internal bug report for this issue, will post when I get an update" would have done much to alleviate the problem.

And if there is *anything* that can be done by those who are experiencing this bug to help diagnose and fix it faster (e.g. logs, traces, debugging, testing, etc.), please let us know!
Comment 27 doug 2011-08-06 22:28:43 UTC
You may want to look at  cairo, specifically (use_enable opengl gl) 
Here on another distro rebuilding cairo without gl support has removed these issues w/ current nvidia drivers
Comment 28 Tim Ryan 2011-08-07 00:47:10 UTC
(In reply to comment #27)
> You may want to look at  cairo, specifically (use_enable opengl gl) 
> Here on another distro rebuilding cairo without gl support has removed these
> issues w/ current nvidia drivers

This seems to have worked for me. I recompiled cairo with -opengl, then compiled nvidia-drivers-280.13. I've logged in and out a few times with no problems, and this wasn't possible before if I used anything above 275.19.
Comment 29 Tolga Dalman 2011-08-07 00:55:39 UTC
(In reply to comment #28)
> (In reply to comment #27)
> > You may want to look at  cairo, specifically (use_enable opengl gl) 
> > Here on another distro rebuilding cairo without gl support has removed these
> > issues w/ current nvidia drivers
> 
> This seems to have worked for me. I recompiled cairo with -opengl, then
> compiled nvidia-drivers-280.13. I've logged in and out a few times with no
> problems, and this wasn't possible before if I used anything above 275.19.

This might be the culprit as I have a working Gnome 2.32 system using Cairo+OpenGL with nvidia-drivers 275.21. Can anyone else confirm ?
Comment 30 Alexandre Rostovtsev (RETIRED) gentoo-dev 2011-08-07 02:33:10 UTC
(In reply to comment #29)
> This might be the culprit as I have a working Gnome 2.32 system using
> Cairo+OpenGL with nvidia-drivers 275.21. Can anyone else confirm ?

In short, no.

After some experiments with nvidia-drivers-275.21 and with 280.13 (not yet in portage), it appears that either of the following makes the bug go away:

* if the application is run from strace, gdb, or valgrind; or
* if the environment variable __GL_NO_DSO_FINALIZER is set to 1.

But building cairo with USE="-opengl" has no effect on my machine; the bug still manifests whether USE=opengl or USE=-opengl. I have tried cairo-1.10.2-r1 and cairo-9999, and both behave the same way.

Similarly, setting __GL_SINGLE_THREADED=1 has absolutely no effect (i.e. the bug will manifest if cairo is built with USE=opengl).

Sets of cairo USE flags that I tried: "X glib opengl svg xcb" and "X glib svg xcb" (all other flags were disabled).
Comment 31 Alexandre Rostovtsev (RETIRED) gentoo-dev 2011-08-07 02:51:21 UTC
(In reply to comment #30)
> Similarly, setting __GL_SINGLE_THREADED=1 has absolutely no effect (i.e. the
> bug will manifest if cairo is built with USE=opengl).

Horrific typo; I meant to say "__GL_SINGLE_THREADED=1 has absolutely no effect (i.e. the bug will manifest whether or not cairo is built with USE=opengl)".
Comment 32 Brian Beardall 2011-08-10 04:43:42 UTC
I build cairo with the following use flags:

[ebuild   R    ] x11-libs/cairo-1.10.2-r1  USE="X glib svg xcb (-aqua) -debug -directfb -doc (-drm) (-gallium) -opengl (-openvg) -qt4 -static-libs" 0 kB

and I don't get the opengl bug hang in the nvidia driver anymore. If I compile cairo with opengl support the hang bug is back.
Comment 33 Livid 2011-08-10 12:23:31 UTC
Rebuilding cairo without opengl flag solves the problem for me (nvidia-drivers-275.21)

cairo-1.10.2-r1 (X glib qt4 svg -aqua -debug -directfb -doc -drm -gallium -opengl -openvg -static-libs -xcb)
Comment 34 Damien Thébault 2011-08-18 19:04:10 UTC
On my computer, this bugs makes gdm fail to start gnome, as described in comment #1 (gnome-session is locked).

I tried with yesterday's 285.03 nvidia drivers beta, and the bug is still there.

I tried setting __GL_NO_DSO_FINALIZER="1" (in /etc/env.d/99nvidia), which solves nothing either.
Comment 35 Alexandre Rostovtsev (RETIRED) gentoo-dev 2011-08-18 19:16:56 UTC
(In reply to comment #34)
> I tried setting __GL_NO_DSO_FINALIZER="1" (in /etc/env.d/99nvidia), which
> solves nothing either.

That's because current versions of gdm explicitly ignore almost all environment variables (see https://bugzilla.gnome.org/show_bug.cgi?id=656094). If you want gdm to read __GL_NO_DSO_FINALIZER from env.d, you need to use gdm-3.0.4-r2 (currently in the gnome overlay, but should be coming to the main portage tree some time soon).

However, setting __GL_NO_DSO_FINALIZER="1" in /etc/env.d/99nvidia should at least fix your terminal emulators and make it possible to log out of Gnome.
Comment 36 edoceo 2011-08-24 00:44:23 UTC
I have been seeing issues with nVidia drivers >=275.06  Huge black boxes ghosting terminal (Terminal, roxterm) windows and both those processes hanging on exit.  "nybblenybble" in IRC helped me find this bug.

Comment #28 mentions removing opengl from Cairo and then trying things.
Seems to be OK for me - Terminal, roxterm, xfce4-notes & panel all are behaving nicely.

[ebuild   R   #] x11-drivers/nvidia-drivers-275.21  USE="acpi -custom-cflags gtk (multilib)"

[ebuild   R    ] x11-libs/cairo-1.10.2-r1  USE="X (-aqua) -debug -directfb -doc (-drm) (-gallium) glib -opengl (-openvg) -qt4 -static-libs svg xcb"


Portage 2.1.10.3 (edoceo/neon, gcc-4.4.5, glibc-2.12.2-r0, 2.6.39-gentoo-r3-element x86_64)
=================================================================
System uname: Linux-2.6.39-gentoo-r3-element-x86_64-Intel-R-_Core-TM-2_Duo_CPU_E4600_@_2.40GHz-with-gentoo-2.0.3
Timestamp of tree: Tue, 23 Aug 2011 12:00:01 +0000
app-shells/bash:          4.1_p9
dev-java/java-config:     2.1.11-r3
dev-lang/python:          2.7.1-r1, 3.1.3-r1
dev-util/cmake:           2.8.4-r1
dev-util/pkgconfig:       0.26
sys-apps/baselayout:      2.0.3
sys-apps/openrc:          0.8.3-r1
sys-apps/sandbox:         2.4
sys-devel/autoconf:       2.13, 2.68
sys-devel/automake:       1.9.6-r3, 1.10.3, 1.11.1
sys-devel/binutils:       2.21.1
sys-devel/gcc:            4.4.5
sys-devel/gcc-config:     1.4.1-r1
sys-devel/libtool:        2.4-r1
sys-devel/make:           3.82
sys-kernel/linux-headers: 2.6.36.1 (virtual/os-headers)
sys-libs/glibc:           2.12.2
Repositories: gentoo
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt /usr/share/openvpn/easy-rsa"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.2/ext-active/ /etc/php/apache2-php5.3/ext-active/ /etc/php/cgi-php5.2/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cli-php5.2/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -pipe"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--alphabetical --nospinner"
FEATURES="assume-digests binpkg-logs buildpkg distlocks ebuild-locks fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"
FFLAGS=""
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_EXTRA_OPTS="--quiet"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://cdn.edoceo.com/element/"
USE="X a52 aac acl acpi alsa amd64 berkdb bluetooth branding bzip2 cairo cdda cdr cli consolekit cracklib crypt cups cxx dbus dri dts dvd dvdr emboss encode exif fam firefox flac fortran gdbm gdu gif gtk iconv ipv6 jpeg lcms ldap libnotify mad mmx mng modules mp3 mp4 mpeg mudflap multilib ncurses nls nptl nptlonly ogg opengl openmp pam pango pcre pdf perl png policykit ppds pppd python qt3support qt4 readline sdl session spell sse sse2 ssl startup-notification svg sysfs tcpd tiff truetype udev unicode usb vorbis x264 xcb xml xorg xulrunner xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" 
Unset:  CPPFLAGS, CTARGET, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS
Comment 37 blahstonedblah 2011-08-26 20:58:01 UTC
How is it, that drivers, that isn't in portage (without overlays), are masked, because they break things in gnome3, that also isn't in portage (without overlays). If video card drivers are causing problems with gnome3, and it's not even in portage, whats the reasoning. "You can't have the latest drivers, because I use gnome3, and I can't have them." Isn't this the exact reason'ing behind KEYWORDS? If the drivers aren't 'stable', they should be marked ~x86/~amd64/etc. Not hard masked completely. Users running x86/amd/etc, get gnome2, users running ~x86/~amd64/etc, get gnome2. Users using overlays, get whatever they want, and suffer whatever headaches that go along with that, the same as the users who run ~x86/~amd64/etc, but with the slightly added benefit of being able to be told to try the equivalent x86/amd64/etc package. Not everyone uses gnome2, not everyone uses gnome3. This bug doesn't effect every nvidia user. I'm using 280.13 with fluxbox-1.3.1, and xorg-server-1.10.2. nvidia-drivers-280.13 should not be excluded from portage, or masked, based on bugs with one piece of software, when there is no confirmation that it is or is not the drivers at fault, when it could possible be faults in gnome or ever cairo code.
Comment 38 Alexandre Rostovtsev (RETIRED) gentoo-dev 2011-08-26 21:34:02 UTC
(In reply to comment #37)
> How is it, that drivers, that isn't in portage (without overlays), are masked,
> because they break things in gnome3

This bug affects a large subset of users of all gtk-based desktop environments, including gnome 2.32, gnome 3, and xfce 4. However, it is true that the effect on gnome 3 users is more severe than on other users, since the bug makes it nearly impossible to log in via gdm 3.

> that also isn't in portage

Most gnome 3.0 packages are now in portage (package-masked, for the most part). The rest (including gdm 3) will be coming soon.

> nvidia-drivers-280.13 should not be excluded from portage

There is no gnome-directed conspiracy to exclude 280.13 from portage. I believe that the driver is not in portage simply because the maintainers of nvidia-drivers are busy and haven't had time to add it yet.

> when there is no confirmation that it is or is not the drivers at fault, when
> it could possible be faults in gnome or ever cairo code.

Yes, it could be possible. But considering that gnome and cairo code works correctly on all xorg drivers in existence with the exception of nvidia-drivers-275.19 and higher, and that nvidia-drivers have a history of multithreading bugs that cause some gtk applications to break (e.g. last year, 260.19.04 broke gvim), and that backtraces point to code in nvidia's libGL, it seems reasonable to assume that nvidia-drivers is probably at fault here again.
Comment 39 Fabio Erculiani (RETIRED) gentoo-dev 2011-08-27 06:34:00 UTC
Has anybody contacted NVIDIA already?
I mean, not through forums...
Comment 40 Mikael Magnusson 2011-09-11 11:55:48 UTC
Anyone tried 275.28? It seems to work fine for me, but I never had the problem in the first place (updated X server 1.10.4 w/ nvidia-drivers 275.09.07 to 1.11 w/ 275.28).
Comment 41 Krellan 2011-09-11 21:31:45 UTC
I can confirm this bug as well.  It shows up most often with "gnome-terminal", whenever a terminal window is closed.  One of my CPU cores goes to 100% CPU and stays there, after closing each window, until all cores are eventually at 100%.

At least I know my CPU fans are working well :)
Comment 42 Dmitry Suloev 2011-09-12 10:52:37 UTC
(In reply to comment #40)
> Anyone tried 275.28? It seems to work fine for me, but I never had the problem
> in the first place (updated X server 1.10.4 w/ nvidia-drivers 275.09.07 to 1.11
> w/ 275.28).

It broken for me.
Comment 43 Alessandro Guido 2011-09-13 17:42:46 UTC
Had the same bug (http://www.nvnews.net/vbulletin/showthread.php?t=164775) and compiling cairo with USE="-opengl" fixes the problem for me
Comment 44 Andreas Arens 2011-09-18 12:00:35 UTC
(In reply to comment #42)
> (In reply to comment #40)
> > Anyone tried 275.28? It seems to work fine for me, but I never had the problem
> > in the first place (updated X server 1.10.4 w/ nvidia-drivers 275.09.07 to 1.11
> > w/ 275.28).
> 
> It broken for me.

Seems to be a known bug in server 1.11

This patch from Nvidia's Aaron Plattner seems to fix it.

http://lists.x.org/archives/xorg-devel/2011-September/025062.html

Can you retry if the original problem persists with a patched xserver?
Comment 45 Damien Thébault 2011-09-18 14:15:17 UTC
I tried with xorg-server-1.11 with the patch in comment #44, with nvidia-drivers 275.28, and it does not work.

The latest driver working for me is still 275.09.07.
Comment 46 Thomas Scheiblauer 2011-09-26 10:46:37 UTC
the people for whom
__GL_NO_DSO_FINALIZER="1" (in /etc/env.d/99nvidia)
did not work probably forgot to do an "env-update" afterwards!
(don't forget to reboot or relogin in gdm after doing that)
Following this procedure all the recent nvidia drivers (even the 285.xx beta ones) worked for me.
Comment 47 Chris Smith 2011-09-27 22:53:09 UTC
(In reply to comment #45)
> I tried with xorg-server-1.11 with the patch in comment #44, with
> nvidia-drivers 275.28, and it does not work.

I don't think there's a compatible nvidia driver for xorg-server-1.11 yet. I applied the patch to xorg-server-1.10.4 (didn't look like it could hurt) and remerged it instead.

(In reply to comment #46)
> __GL_NO_DSO_FINALIZER="1" (in /etc/env.d/99nvidia)

And I did this also.

Don't know which one fixed it - took the shotgun approach :) Now all is running fine with nvidia-drivers-285.03, even gnucash shuts down properly.

However, I don't use gdm - always boot in cli then use startx.
Comment 48 Nikolay Orlyuk 2011-09-28 06:29:53 UTC
As I can understand words at http://us.download.nvidia.com/XFree86/Linux-x86_64/280.13/README/knownissues.html and comments there, the issue is related either with application that have undefined order of deinitialization due to outstanding threads (or simply calling dlclose() while other thread is trying to access libGL) or NVidia introduced some thread and do not pthread_join it before freeing resources.
For first case: I think community can bring something useful for NVidia. Like smaller examples code that raises situation that happens with gnome-related application (btw it will be good to see stack-trace of all threads, since _fini wasn't finished as far as I can see).
Second case: again it's possible to find which calls create outstanding thread that interfer with finaliziers. If NVidia will give at least some hints about how they work with threads and do they work at all.

P.S. Opening the sources will solve this issue much better, I think :)
Comment 49 Alexandre Rostovtsev (RETIRED) gentoo-dev 2011-09-28 06:43:40 UTC
(In reply to comment #48)
> it will be good to see stack-trace of all threads, since _fini wasn't finished
> as far as I can see

I have not been able to get a good stacktrace because the bug does not manifest when affected applications are run from a debugger; see comment #30.
Comment 50 Maks Verver 2011-09-28 16:44:13 UTC
(In reply to comment #49)
> I have not been able to get a good stacktrace because the bug does not manifest
> when affected applications are run from a debugger; see comment #30.

When I last tested, it was possible to create a core dump instead of running the process in the debugger directly.  Doesn't this work anymore?
Comment 51 Dmitry Suloev 2011-09-29 10:49:55 UTC
Today I tested the nvidia-drivers-285.05 with xorg-server-1.11.1 (since patch). The problem is still there. Add __GL_NO_DSO_FINALIZER = "1" in / etc/env.d/99nvidia fixes the problem, but the overall responsiveness of GUI drops considerably.
Comment 52 Alex Domingo 2011-10-01 22:54:47 UTC
Setting __GL_NO_DSO_FINALIZER="1" in /etc/env.d/99nvidia fixes the problem with nvidia-drivers-285.03 on xorg-server-1.10.4. No drawbacks observed so far, except for maybe an increased overall sluggishness of the gui during high-load processes. For example, emerging libreoffice causes the desktop to briefly freeze sometimes, but I'm not sure if this behavior is directly produced by the nvidia workaround.
Comment 53 torindel 2011-10-02 10:32:06 UTC
(In reply to comment #50)
> (In reply to comment #49)
> > I have not been able to get a good stacktrace because the bug does not manifest
> > when affected applications are run from a debugger; see comment #30.
> 
> When I last tested, it was possible to create a core dump instead of running
> the process in the debugger directly.  Doesn't this work anymore?

To turn on core dumps:
ulimit -c 9999999999

To force proces to core dump: (assuming it wont be zombie/blocked one)
kill -SEGV pid

To turn off core dumps:
ulimit -c 0
Comment 54 Nikolay Orlyuk 2011-10-02 10:53:38 UTC
(In reply to comment #49)
> (In reply to comment #48)
> > it will be good to see stack-trace of all threads, since _fini wasn't finished
> > as far as I can see
> 
> I have not been able to get a good stacktrace because the bug does not manifest
> when affected applications are run from a debugger; see comment #30.
As I understand programs get dead-locked somewhere when run not under debugger. So as showed in comment #0 it's possible to attach to hanging process and get everything you need.
I.e. run:
> info threads
> thread 1
> bt full
> thread 2
> bt full

(In reply to comment #53)
> (In reply to comment #50)
> > When I last tested, it was possible to create a core dump instead of running
> > the process in the debugger directly.  Doesn't this work anymore?
> 
> To turn on core dumps:
> ulimit -c 9999999999
> 
> To force proces to core dump: (assuming it wont be zombie/blocked one)
> kill -SEGV pid
> 
> To turn off core dumps:
> ulimit -c 0
Note that "ulimit" should be done before running process than need to be dumped.
BTW, you can get core-dump from GDB with "generate-core-file" command.

P.S. As I understand this Bug also covers issue with NVidia incompatibility with xorg-server 1.11.
Comment 55 Dmitry Suloev 2011-10-04 06:21:16 UTC
Nvidia today released the nvidia-drivers-285.05.09 Among other changes, there is a patch for this problem. Details here: http://www.nvnews.net/vbulletin/showthread.php?p=2487046
Comment 56 Alexandre Rostovtsev (RETIRED) gentoo-dev 2011-10-04 07:07:28 UTC
(In reply to comment #55)
> Nvidia today released the nvidia-drivers-285.05.09 Among other changes, there
> is a patch for this problem. Details here:
> http://www.nvnews.net/vbulletin/showthread.php?p=2487046

Confirming that 285.05.09 appears to fix the bug. After updating to 285.05.09 + xorg-server-1.11.1, my vte-based terminals, gnome-settings-daemon, gnome-session no longer freeze, and all processes seem to terminate correctly.
Comment 57 Alexandre Rostovtsev (RETIRED) gentoo-dev 2011-10-04 07:28:46 UTC
> 285.05.09 + xorg-server-1.11.1

285.05.09 + xorg-server-1.11.1 results in horrific lag when scrolling or resizing any gtk-based application (see http://www.nvnews.net/vbulletin/showthread.php?t=166998). However, 285.05.09 + xorg-server-1.10.4 works great.
Comment 58 Dmitry Suloev 2011-10-04 07:31:43 UTC
Maybe the problem with the new kernel (linux 3.1.0-rc8)?
Comment 59 Dmitry Suloev 2011-10-04 10:53:35 UTC
Tested today nvidia-drivers-285.05.09 c xorg-server-1.11.1 Problem solved, but there is another problem - reducing the overall interactivity of the user interface.
Comment 60 Dmitry Suloev 2011-10-04 12:29:46 UTC
(In reply to comment #58)
> Maybe the problem with the new kernel (linux 3.1.0-rc8)?

The problem manifests itself in the independence of the kernel.
Comment 61 Dmitry Suloev 2011-10-04 12:30:41 UTC
(In reply to comment #59)
> Tested today nvidia-drivers-285.05.09 c xorg-server-1.11.1 Problem solved, but
> there is another problem - reducing the overall interactivity of the user
> interface.

If you are using xorg-server-1.10.4 all right.
Comment 62 Dmitry Suloev 2011-10-04 17:22:54 UTC
(In reply to comment #61)
> (In reply to comment #59)
> > Tested today nvidia-drivers-285.05.09 c xorg-server-1.11.1 Problem solved, but
> > there is another problem - reducing the overall interactivity of the user
> > interface.
> 
> If you are using xorg-server-1.10.4 all right.

Yep. Now I mask >xorg-server-1.10.4
Comment 63 Damien Thébault 2011-10-04 20:14:39 UTC
I tried 285.05.09 with xorg-server 1.10.4, I'm now able to login and closing gnome-terminals does not end up with the process using 100% CPU.

So it solves the problem for me.

(But I had to add the gdm user to the "video" group or gdm couldn't be run because of permissions on /dev/nvidiactl, maybe it's gdm 3.2, or nvidia-drivers, or something else)
Comment 64 Fabio Erculiani (RETIRED) gentoo-dev 2011-10-04 20:46:02 UTC
(In reply to comment #63)
> I tried 285.05.09 with xorg-server 1.10.4, I'm now able to login and closing
> gnome-terminals does not end up with the process using 100% CPU.
> 
> So it solves the problem for me.
> 
> (But I had to add the gdm user to the "video" group or gdm couldn't be run
> because of permissions on /dev/nvidiactl, maybe it's gdm 3.2, or
> nvidia-drivers, or something else)

Please inform the Gentoo GNOME team about that. There is a fixed ebuild in the sabayon overlay.
Comment 65 Thomas Scheiblauer 2011-10-05 09:00:55 UTC
@Damien Thébault:
Thank you! You solved my problem with running gdm-3.2 in gnome-shell mode on nvidia "en passant" by your remark about adding gdm to the video group.

Btw,, I can't spot noticable performance penalties by using xorg-server-1.11 (rendering to a GeForce GTX 260 Card) using nvidia-drivers-285.05.09... otoh I haven't yet compared it to xorg-server-1.10 ...
Comment 66 PM 2011-10-17 15:08:13 UTC
What's the status of this bug? Is it supposed to be fixed in 285.05.09? 

I'm getting a lot of crashes in gtk apps, all ending in "_nv007tls () from /usr/lib64/opengl/nvidia/lib/libnvidia-tls.so.285.05.09" or something similar. I've reported it here: https://bugs.gentoo.org/show_bug.cgi?id=387079.

I've also noticed a similar bug here: https://bugs.gentoo.org/show_bug.cgi?id=387237
Comment 67 Alex Boyd 2011-10-24 03:31:27 UTC
(In reply to comment #65)
> @Damien Thébault:
> Thank you! You solved my problem with running gdm-3.2 in gnome-shell mode on
> nvidia "en passant" by your remark about adding gdm to the video group.
> 
> Btw,, I can't spot noticable performance penalties by using xorg-server-1.11
> (rendering to a GeForce GTX 260 Card) using nvidia-drivers-285.05.09... otoh I
> haven't yet compared it to xorg-server-1.10 ...

It's not meant to work with xorg-server 1.11 yet - and you will have problems with it. I highly suggest going to 1.10.4-r1 (or newer stable)
Comment 68 Manfred Knick 2011-12-12 19:46:42 UTC
Problem re-loaded:

( Xeon E3, PNY GTX 560 Ti OC2 )
( amd64, pretty stable )
( XFCE 4 )

[IP-] [  ] x11-base/xorg-server-1.10.4-r1:0
[IP-] [  ] media-video/nvidia-settings-290.10:0
[IP-] [  ] x11-drivers/nvidia-drivers-290.10:0

Enabling USE flag "gtk" for x11-drivers/nvidia-drivers-290.10,
starting gkrellm crashes X with segmentation fault.

Re-disabling gtk support, gkrellm starts and works perfectly again.

Hth.
Comment 69 Mehmet Giritli 2011-12-12 21:48:45 UTC
I still get a hang with 100% cpu usage when quitting gnome-terminal with 285.05.09-r1. Downgrading to 275.09.07 fixes it.
Comment 70 Manfred Knick 2011-12-13 09:31:25 UTC
(In reply to comment #68)

> ( XFCE 4 )

I forgot to mention: Plain TWM : the same.
Comment 71 Ira Moss 2012-02-22 04:06:09 UTC
I was @290.10   same problem... I just found this thread.

I also downgraded to 275.09.07 (along with a xserver downgrade) things work fine now.
Comment 72 Dmitry Suloev 2012-02-22 04:15:47 UTC
This wery old bug. Problem fixed in new version. Plz, update your system.
Comment 73 Ira Moss 2012-02-22 13:34:35 UTC
(In reply to comment #72)
> This wery old bug. Problem fixed in new version. Plz, update your system.


ehh.... could you be more specific on the update....?

Especially since I've been doing emerge -DuN world (depclean as well..) every week now for 7 years..  I might be missing something though...

:-)


other than the fact I just downgraded nvidia-drivers and xorg.. I'm up to date, but have still had this problem until yesterday..

Please let me know what is needed...




 emerge --info
Portage 2.1.10.44 (default/linux/amd64/10.0/desktop/gnome, gcc-4.5.3, glibc-2.13-r4, 3.2.1-gentoo-r2 x86_64)
=================================================================
System uname: Linux-3.2.1-gentoo-r2-x86_64-Intel-R-_Core-TM-_i5-2500K_CPU_@_3.30GHz-with-gentoo-2.0.3
Timestamp of tree: Wed, 22 Feb 2012 00:30:01 +0000
distcc 3.1 x86_64-pc-linux-gnu [disabled]
app-shells/bash:          4.1_p9
dev-java/java-config:     2.1.11-r3
dev-lang/python:          2.7.2-r3, 3.2.2
dev-util/cmake:           2.8.6-r4
dev-util/pkgconfig:       0.26
sys-apps/baselayout:      2.0.3
sys-apps/openrc:          0.9.8.4
sys-apps/sandbox:         2.5
sys-devel/autoconf:       2.13, 2.68
sys-devel/automake:       1.10.3, 1.11.1
sys-devel/binutils:       2.21.1-r1
sys-devel/gcc:            4.5.3-r1
sys-devel/gcc-config:     1.4.1-r1
sys-devel/libtool:        2.4-r1
sys-devel/make:           3.82-r1
sys-kernel/linux-headers: 3.1 (virtual/os-headers)
sys-libs/glibc:           2.13-r4
Comment 74 Dmitry Suloev 2012-02-22 13:42:48 UTC
(In reply to comment #73)
> (In reply to comment #72)
> > This wery old bug. Problem fixed in new version. Plz, update your system.
> 
> 
> ehh.... could you be more specific on the update....?
> 
> Especially since I've been doing emerge -DuN world (depclean as well..) every
> week now for 7 years..  I might be missing something though...
> 
> :-)
> 
> 
> other than the fact I just downgraded nvidia-drivers and xorg.. I'm up to date,
> but have still had this problem until yesterday..
> 
> Please let me know what is needed...
> 
> 
> 
> 
>  emerge --info
> Portage 2.1.10.44 (default/linux/amd64/10.0/desktop/gnome, gcc-4.5.3,
> glibc-2.13-r4, 3.2.1-gentoo-r2 x86_64)
> =================================================================
> System uname:
> Linux-3.2.1-gentoo-r2-x86_64-Intel-R-_Core-TM-_i5-2500K_CPU_@_3.30GHz-with-gentoo-2.0.3
> Timestamp of tree: Wed, 22 Feb 2012 00:30:01 +0000
> distcc 3.1 x86_64-pc-linux-gnu [disabled]
> app-shells/bash:          4.1_p9
> dev-java/java-config:     2.1.11-r3
> dev-lang/python:          2.7.2-r3, 3.2.2
> dev-util/cmake:           2.8.6-r4
> dev-util/pkgconfig:       0.26
> sys-apps/baselayout:      2.0.3
> sys-apps/openrc:          0.9.8.4
> sys-apps/sandbox:         2.5
> sys-devel/autoconf:       2.13, 2.68
> sys-devel/automake:       1.10.3, 1.11.1
> sys-devel/binutils:       2.21.1-r1
> sys-devel/gcc:            4.5.3-r1
> sys-devel/gcc-config:     1.4.1-r1
> sys-devel/libtool:        2.4-r1
> sys-devel/make:           3.82-r1
> sys-kernel/linux-headers: 3.1 (virtual/os-headers)
> sys-libs/glibc:           2.13-r4

Wich version of xorg-server and nvidia-drivers you use?
Comment 75 Ira Moss 2012-02-22 13:54:36 UTC
I supposed  I should be more specific..


I "was" running (in addition to the above)  


X.Org X Server 1.11.2
Release Date: 2011-11-04
Nvidia - 290.10


I still had the same problems mentioned.


Now I'm back to running...

X.Org X Server 1.10.4
Release Date: 2011-08-19
Nvidia 275.09.0


My gnome-terminal would always hit 100% CPU after exiting it.  I would have to kill the process manually.  Now that I've downgraded, the problem has ceased.

thanks,

Ira.
Comment 76 Dmitry Suloev 2012-02-22 13:59:40 UTC
(In reply to comment #75)
> I supposed  I should be more specific..
> 
> 
> I "was" running (in addition to the above)  
> 
> 
> X.Org X Server 1.11.2
> Release Date: 2011-11-04
> Nvidia - 290.10
> 
> 
> I still had the same problems mentioned.
> 
> 
> Now I'm back to running...
> 
> X.Org X Server 1.10.4
> Release Date: 2011-08-19
> Nvidia 275.09.0
> 
> 
> My gnome-terminal would always hit 100% CPU after exiting it.  I would have to
> kill the process manually.  Now that I've downgraded, the problem has ceased.
> 
> thanks,
> 
> Ira.

Strange. I don't have this problem anymore.
I use this versions:
[ebuild   R    ] x11-drivers/nvidia-drivers-295.20-r1  USE="acpi gtk (multilib) -custom-cflags" 0 kB
[ebuild   R    ]  x11-base/xorg-server-1.11.4  USE="nptl udev xorg -dmx -doc -ipv6 -kdrive -minimal -static-libs -tslib -xnest -xvfb" 0 kB
Comment 77 Mehmet Giritli 2012-02-22 14:11:22 UTC
Hi Ira,

As I mentioned in my comment 69 above, you are not alone. I have the exact same situation. Checking with nvidia support (link at comment 9), it seems that this bug doesn't happen with the new gnome 3 and only with gnome 2. So the feeling I get is that it is seen as obsolete by nvidia.
Comment 78 Ira Moss 2012-02-23 01:19:03 UTC
Suloev, OK, I can certainly try 295.20/1.11.4   I had not tried ~amd64 on this set of packages yet (most of my system is stable, but a few packages here/there are not) (290.12


Mehmet... Have you tried the unstable ones yet...


I won't be able to try these changes until Friday night on this particular host....

But.. I will post back if this solved the problem for me as well.

Suloev, thanks for the package specifics... I'll try Friday night.  I had only been using:  

Stable for AMD64, wrt bug #394399



Ira.
Comment 79 Mehmet Giritli 2012-02-23 03:03:08 UTC
Yes, it does not make a difference.
Comment 80 Pacho Ramos gentoo-dev 2012-02-23 12:32:42 UTC
In my case I still suffer this on my account on a different machine, but it doesn't affected to newly created user accounts => try with a new created user account on a fresh home
Comment 81 Ira Moss 2012-02-25 15:07:08 UTC
(In reply to comment #80)
> In my case I still suffer this on my account on a different machine, but it
> doesn't affected to newly created user accounts => try with a new created user
> account on a fresh home



OK, Pacho's comments about new users had me intrigued.    I was thinking some type of corrupted "." files... So, I did my emerge --sync last night, and removed my masks for xorg-server and nvidia, and now I'm back at...


emerge -vp xorg-server nvidia-drivers

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] x11-base/xorg-server-1.11.2-r2  USE="ipv6 kdrive nptl udev xorg -dmx -doc -minimal -static-libs -tslib -xnest -xvfb" 0 kB
[ebuild   R    ] x11-drivers/nvidia-drivers-290.10  USE="acpi gtk (multilib) -custom-cflags" 0 kB



and then also did a:
qlist -I -C x11-driver | grep -v nvid | xargs emerge -1


and... I expected to have the same problems before I started to remove .g* or .c* files.... but....

now everything is working?

I'm at the same xorg-server and nvidia-drivers I was at before.  Maybe my re-emerge of x11-drivers (qlist -I -C x11-driver) took care of this?????



Sooo... maybe those of you still having this issue... try that?

qlist -I -C x11-driver | xargs emerge -1
Comment 82 Doug Goldstein gentoo-dev 2012-03-08 04:58:58 UTC
My understanding is this is related to bug #353224 and how that was being worked around. I'd be willing to bet most people with the issue had glibc-2.13. Not sure I understand the new user issue but it will take a bit for people not using --as-needed or who got it added after they built certain components and have not rebuilt them yet to fully get this resolved.
Comment 83 Ira Moss 2012-03-20 18:27:12 UTC
Hmm, found an interesting thing yesterday.

I had posted earlier that "MY" solution was that I had re-installed all my x11-drivers...   As after I un-installed, re-installed.  My problem had gone away.

update...

The other day, I noticed for some odd reason my opengl wasn't using nvidia, but rather xorg-x11.  I did my eselect statement to change it back, and funny... the gnome-terminal (along with a few other things... gnome-screenshot) are back up to pegging the CPU again.   When I change my opengl back to X11.. it goes away.


Soo... hm, I'll do some digging, but I'm thinking a new bug id is order...?  i.e. my problem was NEVER solved, it appears (in my case) to simply be related to if opengl is using nvidia or x11.  if it's using nvidia, my problem with the high cpu is baaaack.
Comment 84 sphakka 2012-03-21 11:07:57 UTC
Gkrellm's GPU sensors broken again by nvidia-295.20.r1.
I suggest reopening this bug.
Comment 85 Pacho Ramos gentoo-dev 2012-03-21 11:21:50 UTC
Better open a new one
Comment 86 Ira Moss 2012-03-22 00:21:04 UTC
For purposes of my opengl discovery...

https://bugs.gentoo.org/show_bug.cgi?id=409247

Was opened.
Comment 87 sphakka 2012-03-22 08:36:01 UTC
(In reply to comment #85)
> Better open a new one

OK, no need actually, as gkrellm's issues are already tracked in Bug 387079.