Created attachment 20161 [details] Archlinux dmesg dump Chipset: G35 on Asus P5E-VM HDMI Arch: i686 (Celeron 420) Testing on Archlinux (Fedora core follow later) 2.6.27-ARCH mesa 7.2-1 xf86-video-intel 2.4.2-2 libdrm 2.4.1-1 xorg-server 1.5.3-1 Neverwinter nights HOTU v.1.69 (final) To reproduce: The fastest way to reproduce this is the "craft armor" menu to add a cloak. This is accessed via a radial menu that is also mapped to the numerical pad, so it's possible to 'dial' to the menu. 1) Start the program and load/start a game. 2) Dial 0 4 8 (or analogueous right-click-on-hero left-option top-option) to bring up the craft armour menu. 3) Select option 2. "Craft armor" 4) Choose to add/remove a robe 5) Adding any robe crashes the game with little or none debug info. I have made dmesg dumps before and after and they are the same. I also copied /var/log/Xorg.0.log before and after: there is no change. On the console using LIBGL_DEBUG=verbose the following is printed: [joel@hotpipe32 Neverwinter]$ LD_LIBRARY_PATH=./miles:$LD_LIBRARY_PATH LIBGL_DEBUG=verbose ./nwmain libGL: XF86DRIGetClientDriverName: 1.9.0 i965 (screen 0) libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/tls/i965_dri.so libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/i965_dri.so drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: Searching for BusID pci:0000:00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: drmOpenMinor returns 10 drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 libGL error: Can't open configuration file /etc/drirc: No such file or directory. Failed to initialize TTM buffer manager. Falling back to classic. Aborted [joel@hotpipe32 Neverwinter]$
Created attachment 20162 [details] Archlinux xorg.log
Running under Archlinux wine (1.1.7-1) it also crashes much the same, but got at least a little more output about the error that I'm attaching. When I did the same in Fedora Core neverwinter didnt crash and return to desktop, but that's only because the rest of the system crashed harder and froze.
Created attachment 20163 [details] Archlinux wine debug info from console
Created attachment 20495 [details] Could-be a problematic shader? I don't know if this can be important, but replacing the glLoadProgramNV with a stub make Nwn run stable (for those intrested in the stub visit the Linux forum at Bioware's site) I also made a wrapper glLoadProgram library, to inspect what the calling parameters were. I found out that it's called as: glLoadProgramNV(34336,1,2880,str) Translating the first to hexadecimal, and grepping Mesa/includes gives: glext.h:#define GL_VERTEX_PROGRAM_ARB 0x8620 glext.h:#define GL_VERTEX_PROGRAM_NV 0x8620 I did not find much documentation about given call, (where can I find it?) from google the following should be ID, length of program (stripping out comments), and some kind of pointer to the program. In this case the pointer is a shader program string, so it's: glLoadProgramNV(GL_VERTEX_PROGRAM_NV,int id, int prg_len, char *prg) I remember that Eric checked the shader program strings in the main executable (bug 13728). However, this shader program is not listed with `strings nwmain`. I'm attaching it for easy reference, adding some newlines for readability.
I get this problem on an ATI R500 (x1950 pro) i686 Phenom with 32 bit userspace Debian 2.6.26-1-686 libgl1-mesa-dri 7.2-1 xserver-xorg-video-radeon 1:6.9.0+git20081129.783cdb73-1 libdrm2 2.4.1+git+20081116+930c0e7-1 Neverwinter nights HOTU v.1.69 (final) The game crashes with "Aborted" If I use Joels LD_PRELOAD stub to remove calls to glLoadProgramNV(...) then it works fine (though obviously some textures are missing).
I also get this problem on another machine with an ATI Technologies Inc RV350 AR [Radeon 9600] Athlon 3000+ Debian 2.6.27.4 libgl1-mesa-dri 7.2-1 xserver-xorg-video-radeon 1:6.9.0+git20081129.783cdb73-1 libdrm2 2.3.1-1 Neverwinter nights HOTU v.1.69 (final) The game crashes with "Aborted" as soon as I select a robe/cloak for a character. If I use Joels LD_PRELOAD stub to remove calls to glLoadProgramNV(...) then it works fine (though again, obviously some textures are missing).
(In reply to comment #4) > I did not find much documentation about given call, (where can I find it?) http://oss.sgi.com/projects/ogl-sample/registry/NV/vertex_program2.txt google for LoadProgramNV, not the gl.... variant
The error I get is nwmain: main/state.c:1030: update_program: Assertion `ctx->VertexProgram._Current->Base.Parameters' failed. I've tried replacing the VP with various other programs but all give the same result. (I don't know what a minimal VP should look like though) I used: !!VP1.0 # Minimal vertex program. DP4 o[HPOS].x, c[0], v[OPOS]; DP4 o[HPOS].y, c[1], v[OPOS]; DP4 o[HPOS].z, c[2], v[OPOS]; DP4 o[HPOS].w, c[3], v[OPOS]; END
commit a4a5a37f2760eca97b85f699c932c746da4d8e6c Author: Brian Paul <brian.paul@tungstengraphics.com> Date: Fri Sep 26 07:45:06 2008 -0600 mesa: remove invalid assertions that programs have parameters Fixes failure with demos/fplight.c
I can confirm that commit a4a5a37f2760eca97b85f699c932c746da4d8e6c stops this crash on NWN :) I got the source for debian mesa 7.2 and simply applied the (now massively offset) patch. NWN then runs and displays some of the previously missing textures - including cloaks; I have noticed one texture doesn't display properly but that's a different bug.
Now aborting on brw_upload_vs_prog at /mesa/drivers/dri/i965/brw_vs.c:93 > assert (vp && !vp->program.IsNVProgram); With latest: - Mesa git (commit: a8921d0b52f04bbd62c66278e7421e6b99bfd7c3) - libDRM (commit: 9aed44beeac4f250a58c792d64a4dee1dde3d086) and - Intel Driver (commit: 0a4c4c5fe8ebad2dd13f5770bd90a194eebb2890) My card is an Intel® GM45 Express Chipset
Mass version move, cvs -> git
commit a9a47afe7e87075432ce2d393b55409fcb7149ac Author: Eric Anholt <eric@anholt.net> Date: Wed Sep 23 16:50:59 2009 -0700 i965: Remove assert about NV_vp now that it somewhat works.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.