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.
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.
Note: there is nothing of interest in dmesg, ~/.xsession-errors, or /var/log/Xorg.0.log
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.
(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
under gnome-2.32, gnome-session, fusion-icons, and blueman also affected by this issue.
That one bit me too under latest gnome in tree.
Can anyone report this to nvidia? http://www.nvnews.net/vbulletin/forumdisplay.php?f=14 Thanks
*** Bug 375881 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > Can anyone report this to nvidia? Done: http://www.nvnews.net/vbulletin/showthread.php?p=2458342
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.
Workaround that works for me: emerge -av =x11-drivers/nvidia-drivers-275.09.07
*** Bug 376171 has been marked as a duplicate of this bug. ***
The nvidia certified version 275.21 also has this problem
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.
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!
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.
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.
*** Bug 376805 has been marked as a duplicate of this bug. ***
I can reproduce it too on my laptop.
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.
I can confirm this problem with gnucash in kde4.7. Supridingly, if I run "strace gnucash", it shuts down fine!
"strace gnucash" works for me too (KDE 4.6.3) : I can close it properly
New "official" nvidia-drivers 280.13 doesn't fix this bug
(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.
(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.
(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!
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
(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.
(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 ?
(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).
(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)".
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.
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)
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.
(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.
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
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.
(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.
Has anybody contacted NVIDIA already? I mean, not through forums...
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).
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 :)
(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.
Had the same bug (http://www.nvnews.net/vbulletin/showthread.php?t=164775) and compiling cairo with USE="-opengl" fixes the problem for me
(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?
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.
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.
(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.
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 :)
(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.
(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?
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.
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.
(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
(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.
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
(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.
> 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.
Maybe the problem with the new kernel (linux 3.1.0-rc8)?
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.
(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.
(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.
(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
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)
(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.
@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 ...
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
(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)
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.
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.
(In reply to comment #68) > ( XFCE 4 ) I forgot to mention: Plain TWM : the same.
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.
This wery old bug. Problem fixed in new version. Plz, update your system.
(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
(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?
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.
(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
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.
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.
Yes, it does not make a difference.
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
(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
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.
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.
Gkrellm's GPU sensors broken again by nvidia-295.20.r1. I suggest reopening this bug.
Better open a new one
For purposes of my opengl discovery... https://bugs.gentoo.org/show_bug.cgi?id=409247 Was opened.
(In reply to comment #85) > Better open a new one OK, no need actually, as gkrellm's issues are already tracked in Bug 387079.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dc2da66d1d3d2d0ec26eebd4301c3782d5659788 commit dc2da66d1d3d2d0ec26eebd4301c3782d5659788 Author: Aliaksei Urbanski <aliaksei.urbanski@gmail.com> AuthorDate: 2024-04-03 14:16:23 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2024-04-03 17:44:11 +0000 media-libs/libavif: add ~mips to the KEYWORDS These changes also fix pkgcheck warnings: - enable dav1d by default for big-endian arches - remove redundant `unset __GL_NO_DSO_FINALIZER` - replace deprecated virtual/jpeg with media-libs/libjpeg-turbo Bug: https://bugs.gentoo.org/375615 Closes: https://bugs.gentoo.org/918451 Signed-off-by: Aliaksei Urbanski <aliaksei.urbanski@gmail.com> Closes: https://github.com/gentoo/gentoo/pull/35823 Signed-off-by: Michał Górny <mgorny@gentoo.org> media-libs/libavif/libavif-0.10.1.ebuild | 18 +++++------------- media-libs/libavif/libavif-0.11.1.ebuild | 14 +++----------- media-libs/libavif/libavif-1.0.4.ebuild | 14 +++----------- media-libs/libavif/libavif-9999.ebuild | 12 ++---------- profiles/features/big-endian/package.use | 7 +++++++ 5 files changed, 20 insertions(+), 45 deletions(-)
