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.
On Sun, 29 Jul 2012 12:31:16 +0000 (UTC)
Mijzelf <[email protected]> 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