Very Computer

Need some help.

I'm running RH 6.2 and have an SMC1244TX pci card.
It used the tulip driver and SMC says get this from
the scyld site, which I've done. It needs both the
tulip driver and a pci-scan driver. I had this system
up and running once, then was playing with installing
a 2.4.x kernel which I was never able to bring up so I
wanted to wipe the system and get back to a clean slate.

Here's what happens. I compile the source files and I
see a warning about "...'time_before' redefined...<path>/timer.h:91:
warning: this is the location of the previous definition".
This occurs when I attempt to compile either of the source
files. I don't recall if this warning originally occurred.
When I attempt to insmod pci-scan.o I get two lines about
unresolved symbols:
apm_register_callback_Rsmpf70b592f
apm_unregister_callback_Rsmp99700428.

If I lsmod the pci-scan module isn't listed. The
pci-scan module needs to be loaded prior to loading the
driver for the NIC.

Any ideas on what's going on?

I took a guess that the symbols relate to apmd and
verified that package was installed and even reinstalled
it. Which has had not effect.

TIA

jmh

Quote:> (Posted this to the RH Install ng but no replies today so
> thought I'd try here.)

> Need some help.

> I'm running RH 6.2 and have an SMC1244TX pci card.
> It used the tulip driver and SMC says get this from
> the scyld site, which I've done. It needs both the
> tulip driver and a pci-scan driver. I had this system
> up and running once, then was playing with installing
> a 2.4.x kernel which I was never able to bring up so I
> wanted to wipe the system and get back to a clean slate.

> Here's what happens. I compile the source files and I
> see a warning about "...'time_before' redefined...<path>/timer.h:91:
> warning: this is the location of the previous definition".
> This occurs when I attempt to compile either of the source
> files. I don't recall if this warning originally occurred.
> When I attempt to insmod pci-scan.o I get two lines about
> unresolved symbols:
> apm_register_callback_Rsmpf70b592f
> apm_unregister_callback_Rsmp99700428.

It seems that your running kernel and the configuration used compiling the
modules do not match. There is an option about module versioning in the
kernel configuration choices. Make sure that your kernel is compiled with
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 modules.

HTH

Tauno Voipio

. . .

Quote:> > [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 the
> modules do not match. There is an option about module versioning in the
> kernel configuration choices. Make sure that your kernel is compiled with
> 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
modules.

> HTH

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

jmh

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
obviously moot.

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.

HTH

Tauno Voipio