These two ebuilds (kernel and glx) are for both amd64 and x86. They seems to work fine here. Here are my concerns. Please let me know what you think: - GLX EBUILD: ${FILESDIR}/${P}-glheader.patch no longer applies and it seems as if it's no longer needed. Commented out. - GLX EBUILD: There are now 32-bit compatability libs for amd64. I am simply installing them to /usr/lib32 as they don't stomp on any other files. This may need to be handled by opengl-update. - GLX EBUILD: What's the deal with the libGL.la stuff at the end? Someone want to write that for the 32bit compat lib which is in the usr/lib32 directory? - KERNEL EBUILD: NVIDIA_kernel-${NV_V}-2.6-20040521.patch and NVIDIA_kernel-${NV_V}-fix-makefile-for-2.6.patch seem no longer needed. Commented out. - KERNEL EBUILD: NVIDIA_kernel-${NV_V}-basic-sysfs-support-v2.patch may need to be ported. Haven't had a chance to check for sysfs support in new driver. Please let me know what you think of the new ebuild and post test results.
Created attachment 34515 [details] nvidia-glx-1.0.6106.ebuild
Created attachment 34516 [details] nvidia-kernel-1.0.6106.ebuild
for me emerge nvidia-glx fails with: !!! File is corrupt or incomplete. (Digests do not match) >>> our recorded digest: 892fa9f8d6bbdb1f5f3250a130cc8252 >>> your file's digest: 5432f919f0211ce36b854d87108d7db0 !!! File does not exist: /usr/portage/distfiles//NVIDIA-Linux-x86-1.0-6106-pkg1.run
hm.. i got past that bit by doing emerge --digest =nvidia-glx-6106
the 4k stack warning needs to be removed. this release actually supports them :)
also, the 32bit libs should make nvidia-glx depend on emul-linux-x86-baselibs. otherwise they wouldnt work anyways, and would prevent the /usr/lib32 symlink from being created properly.
OK I have an exam in 90 minutes (having just woken up) so ive only just quickly looked over these, just a few notes (mainly for myself) 1) nvidia-kernel doesnt have the koutput patch in 5336-r4, does it need it? 2) sysfs should be ported before committing to the tree 3) does this driver resolve ...../search.c:167 errors 4) libGL compatibility with opengl-update should be aimed for, not the otherway When I get home ill look at this and get it into the tree (today?) asap. Changing assigned.
with the nvidia-glx ebuild for the new driver, glxinfo gives me: name of display: :0.0 Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". Error: couldn't find RGB GLX visual visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". 0x21 16 tc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". 0x22 16 dc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". 0x23 16 tc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". 0x24 16 tc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". 0x25 16 tc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". 0x26 16 tc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". 0x27 16 tc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". 0x28 16 tc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". 0x29 16 tc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". 0x2a 16 tc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". 0x2b 16 tc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". 0x2c 16 dc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". 0x2d 16 dc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". 0x2e 16 dc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". 0x2f 16 dc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". 0x30 16 dc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". 0x31 16 dc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". 0x32 16 dc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". 0x33 16 dc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None Xlib: extension "GLX" missing on display ":0.0". Xlib: extension "GLX" missing on display ":0.0". 0x34 16 dc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None Segmentation fault eep!
andrew re: point 4... opengl-update just handles the main system GL. for the new drivers it would need to handle this -and- the 32bit gl. it'd need to do it's thing twice, once for each bitdepth (64+32). that's why opengl-update needs updating. :)
Thanks! I've read that they will be out for august-september but are already here. Finally they works with my 2.6.7! I've also read that they works with the 4K Stack and regparam too! I have to test this.
As far as sysfs support goes, I talked to Zander and he says they've added sysfs support themselves in this release. The patch is no longer needed.
not having much luck with them either here on amd64. Kernel module loads, startx fails with (unless I comment out load glx from /etc/X11/xorg.conf): (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension LBX (II) Initializing built-in extension XC-APPGROUP (II) Initializing built-in extension SECURITY (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFree86-Bigfont (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing extension GLX *** If unresolved symbols were reported above, they might not *** be the reason for the server aborting. Fatal server error: Caught signal 11. Server aborting
X does not load for me - nothing in the log-file, only the following at the console: XIO: fatal IO error 104 (Connection reset by peer) on X server ":0.0" after 0 requests (0 known processed) with 0 events remaining (32bit here).
If you have not done so, do the following: 1) Reboot. Make sure the old kernel module gets cleaned out. 2) opengl-update nvidia I have seen this clean things up. FYI, AMD64 Gentoo Dual Opteron 248 2GB DDR Quadro FX 3000 glxgears: 87243 frames in 5.0 seconds = 17448.600 FPS WTF!!!!
I'm working on the bugs listed here. If someone elase joins the cause (cyfred), join me in #gentoo-amd64.
Kris Kersey: i tried rebooting and i ran opengl-update. this time X locked up the system while showing no more than blackness.
Veried that NVIDIA_kernel-1.0-5336-2.6-20040521.patch should no longer be needed.
Verified that NVIDIA_kernel-1.0-5336-fix-makefile-for-2.6.patch is also not needed.
Verified that NVIDIA_kernel-1.0-5336-basic-sysfs-support-v2.patch is not needed. SYSFS support is included.
New ebuilds coming up! Comment #5: the 4k stack warning needs to be removed: DONE! Comment #6: the 32bit libs should make nvidia-glx depend on emul-linux-x86-baselibs: DONE! Comment #7: 1) If you are talking about the stuff mentioned in the ck_kern_write(), then it's still broken. 2) sysfs: IN THERE! 3) search.c:167 errors: I don't know yet. 4) opengl-update: SEE COMMENT #9 Comment #9: opengl-update: This may need doing in the future but since we're not stepping on anyone elses files now, I wouldn't worry about it. Unless you like being proactive. ;-)
Created attachment 34544 [details] nvidia-glx-1.0.6106.ebuild See Comment #20. Also, fixed 32-bit binary support. Played Enemy Territory and worked fine.
Created attachment 34545 [details] nvidia-kernel-1.0.6106.ebuild See Comment #20.
glxinfo no longer segfaults :)
works fine for me on an asus sk8v antlon-fx53 and nvidia-fx5900 ... thanks
These ebuilds don't work if you built your kernel with gcc-3.4. It always resulted in an invalid module format error.
Unfortunately, I'm still getting glx coredumps, even with the new builds. Kernel 2.6.7-mm5, 8K stacks.
The mm kernels seem to give this new driver problems. Try the gentoo-dev-sources.
You may want to have it install nvidia-bug-report.sh, like the main distrib does.
OK anyone that has been trying out these drivers please test stuff from http://dev.gentoo.org/~cyfred/overlay/media-video/ The tarball reflects both directories. Changes in the ebuilds listed there -kerenel 1) No more "userpriv" problems -- please check / verify this is you use userpriv (bug #48224) 2) Koutput patch included -- people using koutput should now be right 3) Addwrite support is no longer needed for < 2.6.6 (correlates to userpriv) -glx 1) Added patch to get rid of nvidia comment about using nvidia-installer 2) Introduced ${FILESDIR}/${PV}/* patches for GLX These are primarily based off Kris' ebuilds, and satisfy me as suitable for cvs. So basically post test results galore and if its all good these'll go into the tree.
Update, changed nvidia-glx to install > /usr/bin/nvidia-settings > /usr/bin/nvidia-bug-report.sh This is different to /bin/nvidia-settings and more appropriate. Tarball is still most recent on dev.gentoo.org
The initial set of ebuilds resulted in a corrupted screen with 2.6.7-rc3-love2 kernel. The overlay http://dev.gentoo.org/~cyfred/overlay/media-video/nvidia-overlay.tar.bz2 ebuilds work perfectly.
Being silly gentoo users that like to build things ourselves the nvidia-settings (They GPL'ed it) source can be gotten here http://download.nvidia.com/XFree86/nvidia-settings/nvidia-settings-1.0.tar.gz Perhaps the nvidia-glx ebuild should fetch and build that?
The latest ebuilds are working well thanks. One small problem: $ ldd /usr/lib32/libGL.so.1.0.6106 /usr/lib32/libGL.so.1.0.6106: error while loading shared libraries: libnvidia-tls.so.1: cannot handle TLS data I only need to export LD_LIBRARY_PATH=/usr/lib32 to fix this (must export this before running any 32bit opengl apps) so it's not a big problem. Can't think of an easy fix for this in the ebuild as /usr/lib clearly need before /usr/lib32 in /etc/ld.so.conf. Guess I'll just have add this to any game startup scripts.
I think I agree with floam. I think nvidia-settings should be a separate build. For one, it requires gtk2+ to build, which means that gtk2+ is now a RDEPEND for nvidia-glx, which it should not be. Either the ebuild needs to be modified to support the gtk2 USE flag to build nvidia-settings, or a new nvidia-settings ebuild needs to be created which is added to DEPEND or RDEPEND if USE=gtk2.
ebuild works for me and works the driver too witj gentoo-dev-sources-r6 but somethimes nvidia-setting crashes e.g.when i set digial vibrance and exit from the app Xorg restarts...
re: comments 25 and 27... i'm using gcc 3.4 and mm-sources. it works here... on amd64. v@ayanami lv $ uname -a Linux ayanami.lv 2.6.7-mm4 #2 Tue Jun 29 20:48:44 EDT 2004 x86_64 4 GNU/Linux lv@ayanami lv $ cat /proc/driver/nvidia/version NVRM version: NVIDIA Linux x86_64 NVIDIA Kernel Module 1.0-6106 Wed Jun 23 08:12:31 PDT 2004 GCC version: gcc version 3.4.1 20040625 (prerelease)
You can grab my overlay tarball from http://dev.gentoo.org/~wolf31o2... the only difference is that I've added nvidia-settings as a separate ebuild (needs manifest and such, I'm at work, so no nvidia hardware to test) and removed the nvidia-settings stuff from nvidia-glx... I also added a gtk? media-video/nvidia-settings to DEPEND, though now that I think about it, it should probably be RDEPEND.
err... correction. on amd64 the new nvidia-glx should depend on emul-linux-x86-xlibs, not baselibs.
OK quick update doing right now 1) fixing -glx 2) fitting nvidia-settings into overlay 3) breaking 32bit compatibility into a seperate package
Comment #30: I meant to but it in /usr/bin DOH! Comment #32, Comment #34, Comment #37: I'll test out those ebuilds. I agree that if source is available, we should build it. Especially if it has other deps. Comment #33: I would like to find out why people are having the lib32 problems. I'm not. I ran Enemy Territory with no issues.
Comment #39: I wouldn't move it out of there. Too many packages. The way I was doing it seems fine. If the person wants 32-bit compat, he will have the other compat libs installed.
could someone please make a .tar.bz2 file of the .ebuild files? i'm getting sick of this. i'm on a friends machine here and ssh to my home. i just want those .ebuild files being downloaded at the other machine. it's not possible, because they are not direct links but, some strange attachments. wget can't get them and i can't copy paste the the text of the .ebuild files into an ssh vim window. ... ARGH!!! how invented this system?
Comment 40: I'm assume I'm getting the libnvidia-tls.so.1: cannot handle TLS data because I have tls ebabled glibc (USE=nptl). Do you not? Comment 42: see comment 29
No, I do not have that enabled. I'll have to try that later.
OK im done with my changes, which I shall upload once d.g.o comes back from upgrades. CHANGES 1) There are now FOUR packages - media-video/nvidia-kernel - media-video/nvidia-glx - media-video/nvidia-settings - app-emulation/emul-linux-x86-nvidia The emulation package has been broken off and is PDEPEND from nvidia-glx if USE="amd64 multilib" -- multilib is up for some debate here because it does break other things. However the package _should_ be broken out like this so that users dont necessarily have to install these libraries (even if emul-linux-x86-xlibs is installed, as was the case before). 2) nvidia-settings provides its own documentation so removed that from nvidia-glx install. 3) nvidia-glx provides nvidia-bug-report.sh, notify users of it. 4) Updated DESCRIPTION for all packages, feel free to comment 5) Added / updated metadata.xml to the overlay tarball, get as close as possible to CVS suitable this way, performed repoman scan, only thing missing is ChangeLog (waiting for commit). 6) Added date revisioning to tarball : nvidia-overlay-20040702.tar.bz2 NOTES 1) emul-linux-x86-nvidia needs to be tested by amd64 people. 2) some form of sensible message needs to be added to emul-linux-x86-nvidia post_inst(), "MESSAGE HERE ABOUT 32 BIT LIBS" isnt very useful IMO. Anything else?
I still don't think emul-linux-x86-nvidia makes since. We are going to have a lot of people complaining that 32bit apps don't work. What's really wrong with the old way? Also, it doesn't make since that they depend on multilib. You shouldn't have to have multilib defined to emerge Enemey Territory and run it on AMD64.
would it not make more sense install 32bit libGL* into: /emul/linux/x86/usr/lib/opengl/nvidia/lib/ to be consistent with emul-linux-x86-xlibs which installs libGL* in: /emul/linux/x86/usr/lib/opengl/xorg-x11/lib/ (/usr/lib32 is a symlink to /emul/linux/x86/usr/lib) this could then be more easily handled by opengl-update.
Comment 46: you need not have multilib in your USE if you explicitly emerge emul-linux-x86-nvidia. Also enemy-territory could depend on emul-linux-x86-nvidia if use amd64 && use nvidia or something...
After emerging nvidia-glx-1.0.6106 & -kernel-1.0.6106 xmms (if compiled with USE=opengl) will segfault at startup. The opengl spectrum analyzer plug-in is doing the segfault. All other opengl apps work normal. Can anybody verify this?
all the xmms visualisations work well here
Kris: Yes the use of USE="multilib" is ambiguous, perhaps a different use flag would be a good idea for that -- this however means introducing a use flag that not everyone is going to know about. So if its a use flag to STOP 32 bit libs being installed people are going to be forced to install emul-linux-x86-* who dont know... Conversly someone would need to know to set the flag to get said libraries if they genuinely want them on their system. The reason its broken out is so that the user DOESNT have to have these 32bit libraries installed, just because they have OTHER 32bit libraries installed. The old method did not allow for this, if emul-linux-x86-baselibs was installed then the 32bit compatibility libs wouldve been installed. Re the comment of installing to /emul I have fixed that in my current overlay still waiting for dev.g.o
http://dev.gentoo.org/~cyfred/overlay/nvidia-overlay-20040702.tar.bz2 I have rolled the sources into the distfile tree for mirroring.
OK. You've convinced me to make it a seperate package. I noticed that there are already multple emul packages. I recommend replacing the multilib depend with simple depend on emul-linux-x86-xlibs. Afterall, without those it doesn't make since anyway.
I have problem with nvidia-settings package. >>> Install nvidia-settings-1.0 into /var/tmp/portage/nvidia-settings-1.0/image/ category media-video install: cannot stat `nvidia-settings': No such file or directory man: prepallstrip: strip: >>> Completed installing into /var/tmp/portage/nvidia-settings-1.0/image/ >>> Merging media-video/nvidia-settings-1.0 to / --- /usr/ --- /usr/bin/ --- /usr/share/ --- /usr/share/doc/ >>> /usr/share/doc/nvidia-settings-1.0/ >>> /usr/share/doc/nvidia-settings-1.0/nvidia-settings-user-guide.txt.gz >>> /usr/share/doc/nvidia-settings-1.0/NV-CONTROL-API.txt.gz * Caching service dependencies... >>> media-video/nvidia-settings-1.0 merged. >>> Recording media-video/nvidia-settings in "world" favorites file...
same as above ... gcc output is as follows .. cc1: error: unrecognized option `-fpedantic' cc1: error: unrecognized option `-fpedantic' gcc -c -Wall -fpedantic -O -I /usr/X11R6/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I doc -I src -I src/image_data -I src/xpm_data -I src/gtk+-2.x -I src/libXNVCtrl -I src/libXNVCtrlAttributes src/command-line.c -o .objs/command-line.o cc1: error: unrecognized option `-fpedantic' make: *** [.objs/command-line.o] Error 1
Created attachment 34596 [details, diff] Make the nvidia-settings compile :D
I was just heading to report the problem given in comment 49. According to trace nvidia-tls.so.1 gets read just before segfault so it's most likely to cause the problem. (Also, if I understood correctly, this does mean that the problem only shows with nptl, right?)
Confirmed that patch attachment (id=34596) fixes the nvidia-settings ebuild.
ntptl does seem to be a current problem. I may test this when I get home.
The current overlay works great for me. x86, 2.6.7-ck4, glibc (the latest and greatest in portage) with nptl, gcc 3.4. No problems. nvidia-settings builds for me as well.
Installs ok, KDE starts up ok, opengl apps cause my second display to jiggle violently when the FPS is high. It could be happening when the FPS exceeds 105 which is my refresh rate for both heads. I've tried the sync toVBlank but that only eliminates the problem when I run GLX gears as it still happens with armyops. Kenel 2.6.7 w/ 4k stacks enabled Xorg KDE 3.2.3 ~x86 + linux-headers-2.6.7-r1 and glibc-2.3.4.20040619 Portage 2.0.50-r8 (default-x86-1.4, gcc-3.3.3, glibc-2.3.4.20040619-r0, 2.6.7)
OK, I found out the reason I was getting coredumps from glx stuff - would you believe Alsa OSS library? (LD_PRELOAD=/usr/lib/libaoss.so) If someone can explain THAT one..... Also, nvidia-settings failed to install a binary; thus: >>> md5 src_uri ;-) nvidia-settings-1.0.tar.gz >>> Unpacking source... >>> Unpacking nvidia-settings-1.0.tar.gz to /var/tmp/portage/nvidia-settings-1.0/work >>> Source unpacked. >>> Install nvidia-settings-1.0 into /var/tmp/portage/nvidia-settings-1.0/image/ category media-video install: cannot stat `nvidia-settings': No such file or directory man: prepallstrip: strip: >>> Completed installing into /var/tmp/portage/nvidia-settings-1.0/image/ # qpkg -l nvidia-settings media-video/nvidia-settings-1.0 * CONTENTS: /usr /usr/bin /usr/share /usr/share/doc /usr/share/doc/nvidia-settings-1.0 /usr/share/doc/nvidia-settings-1.0/nvidia-settings-user-guide.txt.gz /usr/share/doc/nvidia-settings-1.0/NV-CONTROL-API.txt.gz
Re: Comment #62; My mistake - I assumed that downloaded tarball included the "make nvidia-settings compile" patch - obviously, it didn't. Applied patch, and all good.
Ok I changed to a different resolution and it seems the problem is gone. Old modeline that caused the problems: ModeLine "1024x768" 119.45 1024 1072 1312 1408 768 770 782 808 #105Hz New modeline, higher res, same params to come up with it @ http://koala.ilog.fr/cgi-bin/nph-colas-modelines ModeLine "1152x864" 130.52 1152 1200 1440 1536 864 866 878 904 #94Hz All seems good with 1152x864 except for a new "look" to my desktop now.
The nvidia-settings error was my fault, the functionality of not having a function in the ebuild is supported in portage .51, but not in .50 ... I have updated the overlay with this fix.
nvidia-settings crashes for me, but other than that things work (well, glxgears works anyway, haven't done any further testing) ===================== Program received signal SIGSEGV, Segmentation fault. 0x000000000042a88b in XNVCTRLQueryExtension () (gdb) bt #0 0x000000000042a88b in XNVCTRLQueryExtension () #1 0x00000000006193d0 in ?? () #2 0x0000007fbffff270 in ?? () #3 0x0000000000614600 in ?? () #4 0x000000000042351b in NvCtrlInitNvControlAttributes (h=0x614600) at src/libXNVCtrlAttributes/NvCtrlAttributesNvControl.c:47 #5 0x000000000042321d in NvCtrlAttributeInit (dpy=0x614600, screen=0, subsystems=7) at src/libXNVCtrlAttributes/NvCtrlAttributes.c:67 #6 0x000000000040ca18 in nv_alloc_ctrl_handles (display=0x6144d0 ":0.0") at src/query-assign.c:153 #7 0x000000000040b817 in main (argc=1, argv=0x7fbffff3d8) at src/nvidia-settings.c:86 ===================== caleb@Chinstrap caleb $ emerge info Portage 2.0.50-r8 (gcc34-amd64-2004.1, gcc-3.4.0, glibc-2.3.4.20040605-r0, 2.6.7-gentoo-r7) ================================================================= System uname: 2.6.7-gentoo-r7 x86_64 4 Gentoo Base System version 1.5.1 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CFLAGS="-Os -march=athlon64 -pipe" CHOST="x86_64-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control"CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-Os -march=athlon64 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X aalib acl acpi alsa amd64 avi berkdb caps cdr cjk crypt cups curl dga directfb djbfft doc dvdr encode esd evo f77 fbcon flash foomaticdb gd gdbm ggi gif gnome gnutls gpm gstreamer gtk gtk2 guile imap imlib innodb ipv6 jack jack-tmpfs java javascript jbig jpeg lcms ldap libg++ libwww lzw-tiff mad mailwrapper mcal md5sum mikmod mmap motif mozilla moznocompose moznoirc moznomail mozsvg mpeg multilib mysql ncurses nls nptl oav objc odbc oggvorbis openal opengl oss pam pcre pda pdflib perl php pic png python quicktime readline samba sdk sdl slang slp snmp spell ssl tcltk tcpd threads tiff truetype unicode video_cards_nvidia vim-with-x wmf xinerama xml xml2 xmms xprint xv zlib"
Re Comment #49; yes, my "xmms" is also segfaulting under 6103. emerge -vp xmms These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] media-sound/xmms-1.2.10-r5 -3dnow +alsa -cjk +directfb +esd -ipv6 +mikmod +mmx +nls +oggvorbis +opengl +oss +xml 0 kB (I have currently reverted to 1.0-5336).
xmms works well here with opengl flag nvidia drivers work aswell with nptl Portage 2.0.50-r8 (default-x86-2004.0, gcc-3.4.0, glibc-2.3.4.20040619-r0, 2.6.7-gentoo-r7)
ebuilds are in the portage sync tree.
i' ve got segfaults with 1.0.6106, too. when starting xine and xmms, both ends with segfaults.... after turning 4k stacks off, i try an other run -> same segfaults. after switching back to: nvidia-kernel-1.0.5336-r4 nvidia-glx-1.0.5336-r2 everything runs fine... are some other information needed ?
xmms is working fine here, but xine isn't (segmentation fault). emerge -pv xine-ui xine-lib xmms xorg-x11 These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] media-video/xine-ui-0.9.23-r2 +X +aalib +directfb +gnome +lirc +nls 0 kB [ebuild R ] media-libs/xine-lib-1_rc4-r1 +X +aalib +alsa +arts +avi +directfb +dvd +esd +gnome -ipv6 +nls +oggvorbis +sdl +speex +theora 0 kB [ebuild R ] media-sound/xmms-1.2.10-r5 +3dnow +alsa -cjk +directfb +esd -ipv6 +mikmod +mmx +nls +oggvorbis +opengl +oss -xml 0 kB [ebuild R ] x11-base/xorg-x11-6.7.0-r1 -3dfx +3dnow -cjk -debug +doc -hardened -ipv6 +mmx +nls +pam -pie -sdk +sse -static 8 kB Total size of downloads: 8 kB
On AMD64 both xine and xmms work flawlessly still: [ebuild R ] media-video/xine-ui-0.99.1 +X +aalib -directfb -gnome -lirc +nls 0 kB [ebuild R ] media-libs/xine-lib-1_rc5-r2 +X +aalib +alsa -(altivec) -arts +avi -directfb +dvd +esd -gnome -ipv6 +nls +oggvorbis +sdl -speex -theora 0 kB [ebuild R ] media-sound/xmms-1.2.10-r5 -(3dnow) +alsa -cjk -directfb +esd -ipv6 +mikmod -(mmx) +nls +oggvorbis +opengl +oss -xml 0 kB
Mathieu you're the most recent to report xine segfaulting, please open a bug about it assigned to xfree@gentoo.org and post a link in this bug. Everyone else that is having the problem _please_ put information into this. Sebastian you get the honours for xmms. Once again people experiencing the problem put info on that bug eg the output of the segfault dump. This bug is for getting the 6106 into portage, thats done so Id like to break off problems into seperate bugs.
xine bug: http://bugs.gentoo.org/show_bug.cgi?id=55897
nvidia-kernel won't build AsusA7N8X AthlonXP2400 $ emerge info Portage 2.0.50-r8 (default-x86-2004.0, gcc-3.3.3, glibc-2.3.3.20040420-r0, 2.6.5-gentoo-r1) ================================================================= System uname: 2.6.5-gentoo-r1 i686 AMD Athlon(tm) XP 2400+ Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O3 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /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=athlon-xp -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox usersandbox" GENTOO_MIRRORS="http://www.gtlib.cc.gatech.edu/pub/gentoo/ ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo http://gentoo.oregonstate.edu ftp://ftp.oregonstate.edu/pub/gentoo http://distro.ibiblio.org/gentoo " MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage/" USE="3dnow X aalib acpiapm alsa apm arts avi cdr crypt cups dga directfb dvd encode esd fbcon flash foomaticdb gd gdbm ggi gif gphoto gpm gtk gtk2 gtkhtml imap imlib java jikes jpeg kde lcms ldap leim libg++ libwww mad maildir mbox mikmod mmx motif mozilla mpeg ncurses nls oav oggvorbis opengl oss pam pdflib perl pic png python qt quicktime readline scanner sdl slang spell ssl svga tcltk tcpd tetex tiff truetype usb x86 xml xml2 xmms xv zeo zlib" fails with: .................................... * Applying NVIDIA_kernel-1.0-6106-koutput-support.patch... [ ok ] >>> Source unpacked. x86 NVIDIA: calling KBUILD... *** Warning: Overriding SUBDIRS on the command line can cause *** inconsistencies mkdir -p .tmp_versions make -f scripts/Makefile.build obj=scripts/basic make -f scripts/Makefile.build obj=scripts gcc -Wp,-MD,scripts/.conmakehash.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/conmakehash scripts/conmakehash.c ACCESS DENIED open_wr: /usr/src/linux-2.6.5-gentoo-r1/scripts/.conmakehash.d cc1: Permission denied: opening dependency file scripts/.conmakehash.d make[3]: *** [scripts/conmakehash] Error 1 make[2]: *** [scripts] Error 2 NVIDIA: left KBUILD. nvidia.ko failed to build! make[1]: *** [module] Error 1 make: *** [module] Error 2 !!! ERROR: media-video/nvidia-kernel-1.0.6106 failed. !!! Function src_compile, Line 87, Exitcode 2 !!! Failed to build module --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-media-video_-_nvidia-kernel-1.0.6106-20026.log" open_wr: /usr/src/linux-2.6.5-gentoo-r1/scripts/.conmakehash.d ------- Thanks, Ernie
Re: comment 75 Your error is koutput related, see http://www.gentoo.org/doc/en/2.6-koutput-user.xml for more info.
Cyfred: I think you should make it so if USE=gtk nvidia-glx depend on nvidia-settings. People are going to be upset when they can't find it (and others who don't use gentoo will quickly get annoyed when they find half the silly gentoo users don't have a required util)
Hmpf I think i mis-interpreted how nvidia did stuff with their makefiles... I thought they had made it so kernels < 2.6.6 wouldnt need stuff built in the tree, but it appears that they only made it so that having a built tree _wasnt_ essential to building on these kernels.. and then threw and error if you were using koutput -- i know it sucks guys but for the time being just disable sandbox FEATURES="-sandbox" emerge nvidia-kernel floam there is a note at the end of the glx ebuild that says nvidia-settings exists as a seperate pacakge. Im sitting on the fence on this one, because in reality nvidia-settings is not something nvidia-glx depends on. However I know what you're saying aswell.
xmms bug http://bugs.gentoo.org/show_bug.cgi?id=55891
All works for me. (No xine or xmms bug, nvidia-settings works as well) I am using sandbox and userpriv with kernel 2.4.26 having set only read permissions for group portage on kernel source. No problem during install.
I've noticed a similar problem to comment #33 except with mplayer. Mplayer gives an error at startup, but then plays with no problem. Also this version of nvidia seemed to break mythtv. Whenever I ran mythfrontend and tried to play video either prerecorded or live tv I receieved the message "Unable to create XvMC Context return status:11 BadAlloc Killied" . And one furthur problem was with ut2004. The game was completely unplayable, very very slow. Both menus and gameplay. I've just downgraded nvidia. All of those problems I just outlined have gone away. sloan
It seems to me that this little driver bug (and fix) hasn't been covered yet: http://www.nvnews.net/vbulletin/showthread.php?t=31010 See comment #6.
OK we need to work out something to do about glext.h and tls both of which are opengl-update handling problems (at least at the moment), adding the depend.
Why does the einfo for emul-linux-x86-nvidia tell the user to set: LD_CONFIG_PATH="/usr/lib32/opengl/nvidia/lib" I'm not sure what LD_CONFIG_PATH is used for but I don't think it's the same as LD_LIBRARY_PATH which I think is what is needs to be set here.
Has anyone had the experience of build 6106 being (very) slow? I've dug through my logs and found nothing of interest so I had to downgrade.
Interisting to note that this tls problem does not occur when both 64bit and 32bit glibc are tls enabled, only when using the emul-linux-x86-baselibs non-tls glibc with a 64bit tls enabled glibc.
Just commited fixes for dependent bugs, leave this open for archs to track once bugs as squashed.
Well these are in the tree and pretty much good for go. Closing this bug and removing the dep on opengl-update as thats not a dep anymore but a opengl-update feature request bug.
