nvidia FreeBSD drivers and linux ut2003
 

This mail is to explain problems I'm having with my system right now getting ut2003 to run.

First of all, Quake 3, Wolfenstein, Tribes II, etc... all work on my system, just not ut 2003.


When I first finished installing ut2003 and ran it, the splash screen came up, and immediately after that, the computer reboots. So thinking this might be a BIOS issue, I went in and turned off the 1 Waitstate read and write options for AGP. After this, the original install of ut2003 worked fine, so I updated it to the latest version. The latest version just crashes the computer no matter what the bios settings are. I have all the latest XFree86 ports from the ports tree, and and up-to-date stable as of yesterday (11/12) at about 11 pm est.

I have log files (XFree86.0.log from /var/log, and dmesg.boot if anyone wants to see...)

This is my hardware:

Abit kx7-333 mobo (via kt333 chipset)
256MB crucial (micron) pc2100 ddr sdram
hercules Fortissimo 2 soundcard
Geforce 3 Ti 200

I have agp running in 4x, and all the bios settings I'm using work fine in windows with ut2003 and all other games (I'd like to get rid of windows, and the only reason I still have it is for games)

Anyway... anyone have any ideas, want more info?

Have you done 'setenv __GL_SINGLE_THREADED'? If not, UT2003 will crash every time. I recommend putting that in your ~/.cshrc until the known multi-threading issues are solved.

I did that, I have it in my .cshrc because no other games work without it. Even with it I have this crashing problem. It's not just the game crashing, it's the whole computer, I have a
backtrace from the kernel panic.

atomic_clear_short(c1596400,d2ae5a40,1556,1556,d2a e5a40) at atomic_clear_short+0xb
nv_alloc_pages(c1596400,d2ae5a40,1556,1,1) at nv_alloc_pages+0x37
__nvsym00150(c17a4000,d2ae5a40,1556,1,1) at __nvsym00150+0x4b
__nvsym00142(c17a4000,c1d00021,d2ae5a40,d2ae5a44,d 2ae59e4) at __nvsym00142+0x120
__nvsym00153(c1d00021,beef0003,beef0020,3e,2100) at __nvsym00153+0x84
__nvsym00606(c1596400,c1690a00,27,d2ae5e88,d2ae5d2 4) at __nvsym00606+0x35b
rm_ioctl(c1596400,c1690a00,27,d2ae5e88,d2ae5d6c) at rm_ioctl+0x17
nvidia_handle_ioctl(c15ab500,c0284627,d2ae5e88,3,c c322520) at nvidia_handle_ioctl+0x53
nvidia_dev_ioctl(c15ab500,c0284627,d2ae5e88,3,cc32 2520) at nvidia_dev_ioctl+0x3a
spec_ioctl(d2ae5dc4,d2ae5dac,c01b99b1,d2ae5dc4,d2a e5e54) at spec_ioctl+0x26
spec_vnoperate(d2ae5dc4,d2ae5e54,c017cb37,d2ae5dc4 ,c1867f40) at spec_vnoperate+0x15
ufs_vnoperatespec(d2ae5dc4,c1867f40,0,28,c025b000) at ufs_vnoperatespec+0x15
vn_ioctl(c1867f40,c0284627,d2ae5e88,cc322520,c0e34 700) at vn_ioctl+0x10f
ioctl(cc322520,d2ae5f80,d2ae5f34,c030bd70,cc322520 ) at ioctl+0x20a
linux_ioctl_nvidia(cc322520,d2ae5f80,cc322520,3,c0 314088) at linux_ioctl_nvidia+0xe
linux_ioctl(cc322520,d2ae5f80,60,bfbfce90,80e9150) at linux_ioctl+0x54
syscall2(2f,2f,2f,80e9150,bfbfce90) at syscall2+0x16a


Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc1d00025
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc020f52c
stack pointer = 0x10:0xd2ae5664
frame pointer = 0x10:0xd2ae5668
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 172 (ut2003-bin)
interrupt mask = none
kernel: type 12 trap, code=0

Fun stuff huh?

Interesting, I am getting that same crash...and its happening in atomic_clear_shot How did you get the nVidia drivers to compile debug, so you could get the proper backtrace from that?

just went into the nvidia driver distribution directory (the one that is created when you untar the driver) and cd to module.

Edit the makefile so that CFLAGS includes a -g

go back to the top level driver directory

make

make install

reboot

That's how I did it

Ahh, simple enough. I will do that. Should have known that myself :P

Also, I said wolfenstein works perfectly. It does most of the time, but occasionally it doesn't. It causes the same panic as ut2003 sometimes... but not very often.

Do you have a ~/.openalrc? With the device line about SDL in it? I moved that file temporarily, to a backup...and started UT2003, and it worked fine. When I have that file, with the device block for SDL in it, the game will crash my system.

I don't have a .openalrc

Ken

And even if I did, Wolfenstein doesn't use openal, so I don't think that's whats causing the crash. It's probably just aggravating some memory management problem for you, where for me, something else is aggravating it. In the kernel panic, the crash is clearly due to some problem either in the driver, or in the vm functions the driver calls.

More on this problem that might help you debug.

in nv_alloc_pages()

first an object is allocated, then it goes and finds some nvidia specific
data structure contained in that object (from what I can tell), then it
calls rm_alloc_agp_pages (which is a function that I don't have access to.
it is in the proprietary part of the driver I guess), then calls
nv_free_vm_object(). I suppose that rm_alloc_agp_pages could very well be
screwing up the vm object, in which case it's part of the proprietary
non-open-source part of the driver that's messing things up.

Just in case this helps anyone.

It's good to have the two of you in the same place, I'm trying to make sense of this problem and haven't been able to reproduce it as of yet.

It'd be good if you, both, could post detailed information about your system's hard and software (including AGP aperture size). Hopefully this will help somewhat.

I'm assuming you're using FreeBSD -STABLE and have tried the basic sanity precautions mentioned in the FAQ hosted by the NVIDIA petition people (i.e. building without optimizations, etc). I understand that all you need to do is start UT2003 to trigger this problem?