|Summary:||x11-drivers/nvidia-drivers-100.14.09: Black screen after exiting X|
|Product:||Gentoo Linux||Reporter:||Denilson Sá <denilsonsa>|
|Component:||Current packages||Assignee:||X11 External Driver Maintainers <x11-drivers>|
|Package list:||Runtime testing required:||---|
Description Denilson Sá 2007-07-25 14:43:01 UTC
I've just emerged x11-drivers/nvidia-drivers-100.14.09 (now marked stable), but I don't think it is stable. With this new driver, sometimes, when exiting X, the screen goes black. It was supposed to return to text-mode console (I don't use xdm/gpm/kdm, I use plain console without framebuffer and use startx), but shows a black screen. The system is still functional, I can hear beeps when I type things in console, I can ssh into it and see the CPU usage is pretty low, but I can see nothing on screen. I haven't tried to run startx again, just after the screen gone black. In two days running this nvidia-driver version, this bug happened three times. This has happened when exiting from both Beryl and Fluxbox, so this issue is independent of window manager. Probably you're going to mark this bug as UPSTREAM (and yes, I'm going to submit it to email@example.com). But you marked this package as stable, and, in my opinion, it isn't. I'm going to add this version to package.mask and install 1.0.9639, which (even not stable) worked flawlessly. Pentium III 800MHz GeForce FX 5500 Asus CUV4X (motherboard) vanilla kernel 126.96.36.199
Comment 1 Denilson Sá 2007-07-25 14:44:32 UTC
Created attachment 125981 [details] nvidia-bug-report.log
Comment 2 Denilson Sá 2007-07-25 15:03:18 UTC
Fast response from nvidia guy: "100.14.09 is no longer supported. Please test with 100.14.11." So, I'm going to test 100.14.11 for a few days.
Comment 3 Doug Goldstein 2007-07-25 15:19:35 UTC
There are 3 different series of drivers that nVidia provides. 71xx, 96xx, 100.xx.yy Your card is supported by 96xx and 100.xx.yy, it's at your discretion which version to use. Each driver version does it's own thing and works in it's own way. It's up to you as the user to pick the version of nvidia-drivers that works best for you. Since they are closed source there really is nothing we can do to tweak them. While you have an issue with 100.14.09, there are many more users out there using 100.14.09 just fine. If we waited to stable a package like this (a binary only package) until every user didn't experience any issues, we would never have a stable version. The reality of the situation does suck but that's where nVidia puts us. With regard to nVidia telling you 100.14.09 is no longer supported. Until they can reply to my e-mail that asks why does 100.14.11 cause a lockup on 2 out of the 6 video cards I have to test and why their forums are flooded with comments that state that 100.14.11 cause system lock ups and 100.14.09 work fine, then I can't reasonably commit 100.14.11 to stable.
Comment 4 Denilson Sá 2007-07-26 00:10:18 UTC
The following message has been just sent to nvidia. I'm posting here to let other users know what happens. I guess someone else in world might find this bug someday, and I think it is important to let it well documented. I've installed 100.14.11 today and left the computer running during the day. I could start and close X lots of times without problems (I also could with 100.41.09). But, eventually, the monitor screen became black when X exited (as happened with 100.41.09). So, I can say the bug is still there, in latest 100.14.11 version. Since the bug is "random", it might take some time until it occurs. Also, I'm not attaching another nvidia-bug-report.log, because there are not significant changes (just driver changed), and because I forgot to make one. :) (actually, it is quite difficult to do that when you can't see what you are doing) I've tried to startx after the monitor went black, and it worked. But, when X exited again, the screen became black again. I left the screen black for some time, and I noticed the power-saving function of text-mode terminal worked, because after some minutes, the monitor led started to blink. But, again, the screen was still black, even after returning power-save. I forgot to test pressing ctrl+alt+F[1-6] while inside X. I don't know if the bug may or may not influence this. Now I'm back to 1.0.9639 driver.
Comment 5 Jesse Ruffin 2007-07-30 03:30:47 UTC
Comment 6 Denilson Sá 2007-07-30 03:42:36 UTC
(In reply to comment #5) > How to reproduce: > 1. Start an X terminal. > 2. Switch off of X. > 3. Switch back. I'm used to switching terminals (ctrl+alt+F[1-8]) and I can't reproduce this problem. I haven't tested this with 100.14.x drivers. Well, many nvidia-related problems can't be easily reproduced, specially on different systems and different hardware. Also, note that my original issue with 100.14.09 and 100.14.11 drivers happened when I exited X. So, your solution "killall X" wouldn't work.
Comment 7 christian 2007-07-30 23:36:34 UTC
i've encountered about same bug... things work ok if only one x session is running, but i sometimes have two or more going for various reasons. if an x session is exited while another session is active, instead of dropping back to the vt from which the x session was activated, the screen goes dead (it's still on the vt which now has no activity). my monitor will usually switch off since it sees no activity. i can't switch back to another vt whether any are logged in or not, but i can switch to an active x session and then things work fine. so, to me, the 100* series are not "stable." also, 100* fails to identify my *supported* graphics card... NVIDIA GPU Unknown (Unknown) at PCI:5:0:0 (GPU-0) "unstable" 1.0.9755 works like a charm... NVIDIA GPU GeForce PCX 5750 at PCI:5:0:0 (GPU-0) i personally think all closed source binaries should always be marked unstable, and the really bad one's should be hard masked (if in portage at all). my emerge --info Portage 188.8.131.52 (default-linux/amd64/2007.0/desktop, gcc-4.1.2, glibc-2.5-r3, 2.6.20-ck1-20070714-64 x86_64) ================================================================= System uname: 2.6.20-ck1-20070714-64 x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System release 1.12.9 Timestamp of tree: Sun, 29 Jul 2007 00:00:10 +0000 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [disabled] dev-java/java-config: 1.3.7, 2.0.33-r1 dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.23b virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -finline-functions -fprefetch-loop-arrays -ftree-vectorize" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /etc/X11 /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/lib/fax /usr/share/X11/xkb /usr/share/config /var/spool/fax/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -finline-functions -fprefetch-loop-arrays -ftree-vectorize" DISTDIR="/local/distfiles" FEATURES="buildpkg distlocks metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org ftp://distro.ibiblio.org/pub/linux/distributions/gentoo/" LANG="en_US" LINGUAS="en" MAKEOPTS="--jobs=2 --quiet" PKGDIR="/local/packages64" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/local/gentoo/tmp" PORTDIR="/local/gentoo/portage" PORTDIR_OVERLAY="/local/gentoo/overlays/se /local/gentoo/overlays/xeffects /local/gentoo/overlays/xeffects-experimental" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowext 7zip X Xaw3d a52 aac aalib acl acpi aiglx alsa amd64 amr amuled apache2 apm arj arts asf audiofile avahi avi berkdb bidi bindist binfilter bitmap-fonts bl browserplugin bzip2 cairo cdda cddb cdio cdparanoia cdr cli cpudetection cracklib crypt css cups curl custom-cflags dbus device-mapper dga dio directfb divx divx4linux dlloader dmi dmx dri dts dv dvb dvd dvdr dvdread dxr3 eds emboss emerald encode erandom esd evo exif expat fam fame fat fbcon ffmpeg fftw firefox flac font-server foomaticdb fortran freetype ftp fuse gdbm ggi gif gimpprint glibc-omitfp glitz glut gmedia gmp gnome gnutls gpm grammar gstreamer gtk gtk2 gtkhtml gtkspell hal hfs httpd i8x0 iconv icq idn ieee1394 imagemagick imlib ipv6 irc isdnlog ithreads jack jack-tmpfs java jbig jfs joystick jpeg jpeg2000 justify kde kdeenablefinal kdexdeltas kerberos kqemu ladcca lame lcd lcms ldap lha libcaca libclamav libg++ libgda libvisual libwww linuxthreads-tls live lzo mad math matroska mbox mgetty midi mikmod mime mjpeg mmap mmx mng modplug motif mozbranding mozilla mp3 mp4 mpeg mplayer mudflap musepack mysql mythtv nas ncurses nls nntp nocd nptl nptlonly nsplugin ntfs nvidia objc ofx ogg oggvorbis openal opengl openmp oss ots pam pcre pdf pdflib perl perlsuid php pic pie png portaudio posix pppd profile pulseaudio python qt qt3 qt3support qt4 quicktime rar readline realmedia recode reflection reiser4 reiserfs rtc samba sdl session shared shorten slang smp sndfile socks5 sox speex spell spl sqlite sse sse2 ssl stream subtitles svg tcl tcpd test tga theora thesaurus threads threadsafe tiff tk toolbar tools transmitter truetype truetype-fonts type1-fonts udev unicode usb userlocales v4l vcd vdr vlm vorbis wmf wmp wxwindows x264 xanim xcomposite xfs xine xinerama xinetd xml xml2 xorg xprint xv xvid xvmc yahoo zip zlib" ALSA_CARDS="ens1370 intel8x0 mpu401" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" LIRC_DEVICES="hauppauge" USERLAND="GNU" VIDEO_CARDS="nv nvidia vesa" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 8 Tom Pala 2007-08-09 23:17:06 UTC
> This problem happens to me as well with the 1.0.9639 drivers. Consistently. In my case 9629 is the last release that restores text mode properly. Since 9631 EVERY time I go back from X console is left dark. To be more precise - it's not blank, but something like badly positoned in video memory. When I press enter for a while I can see some output of previous commands followed by dmesg output. > Relevant lspci -v I've tested FX5200 on two MBs (Duron with NvAGP and Sempron with amd64_agp) and 6200 (only with amd64_agp) having 32-bit systems.
Comment 9 Denilson Sá 2007-08-10 03:48:52 UTC
Not sure if this helps or if this is related, but previously I had problems with nvidia driver freezing X, and I "solved" that by disabling AGP. See details here: http://my.opera.com/CrazyTerabyte/blog/show.dml/150191 (and also on many other posts on that blog) I don't know if NvAGP setting could help to avoid some of the bugs mentioned here. (Hey, nvidia developers, are you reading this bug and that blog?)
Comment 10 Doug Goldstein 2007-08-10 13:26:33 UTC
Have all of you contacted nVidia via firstname.lastname@example.org?
Comment 11 Tom Pala 2007-08-23 07:53:12 UTC
> In my case 9629 is the last release that restores text mode properly. Since > 9631 EVERY time I go back from X console is left dark. To be more precise - > it's not blank, but something like badly positoned in video memory. When I I've found this behaviour is caused by #define VGA_CAN_DO_64KB in drivers/video/console/vgacon.c. After removing this define, that I've been using for a few years from now, the problem is almost fixed. Almost - because my initial 80x26 mode (default from boot, I didn't change anything) restores without the bottom line, only 80x25 is visible.
Comment 12 Denilson Sá 2007-08-23 20:35:09 UTC
(In reply to comment #11) > I've found this behaviour is caused by #define VGA_CAN_DO_64KB in > drivers/video/console/vgacon.c. After removing this define, that I've been > using for a few years from now Have you patched this yourself, or this define is present in gentoo ebuild or vanilla xorg source? I ask this because I use unmodified gentoo "stable" ebuilds. > Almost - because > my initial 80x26 mode (default from boot, I didn't change anything) restores > without the bottom line, only 80x25 is visible. Maybe your boot is the problem. :) I guess most machines defaults from boot to 80x25, and not 80x26. So, I think X (or whatever program that does that) restores to 80x25 because it thinks 80x25 is the correct mode.
Comment 13 Tom Pala 2007-08-24 09:13:24 UTC
> Have you patched this yourself, or this define is present in gentoo ebuild or > vanilla xorg source? It's mine define. In kernel, not xorg - it enlarges console scrollback buffer without having to move it to the system RAM and its drawbacks (VGACON_SOFT_SCROLLBACK). > Maybe your boot is the problem. :) > I guess most machines defaults from boot to 80x25, and not 80x26. So, I think X I've resolved this one too;) I use setfont -h15 iso02grf.psf and so switching from 80x25@16 lines to 80x26@15 lines. > (or whatever program that does that) restores to 80x25 because it thinks 80x25 > is the correct mode. Driver should restore all video registers as they were, with no 'thinking' about hardcoded values. Apparently nVidia forgot about some issues and assumed that some constans will not be changed. Anyway now I know it's nVidia-only bug. It's related with previous reports only in this, that nVidia for sure changed sth in restoring and has broken some configurations.
Comment 14 Chris Gianelloni (RETIRED) 2007-08-24 19:48:34 UTC
There won't be anything that we can do to resolve this. You'll have to get it fixed upstream at NVIDIA before we can do anything.
Comment 15 Tom Pala 2007-08-28 16:25:18 UTC
(In reply to comment #14) > There won't be anything that we can do to resolve this. You'll have to get it > fixed upstream at NVIDIA before we can do anything. You can confirm errors with your hardware and submit bug-report to email@example.com as I did. I don't know if they are going to do something if I'm alone.