Uknown symbols in rfkill_backport.ko on 2.6.25.17 on mips

Uknown symbols in rfkill_backport.ko on 2.6.25.17 on mips

[Mijzelf]

I'm trying to get ath9k from compat-wireless-2012-05-08 running on a 
2.6.25.17 kernel on mips. The module refuses to load, due to unkown 
symbols.
# modprobe ath9k
modprobe: can't load module rfkill_backport 
(updates/net/rfkill/rfkill_backport.ko): unknown symbol in module, or 
unknown parameter
# dmesg
rfkill_backport: Unknown symbol input_register_handle
rfkill_backport: Unknown symbol input_open_device
rfkill_backport: Unknown symbol input_close_device
rfkill_backport: Unknown symbol input_unregister_handler
rfkill_backport: Unknown symbol input_register_handler
rfkill_backport: Unknown symbol input_unregister_handle

Any suggestions?

Re: Uknown symbols in rfkill_backport.ko on 2.6.25.17 on mips

[Pavel Roskin]

On Sun, 22 Jul 2012 21:11:34 +0200
Mijzelf <Mijzelf@Live.com> wrote:

> I'm trying to get ath9k from compat-wireless-2012-05-08 running on a 
> 2.6.25.17 kernel on mips. The module refuses to load, due to unkown 
> symbols.
> # modprobe ath9k
> modprobe: can't load module rfkill_backport 
> (updates/net/rfkill/rfkill_backport.ko): unknown symbol in module, or 
> unknown parameter
> # dmesg
> rfkill_backport: Unknown symbol input_register_handle
> rfkill_backport: Unknown symbol input_open_device
> rfkill_backport: Unknown symbol input_close_device
> rfkill_backport: Unknown symbol input_unregister_handler
> rfkill_backport: Unknown symbol input_register_handler
> rfkill_backport: Unknown symbol input_unregister_handle
> 
> Any suggestions?

If you can recompile the kernel, enable CONFIG_INPUT in .config

-- 
Regards,
Pavel Roskin

Re: Uknown symbols in rfkill_backport.ko on 2.6.25.17 on mips

[Mijzelf]

Pavel Roskin <proski@...> writes:

> 
> On Sun, 22 Jul 2012 21:11:34 +0200
> Mijzelf <Mijzelf@...> wrote:
> 
> > I'm trying to get ath9k from compat-wireless-2012-05-08 running on a 
> > 2.6.25.17 kernel on mips. The module refuses to load, due to unkown 
> > symbols.
> > # modprobe ath9k
> > modprobe: can't load module rfkill_backport 
> > (updates/net/rfkill/rfkill_backport.ko): unknown symbol in module, or 
> > unknown parameter
> > # dmesg
> > rfkill_backport: Unknown symbol input_register_handle
> > rfkill_backport: Unknown symbol input_open_device
> > rfkill_backport: Unknown symbol input_close_device
> > rfkill_backport: Unknown symbol input_unregister_handler
> > rfkill_backport: Unknown symbol input_register_handler
> > rfkill_backport: Unknown symbol input_unregister_handle
> > 
> > Any suggestions?
> 
> If you can recompile the kernel, enable CONFIG_INPUT in .config
> 

Thanks. I was able to compile the input module, and this issue is solved.

Now a new one pops up:
/tmpfs/root # modprobe ath9k
modprobe: can't load module mac80211 (updates/net/mac80211/mac80211.ko): 
unknown symbol in module, or unknown parameter
/tmpfs/root # dmesg 
mac80211: Unknown symbol _flush_cache

I grepped the source tree, and the word 'flush_cache' only exists in the 
objects of mac80211.ko. So I suppose it's some macro expansion. But I also 
grepped all include files in my kernel tree, and flush_cache only appeared 4 
times:

./drivers/scsi/ips.h:   IPS_FC_CMD         flush_cache;
./drivers/video/i810/i810_main.h:static inline void flush_cache(void)
./drivers/video/i810/i810_main.h:#define flush_cache() do { } while(0)
./arch/powerpc/boot/ops.h:extern void flush_cache(void *, unsigned long);

It seems to me no one of these can cause a symbol _flush_cache in a module. 

Because the symbol is in the object files, I suppose it cannot added by some 
library either. (Are there any libraries linked against kernel modules?)

Where does this come from? 

Re: Uknown symbols in rfkill_backport.ko on 2.6.25.17 on mips

[Pavel Roskin]

On Wed, 25 Jul 2012 18:10:38 +0000 (UTC)
Mijzelf <Mijzelf@live.com> wrote:

> Thanks. I was able to compile the input module, and this issue is
> solved.
> 
> Now a new one pops up:
> /tmpfs/root # modprobe ath9k
> modprobe: can't load module mac80211
> (updates/net/mac80211/mac80211.ko): unknown symbol in module, or
> unknown parameter /tmpfs/root # dmesg 
> mac80211: Unknown symbol _flush_cache
> 
> I grepped the source tree, and the word 'flush_cache' only exists in
> the objects of mac80211.ko. So I suppose it's some macro expansion.
> But I also grepped all include files in my kernel tree, and
> flush_cache only appeared 4 times:
> 
> ./drivers/scsi/ips.h:   IPS_FC_CMD         flush_cache;
> ./drivers/video/i810/i810_main.h:static inline void flush_cache(void)
> ./drivers/video/i810/i810_main.h:#define flush_cache() do { } while(0)
> ./arch/powerpc/boot/ops.h:extern void flush_cache(void *, unsigned
> long);
> 
> It seems to me no one of these can cause a symbol _flush_cache in a
> module. 

I agree.

> Because the symbol is in the object files, I suppose it cannot added
> by some library either. (Are there any libraries linked against
> kernel modules?)

No.  Everything used by the modules should be provided by symbols
exported by the kernel.

> Where does this come from? 

My guess is that either it's a result of some clever macro expansion
(so that the source doesn't have "flush_cache") or gcc inserts that call
(perhaps hoping that libgcc has it) but the kernel doesn't satisfy it.

First of all, make sure that you are making a clean build and there are
no object files left from older builds.

Then find the object file that calls _flush_cache.  Recompile the
corresponding source file with "-save-temps".  Look for "flush_cache"
in the *.i and the *.s file.  Try to find out where it comes from.

-- 
Regards,
Pavel Roskin

Re: Uknown symbols in rfkill_backport.ko on 2.6.25.17 on mips

[Mijzelf]

Pavel Roskin <proski@...> writes:
> 
> My guess is that either it's a result of some clever macro expansion
> (so that the source doesn't have "flush_cache") or gcc inserts that call
> (perhaps hoping that libgcc has it) but the kernel doesn't satisfy it.
> 
> First of all, make sure that you are making a clean build and there are
> no object files left from older builds.
> 
> Then find the object file that calls _flush_cache.  Recompile the
> corresponding source file with "-save-temps".  Look for "flush_cache"
> in the *.i and the *.s file.  Try to find out where it comes from.
> 
There are several objects which call _flush_cache, mesh_pathtbl, mac80211, agg-
tx, work and cfg. Looking at the .i and .s files I found that by far the least 
complex function was free_work() in work.c:

void free_work(struct ieee80211_work *wk)
{
        kfree_rcu(wk, rcu_head);
}

work.i:

void free_work(struct ieee80211_work *wk)
{
 do { void __kfree_rcu_fn(struct rcu_head *rcu_head) { void *___ptr; ___ptr = 
({ const typeof( ((typeof(*(wk)) *)0)->rcu_head
 ) *__mptr = (rcu_head); (typeof(*(wk)) *)( (char *)__mptr - ((size_t) &((typeof
(*(wk)) *)0)->rcu_head) );}); kfree(___ptr);
} call_rcu(&(wk)->rcu_head, __kfree_rcu_fn); } while (0);
}

work.s:

$LTRAMP0:
        .word   0x03e00821              # move   $1,$31
        .word   0x04110001              # bgezal $0,.+8
        .word   0x00000000              # nop
        .word   0x8fe30014              # lw     $3,20($31)
        .word   0x8fe20018              # lw     $2,24($31)
        .word   0x0060c821              # move   $25,$3 (abicalls)
        .word   0x00600008              # jr     $3
        .word   0x0020f821              # move   $31,$1
        .word   0x00000000              # <function address>
        .word   0x00000000              # <static chain value>
        .globl  _flush_cache
        .text
        .align  2
        .globl  free_work
        .ent    free_work
        .type   free_work, @function
free_work:
        .frame  $sp,80,$31              # vars= 48, regs= 3/0, args= 16, gp= 0
        .mask   0x80030000,-8
        .fmask  0x00000000,0
        .set    noreorder
        .set    nomacro
        
        addiu   $sp,$sp,-80
        sw      $16,64($sp)
        lui     $5,%hi($LTRAMP0)
        addiu   $16,$sp,16
        lui     $2,%hi(memcpy)
        sw      $31,72($sp)
        sw      $17,68($sp)
        addiu   $5,$5,%lo($LTRAMP0)
        move    $17,$4
        li      $6,40                   # 0x28
        addiu   $2,$2,%lo(memcpy)
        jal     $2
        move    $4,$16

        lui     $2,%hi(__kfree_rcu_fn.0)
        addiu   $2,$2,%lo(__kfree_rcu_fn.0)
        addiu   $3,$sp,16
        sw      $2,32($16)
        lui     $2,%hi(_flush_cache)
        move    $4,$16
        sw      $3,36($16)
        li      $5,40                   # 0x28
        addiu   $2,$2,%lo(_flush_cache)
        jal     $2
<snip>

Looking at this it seems to me it must be some compiler-inserted memory 
barrier, or something like that. But that memcpy baffles me.

I think I'll just add a dummy _flush_cache. My target system is single core, I 
suppose it would be safe.

Re: Uknown symbols in rfkill_backport.ko on 2.6.25.17 on mips

[Pavel Roskin]

On Sun, 29 Jul 2012 12:31:16 +0000 (UTC)
Mijzelf <Mijzelf@live.com> wrote:

> Looking at this it seems to me it must be some compiler-inserted
> memory barrier, or something like that. But that memcpy baffles me.

You did a great job tracking down the problem.  I think the next step
would be to ask in the mips mailing list.  The wireless subsystem has
nothing to do with that problem.

> I think I'll just add a dummy _flush_cache. My target system is
> single core, I suppose it would be safe.

I think it's worth trying.

-- 
Regards,
Pavel Roskin