On 2011-04-14 16:09, Philippe Gerum wrote:
> On Thu, 2011-04-14 at 15:46 +0200, Jesper Christensen wrote:
>   
>> Actually i have been running with CONFIG_XENO_HW_UNLOCKED_SWITCH the
>> whole time
>>     
> You mean enabled?
>   
Disabled, sorry.
>   
>>  and i also raised the stack size from 4k to 8k. I do however
>> think there could be some fishyness in entry_32.S. In
>> "transfer_to_handler" SPRN_SPRG3 is used to check for stack overflow (at
>> least in my kernel 2.6.29.6), but i must admit i haven't seen any of
>> that in the kernel log.
>>
>>     
> Mmm, you are right. In any case, what we want with the unmasked switch
> feature is to allow interrupts while we flush the tlb and set the new mm
> context, which may be lengthy on some low end platforms. Allowing the
> switch code to be preempted during the register swap is of no use wrt
> latency.
>
> Do you have a patch at hand which you could post that flips MSR_EE in
> rthal_thread_switch already?
>
>   
This protects the whole function, but it should flip the bit inside like
you suggest.

diff --git a/include/asm-powerpc/bits/pod.h b/include/asm-powerpc/bits/pod.h
old mode 100644
new mode 100755
index 6269907..e279647
--- a/include/asm-powerpc/bits/pod.h
+++ b/include/asm-powerpc/bits/pod.h
@@ -106,6 +106,7 @@ static inline void xnarch_switch_to(xnarchtcb_t
*out_tcb,
        struct mm_struct *prev_mm = out_tcb->active_mm, *next_mm;
        struct task_struct *prev = out_tcb->active_task;
        struct task_struct *next = in_tcb->user_task;
+       unsigned long flags;
 
        if (likely(next != NULL)) {
                in_tcb->active_task = next;
@@ -156,12 +157,14 @@ static inline void xnarch_switch_to(xnarchtcb_t
*out_tcb,
 #endif /* PPC32 */
 #endif /* !__IPIPE_FEATURE_HARDENED_SWITCHMM */
 
+    rthal_local_irq_save_hw(flags);
 #ifdef CONFIG_PPC64
        rthal_thread_switch(out_tcb->tsp, in_tcb->tsp, next == NULL);
 #else
        rthal_thread_switch(out_tcb->tsp, in_tcb->tsp);
 #endif
        barrier();
+       rthal_local_irq_restore_hw(flags);
 }

>> /Jesper
>>
>>
>> On 2011-04-14 15:31, Philippe Gerum wrote:
>>     
>>> On Thu, 2011-04-14 at 15:04 +0200, Jesper Christensen wrote:
>>>   
>>>       
>>>> I wrote about some problems concerning stack corruption when running
>>>> xenomai on ppc. I have found out that if i disable hardware interrupts
>>>> while running "rthal_thread_switch" the problem seems to dissapear
>>>> somewhat. I saw a crash yesterday after running for 3 hours, and i'm
>>>> currently running a test (has been running for 3 hours). Usually it
>>>> would fail after 30-40 minutes. My question is: could there be a problem
>>>> if we receive an interrupt between updating the stack pointer and the
>>>> sprg3 register with the new thread pointer?
>>>>
>>>>     
>>>>         
>>> Normally, there should not be any issue (famous last words), since we
>>> would run Xenomai-only code over the preempted context, and we don't
>>> depend on SPRG3 to fetch the current phys address. In fact, at this
>>> stage we simply don't care about the linux context, only referring to
>>> the current Xenomai thread, which is obtained differently.
>>>
>>> Try switching off CONFIG_XENO_HW_UNLOCKED_SWITCH, in the "machine"
>>> config area, if this ends up being rock-solid, then this would be a hint
>>> that something may be fishy in this area. Raising your k-thread stack
>>> sizes in a separate test may be interesting to check too, if not already
>>> done.
>>>
>>>
>>>   
>>>       
>>>> /Jesper
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Xenomai-core mailing list
>>>> Xenomai-core@gna.org
>>>> https://mail.gna.org/listinfo/xenomai-core
>>>>     
>>>>         
>>>   
>>>       
>>     
>   


_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to