Summary: | Latest nvidia-kernel doesn't load into 2.6.14-gentoo-r2 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jules Colding <colding> |
Component: | [OLD] Core system | Assignee: | X11 External Driver Maintainers <x11-drivers> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | amd64, andreas, branej, bugreports, decibels.2862, dizzy, dystopianray, eradicator, evert.gentoo, gustav.schaffter, jbeverage, karl.johan.karlsson, me, mertens.steven, phil, randy, rusty_chait |
Priority: | High | ||
Version: | 2005.1 | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
files/1.0.6629/NVIDIA_kernel-1.0-7174-1296092.diff
nvidia-kernel-1.0.6629-r5.ebuild |
Description
Jules Colding
2005-11-24 06:10:22 UTC
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 117790 has been marked as a duplicate of this bug. *** *** 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! |