PCI shared memory - unresolved symbol __ioremap

[Nick Vun]

I wrote a module to scan the PCI display controller memory using ioremap().
No problem in compiling the module. But when I insmod the module, an error message appears - "unresolved symbol __ioremap()".

What is the problem ?

Thanks for any help.

Nick

[Qubit]

Give us some more information...

1) Wild guess: versioning? (It's allways versioning :))
2) Wild guess, slightly more educated though: are you actually using __ioremap() or ioremap()? Be sure to use the non-underscore variant, as the underscore variant is not exported.

[Nick Vun]

I used ioremap() in the modules.

I also suspect it is versioning, so I do a "make mrproper" etc to rebuild the kernel, but the problem remain.

My system was originally installed with RH 6.* (2.2.14), which I upgraded to RH7.0 (2.2.16), but I have since then upgraded the kernel to 2.2.18 and include the lpp patch.

Can it be the library glib that I used ?

Thanks.

[Qubit]

Do a "cat /proc/ksyms | grep ioremap" and see what happens.


Can it be the library glib that I used ?

I don't think so, since the only "library" your module will use is the kernel itself :)

My guess is that this is more of a technical problem, so check your kernel config: do you have a valid System.map in /boot?

[Nick Vun]

Cat of /proc/ksyms shows
c010fa4c __ioremap_R9eac042a

I have my System.map symbolic link to my actual System.map_2.2.18. Cat of System.map shows
c010fa4c T __ioremap
c01f8974 ? __kstrtab___ioremap
c01fec78 ? __ksymtab___ioremap

When I compiled my modules, printk is indicated (as warning message during compilation) to correctly link to the printk_R7**** as shown in the /proc/ksyms. A few other kernel functions like pci_read_** are all indicated to link as that shown in the /proc/ksyms

I noticed that all these successfully linked kernel functions do not have the __ associated with the c*** T __ioremap in the System.map file

The header files I included in the module are
<linux/kernel.h>
<linux/module.h>
<asm/io.h>
<linux/pci.h>

[Qubit]

Man, that's really strange. The only thing there's left is to turn off versioning in the kernel. I once had similar problems (with printk) that went away when I turned off versioning.

I really think this is a technical problem though, because you're not supposed to use the __-functions. Now, ioremap just calls __ioremap (which is also exported, contrary to what I said before ;)), __ioremap is implemented in arch/i386/mm/ioremap.c, and exported somewhere else (the file has 'ksyms' in it, that's all I remember). So, there don't seem to be any strange things on behalf of the kernel, and I suppose you did everything right (right includes), so the problem must be (as the error indicates) during the linking.

Sorry I can't help you there. Do you mind turning off versioning and recompiling?

[ 15 April 2001: Message edited by: Glaurung ]

[pinoy]

Did you compile with optimization on? ie -O

[Nick Vun]

Hi - I got the insmod working with ioremap (i.e. able to insmod)

For some reason, I have included the option
-DMODVERSIONS in my Makefile. It is working fine for the other modules that I have written so far. By removing this option, the module can be inserted with no error message for the __ioremap.

I don't know why it is so, and I also can't remember why I have included -DMODVERSIONS option on the first place now ;-)

Another thing, according to gcc manual, I should have used -O3 in order to use inline function. But using -O3 and -O semms to have no difference in my case.

(Earlier I also tried turning off the versioning and it works as expected. But I was curious why it doesn't work with versioning, and turn it back on again)

Thanks guys for your suggestions ! (but still wondering what really happened)

[Qubit]

It's cool to see that you made your module work :)

Aside: if you don't want to have anymore problems with defining MODVERSIONS, do

#ifdef CONFIG_MODVERSIONS
#define MODVERSIONS
#include <linux/versions.h>
#endif

It might also be linux/version.h, I don't know for sure.