login
Search
hi there,
a lot of people who are using the nvidia closed source driver are having
problems running linux 3d applications. the libGL.so.1 library (linux version
in /compat/linux/usr/lib) causes almost every linux 3d app to segfault. since
the library is the very same one that get's installed under linux the problem
very likely resides in the linuxulator.
i ran two linux games with ktrace. this is the output from linux_kdump. i hope
i copy&pasted the important pieces of the dump that report the crash.
dump from unreal tournament 2004 demo:
...
1180 ut2004-bin RET close 0
1180 ut2004-bin CALL linux_brk(0xae5c000)
1180 ut2004-bin RET linux_brk 182829056/0xae5c000
1180 ut2004-bin CALL linux_getpid
1180 ut2004-bin RET linux_getpid 1180/0x49c
1180 ut2004-bin CALL linux_getpid
1180 ut2004-bin RET linux_getpid 1180/0x49c
1180 ut2004-bin CALL linux_getpid
1180 ut2004-bin RET linux_getpid 1180/0x49c
1180 ut2004-bin CALL
linux_sys_futex(0x2b406e30,0x81,0x7fffffff,0,0x49c,0x7)
1180 ut2004-bin RET linux_sys_futex 1
1180 ut2004-bin PSIG SIGSEGV caught handler=0x874bd50 mask=0x0 code=0x0
1180 ut2004-bin CALL linux_fstat64(0x1,0xbfbfa9e8,0x28fe8ff4)
1180 ut2004-bin UNKNOWN(8) 1180 ut2004-bin RET linux_fstat64 0
1180 ut2004-bin CALL linux_mmap2(0,0x1000,0x3,0x22,0xffffffff,0)
1180 ut2004-bin RET linux_mmap2 688971776/0x2910e000
1180 ut2004-bin CALL write(0x1,0x2910e000,0x25)
1180 ut2004-bin GIO fd 1 wrote 37 bytes
"Signal: SIGSEGV [segmentation fault]
"
1180 ut2004-bin RET write 37/0x25
1180 ut2004-bin CALL write(0x1,0x2910e000,0xa)
1180 ut2004-bin GIO fd 1 wrote 10 bytes
"Aborting.
"
1180 ut2004-bin RET write 10/0xa
1180 ut2004-bin CALL write(0x1,0x2910e000,0x1)
1180 ut2004-bin GIO fd 1 wrote 1 byte
"
"
1180 ut2004-bin RET write 1
1180 ut2004-bin CALL write(0x1,0x2910e000,0x1)
1180 ut2004-bin GIO fd 1 wrote 1 byte
"
"
...For those who might wish to dig into the problem following information from you host may be helpful: ----- % uname -a % sysctl compat.linux % pkg_info -xI linux ----- WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
oh sure. sorry: FreeBSD moshnroll 8.0-CURRENT FreeBSD 8.0-CURRENT #5 r189748: Thu Mar 12 21:09:14 UTC 2009 root@moshnroll:/usr/obj/usr/src/sys/ARUNDEL i386 compat.linux.oss_version: 198144 compat.linux.osrelease: 2.6.16 compat.linux.osname: Linux linux-alsa-lib-1.0.10.3 The Advanced Linux Sound Architecture libraries linux-arts-1.5.3.0.1.f4 Audio system for the KDE integrated X11 desktop (Linux vers linux-atk-1.9.1_1 Accessibility Toolkit, Linux/i386 binary linux-cairo-1.0.2 Linux cairo binary linux-doom3-demo-1.1.1286_2 DOOM III demo for Linux linux-edonkey-core-1.3.0,1 eDonkey2000 'core' command line client linux-esound-0.2.36 RPM of esound linux-expat-1.95.8 Linux/i386 binary port of Expat XML-parsing library linux-fontconfig-2.2.3_7 Linux/i386 binary of Fontconfig linux-gtk2-2.6.10_1 GTK+ library, version 2.X, Linux binary linux-jpeg-6b.34 RPM of the JPEG lib linux-libaudiofile-0.2.6_2 RPM of audiofile linux-libogg-1.1.2.2_3 Ogg bitstream library (Linux version) linux-libvorbis-1.1.0.2 Audio compression codec library (Linux version) linux-openal-0.0.9.0.6.20060204.c.f4_1 A 3D positional spatialized sound library (Linux version) linux-pango-1.10.2_1 Linux pango binary linux-png-1.2.8_2 RPM of the PNG lib linux-quake4-demo-1.0_1 Quake 4 for Linux Demo linux-sdl-1.2.10,1 Cross-platform multi-media development API (linux version) linux-tiff-3.7.1 TIFF library, Linux/i386 binary linux-xorg-libs-6.8.2_5 Xorg libraries, linux binaries linux_base-f8-8_11 Base set of packages needed in Linux mode (for i386/amd64) linux_dri-7.0 Binary Linux DRI libraries for 3D hardware acceleration of linux_kdump-1.5_2 Linux-compatability ktrace.out processor cheers. ...oh...and i'm using release 180.29 of the nvidia drivers. i installed graphics/linux_dri to see if that fixes the problem and with the libGL.so.1 from linux_dri the games run without any problems. also the problem i described doesn't exist on 6.4-STABLE i've been ...
from my experience the nvidia driver does not work at all.. it used to work in 6.x times with linuxulator but recently all I got from it was panic or deadlock (depending on weather) there's an ongoing work on nouveau, so stay tuned :) _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Doesn't work at all.. when? I guess you meant that "linux OpenGL portion of nvidia-driver doesn't work with compat.linux.osrelease=2.6.16", because otherwise the statement doesn't make any sense. nvidia-drivers work perfectly well with compat.linux.osrelease=2.4.2 (maybe not with some very recent -CURRENT, haven't been checking for a while, but that's not the point anyway) and actually are the only way to get any serious 3d gaming done on FreeBSD, and I'm not even starting with OpenGL apps like Blender (ATI users know what I'm pointing to). This is a clear bug in 2.6 linuxulator - the OpenGL works properly in Linux 2.4/2.6 (well, that's kinda expected), it works properly in 2.4 linuxulator, it breaks with 2.6 linuxulator. I think it's hard to call that "nvidia driver doesn't work at all", but maybe I just missed the Yes, that will take many years to complete, or at least, produce a rotating cube or maybe, maybe run glxgears in around 2012. m. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
exactly! the linux compatibility libraries that get installed are the very same ones that get installed under linux. since the drivers work perfectly under linux the problem running linux 3d apps under freebsd can 100% be blamed on the linuxulator. right now i'm switching back to the linux_base-fc4 to see if it works under CURRENT, but i very much doubt it. cheers. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
On Sat, Mar 14, 2009 at 2:19 PM, Alexander Best Don't forget to set compat.linux.osrelease=2.4.2 to run the "old" linuxulator code (it wasn't removed from -CURRENT any time recently, I presume? can't check at the moment for myself), nvidia's libGL should run perfectly then (I'm not sure if UT2004 runs with 2.4 linux kernels, but any ID stuff will pass the test fine, up to ET: Quake Wars). If that's still the case, it should at least prove that 2.4 linuxulator = good, 2.6 linuxulator = broken, somewhere, somehow. I guess that's a start. m. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
thanks for the hint. setting compat.linux.osrelease=2.4.2 works. :-) settings compat.linux.osrelease=2.4.20 let's quake4 crash with the very same error message when using compat.linux.osrelease=2.6.16. unreal tournament 2004 also runs with compat.linux.osrelease=2.4.2. cheers. ..but this just makes it more obvious that the linuxulator is far from being 100% compatible to the kernel version 2.6. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
On Sat, Mar 14, 2009 at 2:55 PM, Alexander Best Ah, I missed the .20 part. I think "2.4.2" and "2.6.16" are the magic words to flip 2.4/2.6 linuxulators, as far as I know there should be no other sub-versions doing anything specific (yes, too lazy to check sources). I'd assume that setting 2.4.20 just enables the default path, that is 2.6 on -CURRENT. m. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
that's a bit strange imo, because entry 20071101 from ports/UPDATING explicitly tells one to set compat.linux.osrelease=2.4.20. maybe a typo. thanks for the help pal. :) _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Setting 2.4.20 and greater flips a switch in the linker to use NPTL as opposed to LinuxThreads (old threading library). Here are some good links about the different versions and how they can be changed for execution of a program: http://my.opera.com/onyxluo/blog/2008/10/15/metalink-note-433292-1-ld-assume-kernel-en... http://developer.novell.com/wiki/index.php/LD_ASSUME_KERNEL http://people.redhat.com/drepper/assumekernel.html A discussion for Ubuntu on running old Loki games: http://ubuntuforums.org/showthread.php?t=21087 Gentoo use to have a page on Loki games: http://gentoo-wiki.com/HOWTO_Running_Old_Loki_Games Information on running Alpha Centauri on a Linux v2.6: http://lordhedgehog.hedgie.com/smac/ Information on running different versions of Unreal Tournament: http://members.shaw.ca/dan.mckay/LinGam.html Personally, I have tried to get games/linux-ut to run using linux-f8 and x11/nvidia-driver on RELENG_7 using various means. These means have included attempts such as setting LD_ASSUME_KERNEL=2.4.2 before running it and/or using a separate directory of linux-fc4 libraries. I may have missed a combination. I think if running it under linux-fc4 with compat.linux.osrelease=2.4.2 works it would be nice to be able to run multiple Linux bases at different compatibility versions. Obviously, this is anything but trivial. BTW, games/sauerbraten is a good OpenGL-based game that is compiled native for FreeBSD. It works well with the nvidia driver. Sean -- scf@FreeBSD.org _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
we dont support this _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
just tried switching back to linux_base-fc4 and compat.linux.osrelease=2.4.20. makes absolutely no difference. quake 4 still crashes. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
On Sat, Mar 14, 2009 at 2:43 PM, Alexander Best Same place, in libGL? Quake 4 used to crash somewhere during alsa initialization, so you needed to put seta s_dsp "/dev/dsp" seta s_driver "oss" in its config. Just making sure. m. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
I am currently running accelerated glgears on freebsd using nouveau. thnx for your enthusiasm :) _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
woowWWW that's hell-I-don't-know-how-to-express-this good !!!! where to get latest code ? thanks !!! matheus -- We will call you cygnus, The God of balance you shall be _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Unfortunately, the 3d is direct "software rendering" right now, but I do have drm enabled hardware accelerated 2d and Xv working now. Linux doesn't have hardware accelerated 3d right now either, so... I'm planning to start putting together patches for -CURRENT next week. The userland components you generally need to get from git. We do now have a port of the nouveau driver based on a git snapshot, but the driver has yet to be released and I've got at least one change to libdrm that is needed against git master to make things work on amd64. I haven't tried NV50 series cards yet... I've done most of the porting on an NV40 and Roman has has an NV44. I need to plug the 8800 back in and see how it goes. --=20 Robert Noland <rnoland@FreeBSD.org> FreeBSD
I have both 7950GT and 8500GT. I'll try the latter first throughout this week. -- We will call you cygnus, The God of balance you shall be _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
While I've been a little sarcastic, yes, there is some preliminary 3D support in nouveau. Still, then you can say that there are fairly good Direct3D accelerated drivers for S3 Virge out there (really, there are). Let's look only on the nouveau front page: Current Status 2D-support is in fairly good shape with EXA acceleration, Xv and Randr12 (think of dual-head, rotations, etc.). Randr12 should work for all cards up to, and including, Geforce 9000 series, although some issues with Geforce 8/9 laptops may still exist, for such issues bug reports should be submitted. Randr12 is now the default. Any 3D functionality that might exist is still unsupported, do not ask for instructions to try it. Also, VT switching while X is running is considered lucky. (yes it's sittinge there for a long time and stuff moved forward a bit in meantime, but, well..) Feature matrix? http://nouveau.freedesktop.org/wiki/FeatureMatrix "4 - While some support for 3D exists, it is far from mature. And even if it was mature, the particular feature you need, be it oddball texture compression formats and whatnot, may not be there. Yet. Patches welcome." Roman, while I appreciate everyone's work on nouveau, be it you, Robert or anyone else, you seriously don't believe to be running Doom 3 or Quake 7.65 on it for yet next few years.. Don't you think? You make it sound like nouveau is "just around the corner" and, I don't know, judging from the immediately following "wow wow wow" reaction, I don't think that's very nice to some of the 'regular' folks around (not trying to make a point with the poster, just thinking generally). Just look at the sad state of oss ATI accelerated drivers (and to avoid being autoattacked by some trigger-happy ATI fanboy, I run both nvidia and ati setups, thank you) and those are out for quite some time, with tons of specs released by AMD/ATI every other month.. Result? (Almost) perfectly running glxgears. Ever tried to run a game with it? Heck, even GL accelerated Duke ...
This is correct, it doesn't exist in any publicly usable form. These ATI/AMD has only recently started releasing specs. They are also actively working on the open source drivers. They are changing quite rapidly and shaping up nicely. Lot's of things in the open source 3d world are changing rapidly... So, I don't expect to see anything The binary Nvidia driver may be fine as long as your running i386 and don't mind the lag behind the rest of Xorg when things change waiting on the next release of the binary. If your on amd64, your out of luck for the time being. So, yes... There is probably room for both drivers, especially as long as Nvidia refuses to publish hardware docs to allow more rapid oss support. " --=20 Robert Noland <rnoland@FreeBSD.org> FreeBSD
Please realize that the blob drivers don't run in many cases, especially with 9-series cards on CURRENT, because they use GIANT locking methods, are compiled against a 5.x kernel / userland, and come with hacked copies of Xorg libraries (which break when we migrate to a non-ABI compatible version of Xorg). Using another alternative like nv or nouveau is the only available option, because Linux and Solaris are second-tier support platforms for nVidia, and FreeBSD is even lower in the support arena it seems... As Robert said, while things won't change tomorrow, there's a high probability that due to people finally getting fed up with not having stable 3D driver support with their cards that developers are working hard to close that gap. So instead of lurking and complaining, why not contribute to the cause? My 2 cents, -Garrett _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
While I sympathize on the complaining ... the response is problematic. I see two ways to contribute to the main problem, which is lack of usable code. (For the moment let's discount "testing" and "documentation".) One could help with one of the open source drivers. Worthy project, but a lot of work involving a skill-set beyond even many coders experienced in other fields. (I'm assuming none of these drivers are on the cusp of a magic moment where lot of good things suddenly happen and it's a coast downhill from there.) The alternative - which sounds seductive but may have its own issues - would be to fill the Nvidia requests and let them write and maintain the code. Again, worthy project (which might have collateral benefits). Again, a lot of work. And an even more esoteric skill-set. If you have some other way a person with limited technical skills can contribute - tell! I'm getting closer to buying a new system, and I'd love to have a moderm graphics card running at full capacity. And, as long as it didn't explode in their faces, I think many others might be willing to help as well. Respectfully, Robert Huff _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
for the time being, I feel almost the same way you do, and all I can do is buy ATi. When someone ask me about new graphics card, I say go ATi ... is what I can do now. And will try this nouveau and help :) matheus -- We will call you cygnus, The God of balance you shall be _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
At this exact moment, radeon is leading the pack. Intel doesn't suck that bad, if an IGP suits your needs. Generally, Intel is a little harder for me to work with than ATI. The nouveau team is quite good to work with as well and I now have at least nv40 class hardware working with EXA and Xv. I started working with the NV50 hardware last night, but I don't have it quite working yet. The features that Nvidia has requested are fairly reasonable and could be used in the open source drivers as well. But, even if/when we deliver those features, they may not be MFC-able. Any ABI changes in either Xorg or our kernel, generally will render the blob useless... " --=20 Robert Noland <rnoland@FreeBSD.org> FreeBSD
Question: would anything _other_ than graphics cards find these That might be a path worth taking. A one time change, well conceived and executed, that goes along with a ".0" release should not be that disruptive. Robert "in my uninformed guesstimate" Huff _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Yes, a large number of devices with large memory requirements or
that pump a lot of data through their buses would benefit from these
changes (large disk mmap, USB, ? Firewire devices like cameras, etc).
Large scale networking with routers and switches would also gain a lot
from this work, especially when dealing with porting apps like IOS on
Cisco products and JunOS on Juniper products to FreeBSD as they
sometimes allocate large amounts of memory for storing spanning trees,
routing lookup tables, and a number of other data structures.
Graphics devices are still the greatest consumer of memory chunks
though, and that's why graphics devices are the largest beneficiary
group for this capability. Networking comes in a close second.
HTH,
-Garrett
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Well, some ways which someone can help are: - Interface with nVidia to say `hey, your driver's broken and you have a bunch of users out here that you're leaving cold in the wind that use your product!'. I've already tried that on the forums by didn't receive that much support... <http://forums.nvidia.com/index.php?showtopic=87932>. If we don't note a problem, I'm pretty sure that because we are a third-tier platform they'll assume that it's business as usual with us, e.g. we don't need support. Saying something like `your driver doesn't support 64-bit' or `you guys suck' without providing hard data, probably won't help our cause as it's all been said before. That's why I specifically asked for a more up-to-date driver without GIANT locking and built against a more recent release like 6.x (yes, it's still being built against 5.x and I have NFI why...). These intermediate steps would relieve the burden required by folks who choose to run the blob drivers as more people could use their stuff. - Provide resources (hardware, money) to developers like Robert and Roman to help make development easier and speed up the entire process. - Test out alpha and beta patches. Sure, we may not like the instability, but as long as we can provide feedback to the developers on whether or not the patches work, that should be sufficient. This should be OK though if you run CURRENT because it is bleeding edge anyhow... - Review and possibly test our the pmap-like interface patch that was provided to the list a while ago, because that helps nail down one requirement that the nVidia folks needed. My 2 cents, -Garrett _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
I'll take that bet... I have 2d and Xv running now. " --=20 Robert Noland <rnoland@FreeBSD.org> FreeBSD
pls uname -a and try patch bellow (current) http://78.107.232.239/futex.c.33.patch --=20 Have fun! chd
thanks for the patch. i applied it and recompiled/reinstalled the kernel. i
ran quake 4 afterwards and the app still crashes:
...
1837 quake4.x86 CALL linux_sys_futex(0x2dbece30,0x81,0x7fffffff,0,0x72d,0x7)
1837 quake4.x86 RET linux_sys_futex 0
1837 quake4.x86 PSIG SIGSEGV caught handler=0x8254b10 mask=0x0 code=0x0
1837 quake4.x86 CALL
linux_sys_futex(0x286ce620,0x81,0x7fffffff,0,0x72d,0xbfbfc4fc)
1837 quake4.x86 RET linux_sys_futex 0
1837 quake4.x86 CALL write(0x1,0x283dd000,0x22)
1837 quake4.x86 GIO fd 1 wrote 34 bytes
"signal caught: Segmentation fault
"
1837 quake4.x86 RET write 34/0x22
1837 quake4.x86 CALL write(0x1,0x283dd000,0xa)
1837 quake4.x86 GIO fd 1 wrote 10 bytes
"si_code 1
"
1837 quake4.x86 RET write 10/0xa
1837 quake4.x86 CALL write(0x1,0x283dd000,0x1c)
1837 quake4.x86 GIO fd 1 wrote 28 bytes
"Trying to exit gracefully..
"
...
the only difference seems to be that now linux_sys_futex is returning 0 as
return value. without the patch it returned 1.
cheers.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
