> . . .
> > > [bla bla bla] I get two lines about
> > > unresolved symbols:
> > > apm_register_callback_Rsmpf70b592f
> > > apm_unregister_callback_Rsmp99700428.
> > These symbols are combined with the kernel version.
> > It seems that your running kernel and the configuration used compiling
> > modules do not match. There is an option about module versioning in the
> > kernel configuration choices. Make sure that your kernel is compiled
> > the same value for the option as used when compiling the modules.
> > The discrepancy prevents the modules from working.
> > A sure-fire way to repair is to re-compile the whole kernel and the
> > HTH
> Again, thanks for the help. I will recompile everything and
> hope I get it right and solve the problem.
> If you've got a little time can you explain the
> above a bit more? What would I look for in the future
> if I have to compile a new driver in order to
> make sure the values for the kernel options and
> the module options are the same? Is that an
> issue about whether the kernel was compiled
> with loadable module support? The device compiled
> into the kernel versus as a module? Something else?
> again, TIA
The modules connect with the kernel body using the exported kernel symbols.
The symbols can be seen in /boot/System.map-<kernel-version>.
When setting up the kernel for compilation (make menuconfig, etc...), there
is an option (under lodable module support) whether the symbols are to be
versioned. The versioning is done adding a random-looking string to each
symbol. The string is generated from the kernel version and configuration
(single or multi-processor).
The idea is to prevent loading modules from an incompatible version.
If you are sure that you're not going to try to load alien modules,
configure the kernel without module synbol versioning.
The issue with module symbols rises up only if there is loadable module
support in the kernel. If there is no module support in the kernel, there
are no exported symbols, and the point of exported symbol versioning is
If you compile a module with a home-compiled kernel running and its
configuration still left in the /usr/src/linux subdirectory, the module
should get compatible options to the kernel (assuming that the module can be
compiled to the current kernel version at all).
The symbols you're having trouble with point to the fact that you're running
a multi-processor kernel (SMP), maybe a distribution kernel, and the
configuration in the source directory does not match it.