Philippe Gerum a écrit :
>> FYI, I'm running on PowerPC 603e core with Linux 2.6.23, Adeos 2.0-09
>> (latest) and Xenomai 2.3.4 (latest).
>>
read Xenomai 2.4.4 here, of course ...
>
> See arch/powerpc/switch_32.S, rthal_switch_threads(), for the part that does
> the
> actual stack switching.
>
> Note that this code is obfuscated by the fact that we have to handle so-called
> "hybrid" switching, between Xenomai kernel threads (which do not rely on a
> task_struct), and Linux tasks (Xenomai userland, Linux kthreads, or regular
> userland Linux). Fortunately, what is saved on the stack in any case is easy
> to
> find out.
>
Ok, I've dig a bit more at sources and found out something strange.
In xenomai arch/powerpc/xenomai/switch_32.S in rthal_thread_switch() we
have:
********
#ifdef CONFIG_SMP
sync
#endif /* CONFIG_SMP */
lwz r1,KSP(r4) /* Load new stack pointer */
mr r3,r2
lwz r0,PGDIR(r4)
cmpwi r0, 0
beq- same_current
tophys(r0,r4)
CLR_TOP32(r0)
mtspr SPRN_SPRG3,r0 /* Update current THREAD phys addr */
addi r2,r4,-THREAD /* Update current */
same_current:
**********
While, in arch/powerpc/kernel/entry_32.S in _switch() we have:
**********
#ifdef CONFIG_SMP
/* We need a sync somewhere here to make sure that if the
* previous task gets rescheduled on another CPU, it sees all
* stores it has performed on this one.
*/
sync
#endif /* CONFIG_SMP */
tophys(r0,r4)
CLR_TOP32(r0)
mtspr SPRN_SPRG3,r0 /* Update current THREAD phys addr */
lwz r1,KSP(r4) /* Load new stack pointer */
/* save the old current 'last' for return value */
mr r3,r2
addi r2,r4,-THREAD /* Update current */
************
As we can see, the code differs from kernel, as
tophys(r0,r4)
CLR_TOP32(r0)
mtspr SPRN_SPRG3,r0 /* Update current THREAD phys addr */
is done _before_ loading new stack pointer in kernel and _after_ doing
so in xenomai.
Is there a good reason for that or is this unintended ??
Ben
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
