IA32 5336 NV driver and SMP Debian/Woody system: unresolved reference to smp_num_cpus

[freelsjd]

Interesting. I did this change. There was also one other unresolved reference
to smp_call_function which was in routine os-interface.c. I just commented this one out as shown below (probably not the right thing to do).

/* #ifdef CONFIG_SMP
if (smp_call_function(ipi_handler, NULL, 1, 0) != 0)
return RM_ERROR;
#endif */

Now the module links OK and will load from insmod/modprobe.

However, when I start X, it just blanks the screen, but nothing is shown. At least it does not hang the system, and I reloaded the XFree86/nv driver.

Now why isn't this information passed onto the installer ?

[freelsjd]

I just installed the 2.6.5 kernel with an "equivalent" configuration (make oldconfig) as the 2.4.25 kernel. The nvidia installer worked flawlessly. So, it is something incompatible with the 2.4.25 kernel that is causing this.

How many people out there build their own 2.4.25 kernels and use this installer ?

Is this a generic bug ?

I would like to be able to revert back to the 2.4.25 kernel if a stability problem arises with the 2.6.x kernels.

[Thunderbird]

The problem really looks like a kernel bug now, I would submit a bugreport for the Linux kernel. Further I doubt that the 2.6x kernel is very unstable as it has been tested a lot. It also contains some very nice improvements like better SMP support, ALSA support and preempt.

[freelsjd]

10-4 I agree with you there on the 2.6.x kernel. I have two other machines where I have experimented with 2.6 since late 2.5 kernels. I have had some strange failures of applications that I can only blame on the 2.6 kernel for one of those machines which is also a dual-Xeon, but is a Debian/Sid machine. Perhaps this Debian/Woody machine will do better. I am shooting for it to be a production machine.

Thanks for your help...

[freelsjd]

Today, I reported this as a bug in the kernel tracker. It was rejected and I was told to "report nvidia bugs to to nvidia, not here".

I guess there is nothing more I can do. Perhaps another brand of video card if I need to use 2.4.25. Let's hope 2.6.x remains trouble free.

[Thunderbird]

Then see what Nvidia has to say about it. I'm affraight Nvidia will say it is a kernel bug and the way around.

[zander]

Are you using vanilla Linux 2.4.25 or a modified distribution kernel of some kind? The former exports both symbols (arch/i386/kernel/i386_ksyms.c) when configured with CONFIG_SMP (check /proc/ksyms). Also, are you actually running the target kernel when you execute the NVIDIA installer? The black screen upon starting X with the references to the symbols removed is likely the symptom of an entirely different problem.

[freelsjd]

Yes, I am using a vanilla Linux 2.4.25 kernel. I made sure of this by downloading a fresh copy.

The machine is at work right now and running the 2.6.5 kernel with nvidia installed correctly. I will reboot Monday under 2.4.25 and examine /proc/ksyms. I have a second SMP machine running Debian/Sid and 2.4.25 and it indeed shows the smp_num_cpus in proc/ksyms. It also is running the nvidia drivers correctly (I have several machines using nvidia cards and I would very much like to keep them that way !).

Yes, I am running the target kernel when installing. I have learned about this issue in the past.

I get the black screen upon starting X only when I run a SMP kernel with a nvidia driver that has been installed under a uniprocessor kernel. If I run the same driver with a uniprocessor kernel, it works fine as it should. This is the only way I have been able to get the 2.4.25-compiled nvidia driver to load without unresolved external references to smp_num_cpus.

I will investigate /proc/ksyms on Monday and report back here. This was new information for me. You learn something new everyday.

[freelsjd]

The machine, when booted up in SMP-mode with kernel 2.4.25 does indeed show smp_num_cpus in /proc/ksyms.

grep smp /proc/ksyms
c0338b04 smp_num_cpus_R__ver_smp_num_cpus
c0112554 smp_call_function_R__ver_smp_call_function

I also tried to disable apic from the kernel, but I could only do that if I disabled smp. In other words, apic is automatically set by the kernel configuration when smp is set.

So, presently, I can only use the nvidia drivers under 2.6.x-smp and 2.4.x-uniprocessor.

Any more ideas to debug/fix here ?

I also submitted a bug report to nvidia, but have not heard anything back from them at all.

[zander]

You could disable APIC support at runtime (see Documentation/kernel-parameters.txt), but this is a compile time problem. From the looks of it, the kernel's MODVERSIONS information is broken, hence the unresolved symbols (with bogus names). Since this seems to be a persistent problem (i.e. it persistet across multiple builds), you should disable MODVERSIONS and rebuild the kernel; the NVIDIA driver should work correctly after that.

[freelsjd]

Bingo ! This fixed the problem. Thanks Zander for you insight and help !

I have filed a bug report already with the kernel folks (they rejected), and the nvidia folks (they have not acknowledged). I am not sure how this can be corrected. Should MODVERSIONS be disabled for all 2.4.x kernels that use nvidia drivers ? If you read the help on MODVERSIONS, this is exactly what this option is intended for (commercial modules across different kernels) !