在Linux2.6.26下用EXPORT_SYMBOL时出现Unknown symbol?

Latest working kernel version:2.6.28

Earliest failing kernel version:2.6.26

Distribution:

Hardware Environment:

Software Environment:

Problem Description:

When you use driver dependent on other driver. It should load cleanely, if

other is loaded. But in kernel 2.6.26 onwards its give error, unknown symbol

found.

Actually find_symbol able to find symbol but check_version unable to match crc.

Because crc is not know to other driver. 



Steps to reproduce:

1) create two device drivers in two separate directories. let say hello and bye 

2) Export Symbol from hello module and try to use that in bye module.

3) Compile both the driver separately.

4) insmod hello.ko

3) While insmod(ing) bye.ko, gives error "Unknown Symbol found"

what about using modprobe instead ? (as this looks in modules.dep to find the

dependend modules and load them before) 

Hi Roland, using modprobe doesn''t work. The entries in modules.dep are added.

Still it ends up showing the same prints - "no symbol version for " and

"Unknown symbol ". And modprobe fails.

Hi Roland,

   Thanks a lot for replying. Below I have written details of experiments we

did and our understanding.



Problem: insmod failure for externally compiled module :-



Experiments:

(1) Compiling 2 modules a.ko and b.ko ( dependent on a.ko ) together :- Works



(2) Copying Module.symvers from module "a" dir to the module "b" dir, before

compiling b.ko :- Works.



(3) Modprobe after appending following lines in /lib/modules/modules.dep 

    /lib/modules/2.6.27.7-smp/kernel/drivers/net/a.ko

    /lib/modules/2.6.27.7-smp/kernel/drivers/net/b.ko:

/lib/modules/2.6.27.7-smp/kernel/drivers/net/a.ko

   :- Fails



(4) After compiling b.ko, just modifying b.mod.c file to include the undefined

symbol in its version table doesn''t work (didn''t expect to work ).



(5) export_objs (doesn''t work):

    In Makefile of a.ko:

       export_objs := a.ko / export-objs := a.ko / exportobjs := a.ko.



(6) Adding "#define EXPORT_SYMTAB" in a.c file (doesn''t work).



From above experiments, we found that In .mod.c file it maintains __versions

array, which contains export symbol name and its crc.

We see symbols of modules which are compiled with kernel. No symbols of

externally compiled modules.



The call trace is load_module -> simplify_symbols -> resolve_symbol -> 

find_symbol and check_version ( if find_symbol succeeds ).



check_version behavior comparison in 2.6.26 and earlier version kernels :-



In earlier versions of kernel also, symbol couldn''t be found in its version

table. Still, check_version used to 

return 1 (success) and the dependent module could be insmod(ed) successfully.



However, in kernel 2.6.26 onwards, behavior has changed.  check_version on not

finding the reqd. symbol in its version table returns 0 (fail) and  the

dependent external module can''t be inserted anymore.



Waiting eagerly for your reply. Thanks in advance.

Any updates ?

No but this is not a support facility, just a bug tracker and as a problem only

you''ve reported and nobody else has duplicated its a very very low priority,

especially as its only out of tree code seeing it

It should not be very very low priotity, Its easy to reproduce. 

Its should be blocker bug, because anybody how will try to compile module

dependent on other module, will fail.



Strange, Why didn''t nobody reply on it.

I am really stuck, because of this problem.

cc''ing Rusty Russell.

hello amit, 

i think alan is right. this seems a very specific, personal problem. 



anyway, if you think it`s a general kernel problem, please post an as simple as

possible repro-case (i.e. some sourcecode) for your problem, so chances will

raise that someone will look at your problem. 



i`d recommend bringing this up on kernel related mailing lists

A typo, it should be

""modprobe --force-modversion" does NOT work for me, it will report "invalid

module

format""

You can''t modprobe --force if  CONFIG_MODULE_FORCE_LOAD isn''t set.  That was

added in 2.6.26, and is off by default.



Hope that clarifies,

Rusty.

You need to log in before you can comment on or make changes to this bug.