After upgrading to kernel 2.6.13 using gentoo-sources on ~x86 (AMD Athlon 705MHz on Asus K7M) I am unable to bring up X (xorg-x11-6.8.2-r2). I have a legacy card (Geforce 256 / Hercules 3D Prophet board) installed, so I am unable to switch to the latest Nvidia drivers which some people reported to work just fine. Latest available drivers for me are: nvidia-kernel-1.0.7174 with nvidia-glx-1.0.7174-r5. These work fine up to at least gentoo-sources-2.6.12-r9 (haven't tried r10 yet but I don't see any reason why they should not work there, too). However, the nvidia module is loaded properly during bootup. At the end X tries to start and stops with an error message saying that several screen configurations have been found but none of them have a usable configuration. Reproducible: Always Steps to Reproduce: Expected Results: Xorg should have started. Using the "startx" command tries to load the nvidia module once more resulting in the same error message.
Just tested 2.6.13 with nv driver (as provided by Xorg) instead of nvidia. nv works, nvidia not.
Please attach the output of your Xorg log as well as `dmesg`.
Created attachment 67383 [details] output of dmesg
Created attachment 67385 [details] Xorg Log
Created attachment 67386 [details] emerge info output
My situation is similar: * system: P3 800 Mhz, nVidia Vanta video board. * kernel 2.6.12.2/ xorg-x11-6.8.2-r2/nvidia-kernel-1.0.6629-r4 works ok * kernel 2.6.13/ xorg-x11-6.8.2-r2/nvidia-kernel-1.0.6629-r4, the kernel loads the module, but xorg stops (xorg log attached) * nvidia doesn't work, nv (as provided by xorg) does
The situation is getting weirder here. I was just booting 2.6.13 for a dmesg output an Xorg.log as X came up just fine. A second boot, no change. I've also upgraded three packages to the following versions before: udev-068 sdl-sound-1.0.1-r1 wxGTK-2.6.1 I'll let you know if I find some reason for this strange behaviour.
I can confirm this behaviour for the current x86 nvidia-{kernel,glx} versions (1.0.6629), though ~x86 (1.0.7676) works (but stalls Xorg after a few hours with my "nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev a1)"). To get 1.0.6629 (and possibly also the reported 1.0.7174) to work, check this forum thread [1] for a solution. The mentioned shell script creates the missing device nodes and can be put in (or called from) /etc/conf.d/local.start . [1] http://forums.gentoo.org/viewtopic-t-375466.html
As some sort of additional info, this is *not* a problem for me. Relevant software versions are: udev-068, xorg-x11-6.8.99.15, nvidia-kernel-1.0.7676, nvidia-glx-1.0.7676-r1, gentoo-sources-2.6.13 This is with a Geforce 6800 video card.
"* kernel 2.6.12.2/ xorg-x11-6.8.2-r2/nvidia-kernel-1.0.6629-r4 works ok * kernel 2.6.13/ xorg-x11-6.8.2-r2/nvidia-kernel-1.0.6629-r4, the kernel loads the module, but xorg stops (xorg log attached) * nvidia doesn't work, nv (as provided by xorg) does" I'm experiencing the exact same thing as commenter #6; same versions and all.
Could some people confirm the fix in comment #8?
(In reply to comment #11) > Could some people confirm the fix in comment #8 confirmed. when I boot kernel 2.6.12.2 the nodes are created. when I boot 2.6.13 they are not. after creating the nodes (kernel 2.6.13) it works again. I don't know if nvidia-kernel-1.0.6629-r4 were fixed by this. I upgraded to nvidia-kernel-1.0.7174 because some people reported build 7174 worked for them. Not my case. In my case 7174 only worked after nodes were created by the script.
I can confirm comment #8's fix as well. The legacy nvidia drivers didn't create the device nodes. Manually creating them fixed the problem.
I had RC_DEVICE_TARBALL="yes" set. This was what made Xorg suddenly working with 2.6.13 with nvidia-kernel-1.0.7174. The nodes had just been saved from a prior 2.6.12 boot. So, it looks like a "missing device nodes" here, too.
I had a brief chat with one of the kernel developers on the Gentoo team and, if I understand him correctly, apparently sysfs is now "strictly GPL-only". This would explain the problem because if a device is not shown by sysfs then udev will not create or manage its device nodes. And the nvidia driver core is neither open nor licensed under the GPL. I've no idea which patch(es) introduced this change, when or the reasoning behind it but I'm assuming that it was done quite deliberately and that it is not going to be reverted. If that assumption is correct then I suppose we're just going to have to accept that something else is going to have to be responsible for creating the nodes. I'm not entirely sure, but I think the very newest drivers do (or will) create the nodes automatically of their own accord. After all, I'm sure nvidia are well aware of the problem. For now, I'm creating the nodes in /etc/conf.d/local.start as I suspect almost everyone else is. mknod /dev/nvidiactl c 195 255 mknod /dev/nvidia0 c 195 0 chown root:video /dev/nvidia* chmod 0660 /dev/nvidia* I suppose we (nvidia users) are just going to have to wait and see how the situation pans out. At least there appear to be no problems other than the aformentioned one. I'm using a Riva TNT2 with 2.6.13-ck1, nvidia-kernel-1.0.7167-r1 and the necessary workaround. Furthermore, I use (and have always used) the RC_DEVICE_TARBALL="no" setting. It appears to be perfectly reliable.
As I mentioned earlier, 1.0.7676 (current ~x86) _does_ work for me on 2.6.13 and creates the necessary device nodes. Whatever kernel interface changes are mentioned in comment #15, this version seems to keep up with them (though it seems to be unstable with my pretty old GeForce2 MX, Xorg stalls after an hour or so); maybe the nvidia people will be so kind to backport whatever they changed to accommodate the kernel changes. Did I ever mention binary drivers suck? I only use this one because it does a quite better job in 2D acceleration (tvtime video overlay, scaling...) than the Xorg nv driver, which is essential for me as my Athlon 700 does not give me an usable frame rate when watching TV while using nv... *sigh* (And, yes, I'm not even mentioning 3D acceleration.)
Comment #15 probably refers to this patch that changed the sysfs export symbols to GPL only: http://lwn.net/Articles/104392/
Also confirmed fix in comment #8. Please note that there is already a script /sbin/NVmakedevices.sh which you can call from your /etc/conf.d/local.start like so: if [ ! -e /dev/nvidia0 ]; then /sbin/NVmakedevices.sh fi
kernel 2.6.13/ xorg-x11-6.8.2-r2/nvidia-kernel-1.0.6629-r4 here. It doesnt work either on RC_DEVICE_TARBALL="yes" or RC_DEVICE_TARBALL="no" so... no way for fixing it ?? :(
Look one comment up...
I have kernel 2.6.13-r3 and the latest 7676 drivers on my AMD64 system. I have this same problem, and I don't have /sbin/NVmakedevices.sh so I can't try to see if that works.
Look at the forum entry in comment #8.
Since 2.6.13 the interface class_simple has been renamed, because it became the default IF (instead of the artifice, it original was, see http://www.kerneltraffic.org/kernel-traffic/kt20040120_248.html#3). The intention of this IF is to communicate by /sys with udev, this way it knows which device nodes it should make. The nvidia kmod uses this IF, and as of 2.6.13, it won't get compiled in (at least in the 1.0.6629-r4 version), because the IF ceases to exist for as far the module is aware of.So this is why the problem occurs as of 2.6.13. Since version 7667 and 7676, don't come up with !$ grep class_simple nv.c! I'm guessing these are updated with the new IF (comment #8 and #9 pretty much confirms this). So backporting these changes will solve this (I took the /etc/conf.d/local.start approach, because of time issues)...
If someone wants to do the port go ahead; chances are some of the changes required may be rather large. As far as I'm concerned, a workaround exists and this is nVidia's problem. Maybe we should add these instructions to the docs. Adding swift to CC so he can decide. Also note that some people in the forum are having better luck with newer versions of udev.
Just as a check point On my amd64 machine upgraded to 2.6.13 kernel, udev-0.68, neither 6629-r4 nor (unstable ~amd64) 7676 nvidia driver create /dev/nvidia and /deb/nvidiactrl when the module is loaded, even when the module is autoloaded on boot. Workaround with a script is of course possible, as well as manual creation of devices, but I guess this was not a point of me upgrading to brand new (for me) udev system
(In reply to comment #23) > Since 2.6.13 the interface class_simple has been renamed, because it became the > default IF (instead of the artifice, it original was, see > http://www.kerneltraffic.org/kernel-traffic/kt20040120_248.html#3). The > intention of this IF is to communicate by /sys with udev, this way it knows > which device nodes it should make. The nvidia kmod uses this IF, and as of > 2.6.13, it won't get compiled in (at least in the 1.0.6629-r4 version), because > the IF ceases to exist for as far the module is aware of.So this is why the > problem occurs as of 2.6.13. > > Since version 7667 and 7676, don't come up with !$ grep class_simple nv.c! > I'm guessing these are updated with the new IF (comment #8 and #9 pretty much > confirms this). > > So backporting these changes will solve this (I took the /etc/conf.d/local.start > approach, because of time issues)... 7676 does not work on my 2.6.13 amd64 machine as well
Well the user emerging nvidia-kernel and nvidia-glx already knows that it's not GPL and has obviously decided to go through with it. We're going to have to accept that udev won't play nicely, but we shouldn't punt and make the user have to search for this bug and copy and paste a script into /etc/conf.d/local.start. Why not add a little script to /etc/init.d/ and add it to the boot runlevel instead? It's still kludgy but at least we do the work and the user doesn't have to look at the kludge every time he runs etc-update.
Thank you, Ryan, exactly. I (being not an expert) feel that expecting/forcing binary non-GPL drivers to create directly their own devices bypassing sysfs/udev is perhaps even less appropriate than allowing them to communicate with sysfs. And I don't think users doing it manually will be consistent in properly restrictive ownership/permissions. So the device creation for non-GPL drivers will have to be taken care by ebuild maintainers. Will it result in init script for every non-GPL driver present :( ?
I've had exactly the same problems with nvidia-kernel-1.0.6629-r4 and 2.6.13 (gentoo and vanilla sources). After upgrading to nvidia-kernel-1.0.7676 and nvidia-glx-1.0.7676-r1 X seems to work again (at least for the last 30 minutes). I'm using udev-0.70 [RC_DEVICE_TARBALL="no"] and a 'GeForce3 Ti 200' card. Portage 2.0.51.22-r3 (default-linux/x86/2005.0, gcc-3.3.6, glibc-2.3.5-r2, 2.6.13.4 i686) ================================================================= System uname: 2.6.13.4 i686 AMD Athlon(tm) XP 2400+ Gentoo Base System version 1.6.13 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.5-r2, 2.4.1-r1 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-xp -mmmx -msse -m3dnow -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -mmmx -msse -m3dnow -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp://gd.tuwien.ac.at/opsys/linux/gentoo/ " LANG="en_US.utf8" LC_ALL="en_US.utf8" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowext X aalib alsa apm arts avi berkdb bitmap-fonts bzlib cdr crypt cups curl dbus divx4linux dvd dvdr emboss encode esd firefox foomaticdb fortran gd gdbm gif gnome gphoto2 gpm gstreamer gtk gtk2 guile hal imagemagick imlib ipv6 java jpeg junit libg++ libwww mad mikmod mmx mmxext motif mp3 mpeg ncurses nls nsplugin nvidia ogg oggvorbis opengl oss pam pdflib perl plotutils png python readline ruby sdl slang speex spell sqlite sse ssl svga tcltk tcpd tiff truetype truetype-fonts type1-fonts udev unicode usb vorbis win32codecs xine xml xml2 xmms xv xvid zlib video_cards_radeon userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LDFLAGS, LINGUAS
By the way: I'm using xorg-x11-6.8.2-r4
I'm having the same troubles. the nvidia module just won't start when using 2.6.13-gentoo-r3. I've tried to upgrade nvidia-kernel and nvidia-glx and nvidia-kernel to the latest version (media-video/nvidia-kernel-1.0.7676) but it still didn't work, this is what the Xorg log says: (EE) NVIDIA(0): Failed to obtain a shared memory identifier. (II) NVIDIA(0): Using the NVIDIA 2D acceleration architecture (==) NVIDIA(0): Backing store disabled (==) NVIDIA(0): Silken mouse enabled (II) Loading extension NV-CONTROL *** If unresolved symbols were reported above, they might not *** be the reason for the server aborting. Fatal server error: Caught signal 11. Server aborting -- I'm using a 'GeForce4 MX 440' videocard
(In reply to comment #31) > I'm having the same troubles. the nvidia module just won't start when using > 2.6.13-gentoo-r3. I've tried to upgrade nvidia-kernel and nvidia-glx and > nvidia-kernel to the latest version (media-video/nvidia-kernel-1.0.7676) but it > still didn't work, this is what the Xorg log says: > > (EE) NVIDIA(0): Failed to obtain a shared memory identifier. > (II) NVIDIA(0): Using the NVIDIA 2D acceleration architecture > (==) NVIDIA(0): Backing store disabled > (==) NVIDIA(0): Silken mouse enabled > (II) Loading extension NV-CONTROL > > *** If unresolved symbols were reported above, they might not > *** be the reason for the server aborting. > > Fatal server error: > Caught signal 11. Server aborting > > -- > I'm using a 'GeForce4 MX 440' videocard Oops, I've seem to forget that 'System V IPC' was needed for the nvidia driver to work. Now i've enabled it and upgraded to the new nvidia drivers, it works!
closing as user reports fixed.
I am sorry, but I cannot consider this bug to be resolverd neither closed. I use a Nforce chiset (with integrated GEFORCE2) and therefore Nvidia drivers above 7174 do not support my GPU. So I am stuck to 7174. I know the workaround, but this is not clean. Udev or Nvidia ebuild should take care of this.
I agree with Pierre/comment #34. For me this one is not FIXED either: Newer nvidia driver releases are very unstable if used with my GeForce2 MX hardware and tend to freeze X11 here.
I don't see why the bug is closed as fixed. I don't think comment 31 and 32 described the same problem as the original one. At least for me on amd64 architechture there is no combination of nvidia drivers (including ~amd64) and udev version which would automatically create nvidia devices. This is a bug.
Perhaps FIXED is incorrect, it should say CANTFIX. We have no controll over nvidia's release policy... as for what to do if you have old hardware, just mask out newer versions by placing entries in /etc/portage/package.mask As for the other problems not associated with this bug, please open other bug reports for those problems if you're still having issues. Please don't clutter bug reports with unrelated issues, thanks.
Same here, I'm stuck to 6xxx thanks to nvidia abandoning support for my card somewhere in 7xxx. (GeForce 256) So bad nvidia leaves us naked; not supported anymore, but drivers/documentation not freed either. Not that I'm going to buy anything from nvidia again, unless they radically change their way of doing things.
Fails on 2.6.15 from emerge as well. Same hardware works with Arch
Hmm, i'm using gentoo-sources-2.15-r5, nvidia-kernel-1.0.8178-r3 and xorg-x11-6.8.2-r6 with a GeForce3-Ti-200 and everything seems to work fine ... Portage 2.0.54 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5-r2, 2.6.15-gentoo-r5 i686) ================================================================= System uname: 2.6.15-gentoo-r5 i686 AMD Athlon(tm) XP 2400+ Gentoo Base System version 1.6.14 dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-xp -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.inode.at/ " LANG="en_US.utf8" LC_ALL="en_US.utf8" LINGUAS="de en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowext X a52 aalib alsa apm audiofile avi berkdb bitmap-fonts bonobo bzip2 bzlib cairo cdr crypt css cups curl dbus divx4linux dts dv dvd dvdr dvdread emboss encode esd evo exif expat fam fame ffmpeg firefox flac foomaticdb fortran gd gdbm gif glut gmp gnome gphoto2 gpm gstreamer gtk gtk2 gtkhtml guile hal idn imagemagick imlib ipv6 java jpeg junit lcms libg++ libwww mad mikmod mmx mmxext mng motif mp3 mpeg nautilus ncurses nls nptl nsplugin nvidia ogg oggvorbis openal opengl pam pcre pdflib perl plotutils png python quicktime readline real ruby sdl slang speex spell sqlite sse ssl subtitles svga tcltk tcpd tetex theora tiff truetype truetype-fonts type1-fonts udev unicode usb vcd vorbis win32codecs xine xml xml2 xmms xv xvid zlib linguas_de linguas_en userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LDFLAGS
Created attachment 80607 [details] Xorg.log
It does not work here though my setup seems very similar Intel EM64T Nvidia 6800GTO (a special version that support Apple HD 30" montior with 2560x1600) gentoo-sources-2.6.15-r5, (SMP) nvidia-kernel-1.0.8178-r3 xorg-x11-6.8.2-r6 and xorg-x11-7.0-r1 the machine hangs during startx. Xorg.0.log *always* shows "resources ranges after preInit:" follow by 42 resources and then it hangs.... (attached) (In reply to comment #40) > Hmm, i'm using gentoo-sources-2.15-r5, nvidia-kernel-1.0.8178-r3 and > xorg-x11-6.8.2-r6 with a GeForce3-Ti-200 and everything seems to work fine ... > > Portage 2.0.54 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5-r2, > 2.6.15-gentoo-r5 i686)
