Unknown symbols are used by nvidia-kernel. The log says: Nov 24 13:29:01 omc-2 [ 112.677286] Adding 1004052k swap on /dev/sda3. Priority:-1 extents:1 across:1004052k Nov 24 13:29:01 omc-2 [ 115.795192] nvidia: module license 'NVIDIA' taints kernel. Nov 24 13:29:01 omc-2 [ 115.795490] nvidia: Unknown symbol register_ioctl32_conversion Nov 24 13:29:01 omc-2 [ 115.795526] nvidia: Unknown symbol unregister_ioctl32_conversion < *SNIP* > Nov 24 13:29:14 omc-2 [ 136.618256] nvidia: Unknown symbol register_ioctl32_conversion Nov 24 13:29:14 omc-2 [ 136.618300] nvidia: Unknown symbol unregister_ioctl32_conversion Nov 24 13:29:14 omc-2 modprobe: FATAL: Error inserting nvidia (/lib/modules/2.6.14-gentoo-r2/video/nvidia.ko): Unknown symbol in module, or unknown parameter (see dmesg) Nov 24 13:29:16 omc-2 gdm[7312]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0 Nov 24 13:29:19 omc-2 [ 140.882760] nvidia: Unknown symbol register_ioctl32_conversion Nov 24 13:29:19 omc-2 [ 140.882804] nvidia: Unknown symbol unregister_ioctl32_conversion Nov 24 13:29:19 omc-2 modprobe: FATAL: Error inserting nvidia (/lib/modules/2.6.14-gentoo-r2/video/nvidia.ko): Unknown symbol in module, or unknown parameter (see dmesg) Nov 24 13:29:20 omc-2 gdm[7380]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0 Nov 24 13:29:23 omc-2 [ 145.151901] nvidia: Unknown symbol register_ioctl32_conversion Nov 24 13:29:23 omc-2 [ 145.151944] nvidia: Unknown symbol unregister_ioctl32_conversion Nov 24 13:29:23 omc-2 modprobe: FATAL: Error inserting nvidia (/lib/modules/2.6.14-gentoo-r2/video/nvidia.ko): Unknown symbol in module, or unknown parameter (see dmesg) Nov 24 13:29:24 omc-2 gdm[7475]: gdm_slave_xioerror_handler: Fatal X error - Restarting :0 Nov 24 13:29:24 omc-2 gdm[7310]: deal_with_x_crashes: Running the XKeepsCrashing script Nov 24 13:29:28 omc-2 gdm[7310]: Failed to start X server several times in a short time period; disabling display :0 Nov 24 13:29:31 omc-2 [ 153.082256] nvidia: Unknown symbol register_ioctl32_conversion Nov 24 13:29:31 omc-2 [ 153.082299] nvidia: Unknown symbol unregister_ioctl32_conversion Nov 24 13:29:31 omc-2 modprobe: FATAL: Error inserting nvidia (/lib/modules/2.6.14-gentoo-r2/video/nvidia.ko): Unknown symbol in module, or unknown parameter (see dmesg) Nov 24 13:29:32 omc-2 gdm[7609]: gdm_slave_xioerror_handler: Fatal X error - Restarting :1 Nov 24 13:29:35 omc-2 [ 157.342945] nvidia: Unknown symbol register_ioctl32_conversion Nov 24 13:29:35 omc-2 [ 157.342988] nvidia: Unknown symbol unregister_ioctl32_conversion Nov 24 13:29:35 omc-2 modprobe: FATAL: Error inserting nvidia (/lib/modules/2.6.14-gentoo-r2/video/nvidia.ko): Unknown symbol in module, or unknown parameter (see dmesg) Nov 24 13:29:36 omc-2 gdm[7655]: gdm_slave_xioerror_handler: Fatal X error - Restarting :1 Nov 24 13:29:40 omc-2 [ 161.608611] nvidia: Unknown symbol register_ioctl32_conversion Nov 24 13:29:40 omc-2 [ 161.608654] nvidia: Unknown symbol unregister_ioctl32_conversion Nov 24 13:29:40 omc-2 modprobe: FATAL: Error inserting nvidia (/lib/modules/2.6.14-gentoo-r2/video/nvidia.ko): Unknown symbol in module, or unknown parameter (see dmesg) Nov 24 13:29:41 omc-2 gdm[7310]: deal_with_x_crashes: Running the XKeepsCrashing script Nov 24 13:29:41 omc-2 gdm[7713]: gdm_slave_xioerror_handler: Fatal X error - Restarting :1 Nov 24 13:29:42 omc-2 hald[6861]: Timed out waiting for hotplug event 946. Rebasing to 948 Nov 24 13:29:43 omc-2 gdm[7310]: Failed to start X server several times in a short time period; disabling display :1 Nov 24 13:29:46 omc-2 hald[6861]: Timed out waiting for hotplug event 950. Rebasing to 952 Nov 24 13:29:48 omc-2 hald[6861]: Timed out waiting for hotplug event 954. Rebasing to 956 Nov 24 13:29:50 omc-2 login(pam_unix)[7267]: session opened for user root by LOGIN(uid=0) Nov 24 13:29:50 omc-2 hald[6861]: Timed out waiting for hotplug event 958. Rebasing to 960 Nov 24 13:29:52 omc-2 hald[6861]: Timed out waiting for hotplug event 962. Rebasing to 964 Nov 24 13:29:54 omc-2 hald[6861]: Timed out waiting for hotplug event 966. Rebasing to 968 Nov 24 13:29:58 omc-2 hald[6861]: Timed out waiting for hotplug event 970. Rebasing to 972 Nov 24 13:30:00 omc-2 hald[6861]: Timed out waiting for hotplug event 974. Rebasing to 976 Nov 24 13:30:01 omc-2 cron[7858]: (jail) CMD (cd /home/jail/ ; ./boinc_4.32_opteron-64-linux-gnu &>/dev/null) Nov 24 13:30:01 omc-2 cron[7859]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons ) Nov 24 13:30:02 omc-2 hald[6861]: Timed out waiting for hotplug event 978. Rebasing to 980 Nov 24 13:30:04 omc-2 hald[6861]: Timed out waiting for hotplug event 982. Rebasing to 984 Nov 24 13:30:06 omc-2 hald[6861]: Timed out waiting for hotplug event 986. Rebasing to 988 Nov 24 13:30:08 omc-2 hald[6861]: Timed out waiting for hotplug event 990. Rebasing to 992 Reproducible: Always Steps to Reproduce: 1. Attempt to use nvidia-kernel with 2.6.14-gentoo-r2 2. 3. Actual Results: No X. The nvidia module couldn't load Expected Results: nvidia should load omc-2 var # emerge --info Portage 2.0.51.22-r3 (default-linux/amd64/2005.1, gcc-3.4.4, glibc-2.3.5-r2, 2.6.13-gentoo-r3 x86_64) ================================================================= System uname: 2.6.13-gentoo-r3 x86_64 AMD Opteron(tm) Processor 252 Gentoo Base System version 1.6.13 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.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib64/mozilla/defaults/pref /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="-march=k8 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://pandemonium.tiscali.de/pub/gentoo/ ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo http://mirror.gentoo.no/ http://gentoo.prz.rzeszow.pl http://ftp.du.se/pub/os/gentoo ftp://mirror.pudas.net/gentoo" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="amd64 X aac aalib alsa audiofile avi berkdb bitmap-fonts browserplugin bzip2 cdr crypt cups curl dvd dvdr dvdread eds emacs emboss encode esd exif expat fam fbcon foomaticdb fortran gdbm gif glut gnome gstreamer gtk gtk2 hal iconv imlib ipv6 java jpeg lcms ldap libwww lua lzw lzw-tiff mad mng motif mozilla mp3 mpeg ncurses nls nptl nptlonly nsplugin nvidia ogg opengl oss pam pdflib perl png python quicktime readline recode sdl slang spell ssl symlink tcltk tcpd tetex theora tiff truetype truetype-fonts type1-fonts udev unicode usb userlocales vorbis xine xml2 xmms xpm xv xvid zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTDIR_OVERLAY
Which version of nvidia-kernel do you have ?
1.0.6629
1.0.6629-r4 actually...
I have had the same problem with nvidia-kernel my system is amd64 kernel 2.6.14-r3 (gentoo-sources) nvidia-kernel 1.0.6629-r4 I switched to the unstable nvidia-kernel build ie. /etc/portage/package.keywords added: media-video/nvidia-kernel ~amd64 media-video/nvidia-glx ~amd64 media-video/nvidia-settings ~amd64 app-admin/eselect-opengl ~amd64 app-admin/eselect ~amd64 emerge -uv world --deep nvidia-kernel now works.
Correction to my previous comment, my kernel is kernel 2.6.14-r2 (gentoo-sources)
It really defies the concept of "stable" that you have to run "~AMD64" to get the latest stable kernel to work with the latest stable nvidia-kernel.
This is essentially the same problem we have with the ati-drivers (bug 113220). The dependancy on eselect is preventing a newer nvidia-glx from being marked stable. Maybe we need a revbumped version depending on opengl-update for now? As to which version needs to go stable, 7676 has worked very well for me. Any objections to 7676 going stable?
I would second 7676 going stable and it has worked well here too.
Jeremy, I apologize, I'm still not sure if you're on the x11-drivers alias. You've done the recent work on this driver so I'm adding you to the discussion. Also, I find the newest drivers fix many of the nVidia problems I've seen with a machine I maintain at school.
Third vote for 7676 here. The 1.0.7676-r1 has been stable here for a few weeks. Plays Doom III and is currently running 3 X-sessions (all 3 Enlightenments) with no problems.
> Any objections to 7676 going stable? This would not solve the problem for me. nVidia has dropped support for older chipsets (GeForce 2 and below) with the 7000 series. Everyone who still runs such a chipset has to stick with 6629.
I don't know that there is a great deal we can do about that - this is one of the bad points of depending upon a binary driver. You can always use the open source nv driver, but you will lose 3D acceleration. It would be nice if they would open up the specs for cards they no longer support. The driver maintainers will have more idea if it will be possible to backport fixes, but this may prove too difficult to maintain.
> This would not solve the problem for me. nVidia has dropped support for older > chipsets (GeForce 2 and below) with the 7000 series. > Everyone who still runs such a chipset has to stick with 6629. Is this true? Does this mean I have to stick with kernel 2.6.12.5 if I want to use glx with a GeForce2 Pro?
I'd like 7676 to go stable, but we can't until eselect goes stable (which should be soon). When that happens, eselect-opengl and nvidia-glx-1.0.7676-r2 will go stable.
After having followed Russel Chaits trick on my AMD64, to use the currently masked nvidia driver, I run into a problem that I also managed to work around. The problem is not directly nvidia related, but since it's a result from actions described here, I choose to give my feed-back here. If that's not right, then please tell me where to go. ;-) 1. I updated /etc/portage/package.keywords according to Russel. 2. In one of the ebuilds, I saw the instruction to 'eselect opengl set nvidia' which I did. 3. Recompiled the kernel, installed and rebooted. Result: Excellent! The new kernel and nvidia works well together. Problem: I broke the 'amarok' music player. amarok complains it cannot find libGL.so.1 and fails to run. My work around: The command 'ln -s /usr/lib/opengl/xorg-x11/lib/libGL.so.1 /usr/lib/libGL.so.1' solved the problem and amarok runs as expected. This is of course an unsupported solution, that is the beginning of 'installation-rot' in this box, but it works... As I said, I don't know where to report this, so tell me if I should open a separate report. I just felt it was partially a result of using the masked module, of course adding the 'eselect' into the soup. Best regards Biker
This is a common problem encountered when upgrading packages that provide modules that are used by other packages. The correct way to fix this problem is to use revdep-rebuild, which is provided by app-portage/gentoolkit. I suggest that you undo the change you make to your system ,you used the command 'ln -s /usr/lib/opengl/xorg-x11/lib/libGL.so.1 /usr/lib/libGL.so.1' I suggest that you remove this link: rm /usr/lib/libGL.so.1 emerge gentoolkit (unless already installed) revdep-rebuild (this may take a while) I'm not sure but in your case you might also need to reissue the command : opengl-update nvidia (In reply to comment #15) > After having followed Russel Chaits trick on my AMD64, to use the currently > masked nvidia driver, I run into a problem that I also managed to work around. > The problem is not directly nvidia related, but since it's a result from actions > described here, I choose to give my feed-back here. If that's not right, then > please tell me where to go. ;-) > > 1. I updated /etc/portage/package.keywords according to Russel. > 2. In one of the ebuilds, I saw the instruction to 'eselect opengl set nvidia' > which I did. > 3. Recompiled the kernel, installed and rebooted. > > Result: Excellent! The new kernel and nvidia works well together. > > > Problem: I broke the 'amarok' music player. amarok complains it cannot find > libGL.so.1 and fails to run. > > My work around: The command 'ln -s /usr/lib/opengl/xorg-x11/lib/libGL.so.1 > /usr/lib/libGL.so.1' solved the problem and amarok runs as expected. > > This is of course an unsupported solution, that is the beginning of > 'installation-rot' in this box, but it works... > > > As I said, I don't know where to report this, so tell me if I should open a > separate report. I just felt it was partially a result of using the masked > module, of course adding the 'eselect' into the soup. > > Best regards > Biker >
Gustav, Russell: that's a separate issue, bug 109922. Eradicator: What I was suggesting is that we make a revbumped release with the eselect-opengl dependancy replaced by opengl-update (as has now been done with ati-drivers) as it seems that a stable version of eselect is a while off yet. Is there some problem that would prevent us from doing this? is it not just a matter of s/eselect/opengl-update in the ebuild? As it stands the latest stable nvidia-kernel fails to emerge with the latest stable vanilla-sources or gentoo-sources.
I am having this issue as well. I don't want to diverge from the official tree, but I need OpenGL support so I can play the games I have. Has there been any change in the status of this bug?
I have to say "me to" on this bug - kernel 2.6.14-r2 and nvidia-kernel-1.0.8178. I had to go back to 8174-r1 emerge info brane@entwood ~ $ emerge --info Portage 2.0.53 (default-linux/amd64/2005.1, gcc-3.4.4, glibc-2.3.5-r2, 2.6.14-ge ntoo-r2 x86_64) ================================================================= System uname: 2.6.14-gentoo-r2 x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.6.13 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.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2" CHOST="x86_64-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/shar e/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.etf.bg.ac.yu/gentoo ftp://mirror.etf.bg.ac.yu/gent oo ftp://gentoo.itdnet.net/gentoo/ http://gentoo.ITDNet.net/gentoo http://gentoo .math.bme.hu http://gentoo.mirror.icd.hu/" LANG="sr_CS.UTF-8" LINGUAS="sr sr@Latn" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="amd64 X alsa audiofile avi berkdb bitmap-fonts bzip2 cdr crypt cups curl dv d eds emboss encode esd exif expat fam ffmpeg flac foomaticdb gif glut gnome gst reamer gtk gtk2 idn imagemagick imlib ipv6 java jpeg junit kde lcms ldap libwww lzw lzw-tiff mad mhash mng mp3 mpeg mysql ncurses nls nvidia ogg oggvorbis opena l opengl pam pcre pdflib perl png python qt quicktime readline recode sdl slang spell sqlite ssl tcltk tcpd tiff truetype truetype-fonts type1-fonts udev unicod e usb userlocales vorbis wmf xml2 xpm xv zlib linguas_sr linguas_sr@Latn userlan d_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LC_ALL, LDFLAGS, MAKEOPTS, PORTDIR_OVERLAY
*** Bug 116588 has been marked as a duplicate of this bug. ***
nvidia-kernel-1.0.6629-r4 can be made to load with a newer kernel by applying this patch http://www.nvnews.net/vbulletin/attachment.php?s=3163bd5a4d78a7a1d4280a5e179cb9b6&attachmentid=12063&d=1118762140 (yes, the patch is for 7174 but people say they applied it to solve our problem on 6629 as from this forum thread: http://www.nvnews.net/vbulletin/showthread.php?t=56926&page=2 So, if that works, then GeForce2 people can still be happy with 6629. However, I do not consider this a solution as sticking with 6629 limits you to features of this old driver (the newer ones have OpenGL2.0 support and other new features, besides support for "newer" hardware, so if you dont want to break GeForce2 users you are actually breaking "newer" cards users). A solution could be to make 2 different packages, one for the old nvidia and one for the new ones and people whould have to select between them depending on their hardware.
*** Bug 117148 has been marked as a duplicate of this bug. ***
(In reply to comment #21) > > A solution could be to make 2 different packages, one for the old nvidia and > one for the new ones and people whould have to select between them depending on > their hardware. I vote for a new ebuild (nvidia-legacy-kernel?) that can be used for old nvidia hw and recent kernels.
*** Bug 117790 has been marked as a duplicate of this bug. ***
(In reply to comment #23) > (In reply to comment #21) > > > > > A solution could be to make 2 different packages, one for the old nvidia and > > one for the new ones and people whould have to select between them depending on > > their hardware. > > I vote for a new ebuild (nvidia-legacy-kernel?) that can be used for old nvidia > hw and recent kernels. > I agree with this, It could be a good idea to have nvidia-legacy-kernel into portage.
I agree with the legacy ebuild. Once eselect goes stable and we move to a 7xxx or 8xxx as stable for this ebuild, I'll create a legacy ebuild for those with older cards. I'm going to attach a new ebuild and patch for you to test. Please see if it fixes this bug.
Created attachment 76346 [details, diff] files/1.0.6629/NVIDIA_kernel-1.0-7174-1296092.diff
Created attachment 76347 [details] nvidia-kernel-1.0.6629-r5.ebuild
Ebuild 1.0.6629-r5 committed and marked stable.
The new ebuild works great here using gentoo-sources-2.6.15 but only after running /sbin/NVmakedevices.sh before starting X. Any chance of more patches to fix the issue of device nodes not being created properly?
I believe that bug is logged as Bug 118030. I'll take a look as soon as I can.
*** Bug 118835 has been marked as a duplicate of this bug. ***
Same here as in comment #30, I also have to run /sbin/NVmakedevices.sh before starting X, otherwise it doesn't start, thanx for the tip Raymond!
