Paul Abrahams wrote:

Mark Hounschell wrote:

...

Paul Abrahams wrote:

...

For about the fourth time I've tried to generate and install the NVIDIA drivers (newest version, 1251). And each time things get worse. The main problem I have is with the kernel module. When I attempt to install it I get a notification of an unresolved symbol _mmx_memcpy. Until the most recent iteration I could still get the server to run, albeit defectively. But now it won't run at all -- I get the message "failed to initialize the NVdriver kernel module". Supposedly that's because I'm using the wrong header files, but the generation scripts seem to indicate that the correct kernel include files are being summoned.

I've tried doing the install using both the rpm's and the tar files, with essentially the same result either way. I've also tried specifying the include files explicitly with the SYSINCLUDE parameter. The only difference I've found between using the rpms and the tarfiles is that the rpms put the NVdriver module in /lib/modules/2.4.4/kernel/drivers/video while the tarfiles put it in /lib/modules/2.4.4/kernel/video, one level higher in the tree.

First off these locations for the module are a BAD THING. Nothing but native kernel modules should go into these locations. They should be reserved for that only because as of 2.4 kernel the kernel build process "make modules_install" removes anything in them. So first off remove all instances of NVdriver in all locations in /lib/modules/2.4.4/. Use the find command.

That use of misc would solve another problem: losing the ALSA sound modules after a kernel module remake.

...

Also rmmod any instance of the driver that may be already loaded. Then modify the Makefile from the tarball. (always use the tarball)

Change this:

ifeq ($(shell if test -d $(KERNDIR)/kernel; then echo yes; fi),yes) INSTALLDIR=$(KERNDIR)/kernel/video else INSTALLDIR=$(KERNDIR)/video endif

to: ifeq ($(shell if test -d $(KERNDIR)/misc; then echo yes; fi),yes) INSTALLDIR=$(KERNDIR)/misc/video else INSTALLDIR=$(KERNDIR)/video endif

Note: KERNDIR is set by the following line: KERNDIR=/lib/modules/$(shell uname -r)

This will save you headaches if you ever get it to work and need to recompile your kernel. Next make sure /usr/src/linux is a link to /usr/src/linux-2.4.4 and that you are indeed running the kernel that came from /usr/src/linux.

"uname -r" says 2.4.4, and it is indeed a vanilla kernel that I compiled myself.

...

I have 4 boxes with TNT2 chipset running 2.4.4 kernel(vanilla). I havn't tried the 2.4.4 sources from Mantels directory so I can't vouch for it. I don't know exactly where the _mmx_memcopy thing is comming from but I have seen it also.

That's reassuring. I've tried recursive greps in a number of places, including the source directory, and have found nothing as to where the _mmx_memcopy thing originates. I think it's being brought in indirectly.

...

And it seems that the makefile isn't finding the correct things it needs from your kernel source tree.

I can believe that, but I can't explain it. /usr/src/linux is definitely symlinked to /usr/src/linux-2.4.4. Your experience in also encountering the _mmx_memcopy problem suggests that the problem is not just a failure to refer to the correct kernel version.

...

Be sure not to turn on any agp settings in your kernel if they don't match your chipset.

I couldn't find any agp-related settings through "make xconfig" in /usr/src/linux.

...

If unsure, leave them all off. Also if you have an AMD irongate chipset make sure to turn OFF framebuffer support. So once you are sure you have your kernel built and running and every thing above has been done then do your make install from the nvidia directory and see what happens. Hope it helps and let us know.

Alas, moving the driver from /lib/modules/2.4.4/kernel/video to /lib/modules/2.4.4/video made no difference whatsoever in the behavior, either in terms of the messages during the build or the failure afterwards.

At least I have things set up so that I can run experiments. In my /etc/X11 directory I have two files, XF86Config.000 and XF86Config.001. The 000 file calls the nv driver; the 001 file calls the NVidia driver. I just copy one or the other to XF86Config. So when the NVidia drivers fail, as they now do consistently, I revert to the nv drivers and can get back on the air to send messages such as this one.

Paul

How did you build your kernel. You know that in the top makefile /boot is commented out such that the make bzlilo or make zlilo command will put your new kernel in / and not /boot. Just fishing for a cause. Also the agp stuff in your kernel is in char devices right below the ftape entry (if you are doing make xconfig). It's easily missed. It looks like _mmx_memcpy has somthing to do with pentium/mmx setting in .config file. Maybe try changing cpu type in your kernel. I have basically duplicated your problem simply by building a kernel after changing my cpu type to pentium mmx instead of athlon and then trying do load the NVdriver without rebuilding it. I get the same message about mmx_memcpy. It still points to, your not running the kernel you think you are. Did you do zlilo or bzlilo??? Mark -- Mark Hounschell dmarkh@cfl.rr.com

Paul Abrahams wrote:

Mark Hounschell wrote:

...

I have basically duplicated your problem simply by building a kernel after changing my cpu type to pentium mmx instead of athlon and then trying do load the NVdriver without rebuilding it. I get the same message about mmx_memcpy. It still points to, your not running the kernel you think you are. Did you do zlilo or bzlilo???

I do bzlilo.

I'll try the kernel change and keep you posted. I'm also moving my sound stuff from /lib/modules/2.4.4./kernel/sound to /lib/modules/2.4.4/misc/sound. That should avoid many headaches.

An update: recompiling the kernel with the correct processor type made the error message go away. I can now use the NVidia drivers again. But the problem with them remains: after one iteration through kdm, the virtual terminals (Alt-Ctl-F2, etc.) no longer work. Paul

Mark Hounschell wrote:

Paul Abrahams wrote:

...

An update: recompiling the kernel with the correct processor type made the error message go away. I can now use the NVidia drivers again. But the problem with them remains: after one iteration through kdm, the virtual terminals (Alt-Ctl-F2, etc.) no longer work.

Paul

What do you mean "after one iteration through kdm".

I boot my system and kdm starts. I log in. Ctl-Alt-F2 works. If I log out and log in again, Ctl-Alt-F2 doesn't work; I get a dead screen. Ctl-Alt-F7 brings the screen back and revives the mouse. I know the problem is related to kdm and to xdm, which lies underneath it. With a different login manager such as gdm, it doesn't happen.

Have you looked at the stuff in your kernel config that I suggested. The agp stuff in particular. Unless you have a supported chip set in there you should disable all of it. Also framebuffer support (which is in the console drivers section). It's what gives you the little penguin in the top left corner when you boot up? That screwed me up good.

Both AGP support and framebuffer support are disabled. That doesn't solve the problem.

My symptoms were I think similar in that from the kdm login screen any (Alt-Ctl-fx) or reboot or shutdown from there would hang my system and I would have to hit the reset switch. After removing framebuffer support in my kernel and unchecking the agp stuff that didn't apply to my system I was then able to do the above. Note: Even though I was able to do those things (reboot/shutdown) from the kdm login screen then, my screen is still black while it is happening. My only indication it's rebooting/shutting down is the disk activity light.

I get the kdm startup screen with the logo moving around. But the behavior is similar. What happens on your system if you try to switch to a virtual terminal after logging out (not rebooting) and logging in again?

I know, these nvidia drivers can be a real pain in the A. Sure would be nice if they would turn them loose.

Yes. Or at least fix the bugs. Paul

Mark Hounschell wrote:

It looks like the same as you. After bootup all is ok but after exiting and logging backin [Alt-CTL-Fn] do not work and ALT-CTL-F7 gets me back ok. But since I never do that anyway it doesn't bother me. Once in kde all works great. If I need a term I open konsole. I have never had a need to use the ALT-CTL-Fx from within kde or the kdm prompt. Oh well, you know what the doctor says, if it hurts don't do it.

It's always useful to know that the misbehavior isn't peculiar to my system. We have a real, genuine, certified bug here. Paul

Ben Rosenberg wrote:

* Paul Abrahams (abrahams@acm.org) [010530 12:50]: ->Mark Hounschell wrote: -> ->> It looks like the same as you. After bootup all is ok but after exiting ->> and logging ->> backin [Alt-CTL-Fn] do not work and ALT-CTL-F7 gets me back ok. But since I ->> never do that ->> anyway it doesn't bother me. Once in kde all works great. If I need a ->> term I open ->> konsole. I have never had a need to use the ALT-CTL-Fx from within kde ->> or the kdm ->> prompt. Oh well, you know what the doctor says, if it hurts don't do it. -> ->It's always useful to know that the misbehavior isn't peculiar to my system. We have a ->real, genuine, certified bug here.

Solution:

1. Get kernel 2.4.4's RPM /pub/people/mantel/next/RPM A. Install this. 2. Get kernel 2.4.4's tar.gz /pub/people/mantel/next 3. Unzip the tar.gz kernel src in /usr/src and replace the link so that it points to the new src. 4. Get the tar.gz files of the nVidia driver and GLX. 5. mv them to /usr/src and untar them. 6. cd into the kernel module directory and make the module 7. Do the make install for the GLX. 8. Search the archives for the modified switch2nv_glx and use this. 9. It will work. I have NO problems ..with or without KDM.

Unresolved symbols stem from a mismatch of src. If you don't have the same src that your compiling the module against as your running kernel is using..then the module will be hella fucked up and won't work. These drivers work. The kernel works. Doing it right makes it work.

Last 0.02 -- Ben Rosenberg mailto:ben@whack.org ----- If two men agree on everything, you can be sure that only one of them is doing the thinking.

The unresolved symbols problem has been fixed. Read the thread closer. We are now only having problems with the use of a cleanly built/installed driver. Your solution will do nothing to fix this other problem that we are having with it. Although I've been meaning to try that particular kernel for other reasons. We'll see. But our problem now is not an unresolved symbol problem. It's something else that appears just to be the driver it's self. Thanks Mark

* Paul Abrahams [May 30. 2001 18:31]:

What is the function of switch2nv_glx? How would one undo its effect?

Look at it. It is just shellscript (/usr/X11R6/bin/switch2nv_glx) that links libraries etc. correctly. So undoing it is fairly easy -- just see what was done and revert it. -- Mads Martin Joergensen, http://mmj.dk "Why make things difficult, when it is possible to make them cryptic and totally illogic, with just a little bit more effort." -- A. P. J.

->> ->> So undoing it is fairly easy -- just see what was done and revert it. -> ->I forgot. Please read: http://learn.to/edit_messages. Mads, I don't think anyone has USED the script I posted that we altered. Which is why I was advocating the use of it. You've seen my box..no problems eh? I don't get where all these issues are coming from. Regards, -- Ben Rosenberg mailto:ben@whack.org ----- If two men agree on everything, you can be sure that only one of them is doing the thinking.

* Paul Abrahams (abrahams@acm.org) [010531 06:58]: -> ->By the way (note to Mads), the problem in understanding the script isn't ->what the commands do. It's what all those library files are about, and what ->the relationship is between Mesasoft and GLX. There seem to be some ->conflicts, but I don't understand them nor do I understand the best way to ->resolve them. Simple. Delete Mesasoft..because it's also an implementation of OpenGL..and yes it will conflict with nVidia's GLX. :) -- Ben Rosenberg mailto:ben@whack.org ----- If two men agree on everything, you can be sure that only one of them is doing the thinking.

* Ben Rosenberg (Wed, May 30, 2001 at 07:37:01PM -0700)

Once the proper version of OpenGL is installed then if you have 3D enabled ..everything works right. I highly recommend using the 2.4.4 kernel, nVidia's new module release and their GLX (opengl)..I haven't had any issues.

Then you've obviously never had to use color indexed textures . Try the below and see if you get anything better than a black square in the middle Note; you need Motif and GLw #include #include #include #include #include #include #include #include #include #include #include #include #include //#define DO_LUMINANCE_ALPHA //#define USE_EXTENSIONS static GLXContext glx_context = NULL; static GLuint tex_name; static void init_action(Widget glx_widget, XtPointer user_data, XtPointer call_data) { GLwDrawingAreaMakeCurrent(glx_widget, glx_context); #ifdef USE_EXTENSIONS GLubyte tex_image[4 * 4 * 2]; for(int y = 0; y < 4; y++) { for(int x = 0; x < 4; x++) { int idx = 8 * y + 2 * x; if((x + y) % 2 == 1) { tex_image[idx] = 255; tex_image[idx + 1] = 255; } else { tex_image[idx] = 0; tex_image[idx + 1] = 0; } } } #else GLubyte tex_image[4 * 4]; for(int y = 0; y < 4; y++) { for(int x = 0; x < 4; x++) { int idx = 4 * y + x; if((x + y) % 2 == 1) { tex_image[idx] = 255; } else { tex_image[idx] = 0; } } } #endif #ifdef USE_EXTENSIONS GLfloat lut[4 * 256]; for(int i = 0; i < 256; i++) { int idx = 4 * i; lut[idx] = (i < 128) ? 1.0 : 1.0 - (i - 128) / 127.0; lut[idx + 1] = (i < 128) ? i / 127.0 : 1.0 - (i - 128) / 127.0; lut[idx + 2] = (i < 128) ? 0.0 : (i - 128) / 127.0; lut[idx + 3] = i / 255.0; } #else GLfloat redMap[256]; GLfloat greenMap[256]; GLfloat blueMap[256]; GLfloat alphaMap[256]; for(int i = 0; i < 256; i++) { redMap[i] = (i < 128) ? 1.0 : 1.0 - (i - 128) / 127.0; greenMap[i] = (i < 128) ? i / 127.0 : 1.0 - (i - 128) / 127.0; blueMap[i] = (i < 128) ? 0.0 : (i - 128) / 127.0; alphaMap[i] = i / 255.0; } glPixelMapfv(GL_PIXEL_MAP_I_TO_R, 256, redMap); glPixelMapfv(GL_PIXEL_MAP_I_TO_G, 256, greenMap); glPixelMapfv(GL_PIXEL_MAP_I_TO_B, 256, blueMap); glPixelMapfv(GL_PIXEL_MAP_I_TO_A, 256, alphaMap); #endif glGenTextures(1, &tex_name); glBindTexture(GL_TEXTURE_2D, tex_name); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE); glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, 4, 4, 0, #ifdef USE_EXTENSIONS GL_LUMINANCE_ALPHA, #else GL_COLOR_INDEX, #endif GL_UNSIGNED_BYTE, tex_image); glBindTexture(GL_TEXTURE_2D, 0); #ifdef USE_EXTENSIONS glColorTableSGI(GL_TEXTURE_COLOR_TABLE_SGI, #if defined(DO_LUMINANCE_ALPHA) GL_RGBA, #else GL_RGB, #endif 256, GL_RGBA, GL_FLOAT, lut); (void)glGetError(); glGetColorTableSGI(GL_TEXTURE_COLOR_TABLE_SGI, GL_RGB, GL_FLOAT, lut); cout << "glGetColorTableSGI returns error code: 0x" << hex << glGetError() << dec << endl; #endif } static void expose_action(Widget glx_widget, XtPointer user_data, XtPointer call_data) { GLwDrawingAreaCallbackStruct *cbs = (GLwDrawingAreaCallbackStruct *)call_data; GLwDrawingAreaMakeCurrent(glx_widget, glx_context); glMatrixMode(GL_PROJECTION); glLoadIdentity(); glOrtho(-1.0, 1.0, -1.0, 1.0, -1.0, 1.0); glMatrixMode(GL_MODELVIEW); glLoadIdentity(); glViewport(0, 0, cbs->width, cbs->height); glClearColor(0.0, 0.5, 0.5, 1.0); glClear(GL_COLOR_BUFFER_BIT); glDisable(GL_TEXTURE_2D); glColor3f(0.0, 0.0, 0.0); glLineWidth(1.0); glBegin(GL_LINES); for(GLfloat c = -1.0; c < 1.0; c += 0.1) { glVertex2f(c, -1.0); glVertex2f(c, 1.0); glVertex2f(-1.0, c); glVertex2f(1.0, c); } glEnd(); glBindTexture(GL_TEXTURE_2D, tex_name); glColor3f(1.0, 1.0, 1.0); glEnable(GL_TEXTURE_2D); glEnable(GL_BLEND); glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA); #ifdef USE_EXTENSIONS glEnable(GL_TEXTURE_COLOR_TABLE_SGI); #endif glBegin(GL_TRIANGLE_STRIP); glTexCoord2f(0.0, 0.0); glVertex2f(-0.8, -0.8); glTexCoord2f(1.0, 0.0); glVertex2f(0.8, -0.8); glTexCoord2f(0.0, 1.0); glVertex2f(-0.8, 0.8); glTexCoord2f(1.0, 1.0); glVertex2f(0.8, 0.8); glEnd(); GLwDrawingAreaSwapBuffers(glx_widget); } int main(int argc, char *argv[]) { XtToolkitInitialize(); XtAppContext app_ctx = XtCreateApplicationContext(); Display *dpy = XtOpenDisplay(app_ctx, NULL, "widTestMotif", "WIDTestMotif", NULL, 0, &argc, argv); if(dpy == NULL) exit(1); int glx_attribs[] = {GLX_RGBA, GLX_DOUBLEBUFFER, None}; XVisualInfo *glx_vis = glXChooseVisual(dpy, DefaultScreen(dpy), glx_attribs); if(glx_vis == NULL) exit(2); Colormap cmap = XCreateColormap(dpy, RootWindow(dpy, glx_vis->screen), glx_vis->visual, AllocNone); if(cmap == (Colormap)None) exit(3); #if defined(DO_LUMINANCE_ALPHA) const char *app_name = "LUT test RGBA"; #else const char *app_name = "LUT test RGB"; #endif Widget toplevel = XtVaAppCreateShell(app_name, "LUTtest", applicationShellWidgetClass, dpy, XmNvisual, glx_vis->visual, XmNdepth, glx_vis->depth, XmNcolormap, cmap, NULL); Arg args[32]; int n = 0; XtSetArg(args[n], XmNwidth, 400); n++; XtSetArg(args[n], XmNheight, 400); n++; Widget main_form = XmCreateForm(toplevel, "MainForm", args, n); XtManageChild(main_form); glx_context = glXCreateContext(dpy, glx_vis, NULL, GL_TRUE); if(glx_context == NULL) exit(4); n = 0; XtSetArg(args[n], XmNtopAttachment, XmATTACH_FORM); n++; XtSetArg(args[n], XmNbottomAttachment, XmATTACH_FORM); n++; XtSetArg(args[n], XmNleftAttachment, XmATTACH_FORM); n++; XtSetArg(args[n], XmNrightAttachment, XmATTACH_FORM); n++; XtSetArg(args[n], GLwNvisualInfo, glx_vis); n++; Widget glx_widget = GLwCreateMDrawingArea(main_form, "OpenGLwindow", args, n); XtManageChild(glx_widget); XtAddCallback(glx_widget, GLwNginitCallback, init_action, NULL); XtAddCallback(glx_widget, GLwNexposeCallback, expose_action, NULL); // Realize and loop XtRealizeWidget(toplevel); XtAppMainLoop(app_ctx); exit(0); } // // EOF // They're broken. All you get is

I will try the logging in and out bit..even though I never use KDM..it's a resource hog and I don't need a gui login. *shrug* -- Ben Rosenberg mailto:ben@whack.org ----- If two men agree on everything, you can be sure that only one of them is doing the thinking.

-- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/support/faq and the archives at http://lists.suse.com

Currently listening to: Tool - The Patient (Lateralus) Gerhard, <@jasongeo.com> == The Acoustic Motorbiker == -- __O In Italy, for thirty years under the Borgias, they had warfare, =`\<, terror, murder and bloodshed, but they produced Michelangelo, (=)/(=) Leonardo da Vinci, and the Renaissance. In Switzerland they had brotherly love, they had five hundred years of democracy and peace, and what did they produce? The cuckoo clock.

On Thursday 31 May 2001 07:54 am, Mark Hounschell wrote:

Ben Rosenburg wrote:

...

...

Solution:

1. Get kernel 2.4.4's RPM /pub/people/mantel/next/RPM A. Install this. 2. Get kernel 2.4.4's tar.gz /pub/people/mantel/next 3. Unzip the tar.gz kernel src in /usr/src and replace the link so that it points to the new src. 4. Get the tar.gz files of the nVidia driver and GLX. 5. mv them to /usr/src and untar them. 6. cd into the kernel module directory and make the module 7. Do the make install for the GLX. 8. Search the archives for the modified switch2nv_glx and use this. 9. It will work. I have NO problems ..with or without KDM.

Unresolved symbols stem from a mismatch of src. If you don't have the same src that your compiling the module against as your running kernel is using..then the module will be hella fucked up and won't work. These drivers work. The kernel works. Doing it right makes it work.

The unresolved symbols problem has been fixed. Read the thread closer. We are now only having problems with the use of a cleanly built/installed driver. Your solution will do nothing to fix this other problem that we are having with it. Although I've been meaning to try that particular kernel for other reasons. We'll see. But our problem now is not an unresolved symbol problem. It's something else that appears just to be the driver it's self.

Well I've tried mantels kernel and all and it does not make any differenc. I can live with these issues myself. As long as my 3d works and my machine doesn't hang I can live with it.

Regards Mark

I've done a ton of updates to 7.1 Pro to get to where 7.2 will be when it's released... so hopefully when 7.2 comes out, it will be more "solid" than 7.1+updates. *fingers crossed* -Steven