Re: [Xenomai-core] [PowerPC] Registers Corruption at Context Switch
Benjamin ZORES wrote: > Hi, > > I'm facing a problem with the PowerPC version of Xenomai/Adeos that I > have difficulties > to identify the exact source. > > I'm running a Xenomai RT kernel thread that use to crash sometimes due > to potential register corruption. > Problem occurs after a context switch and, in some cases, if the task > gets interrupted and reschedule, > its registers values are not the same as they used to be before context > switch. > > The code is a bit complex and so, makes use of register that is > generally rarely used (GPR r26 to be accurate). > Driver is compiled with -02 and compiling with -O0 (so disabling > optimizations and so, not using r26) works fine > but is not what I'm looking for. > > Can someone tell me where exactly in Adeos/Xenomai is context switching > actually performed and where are the registers save/restore functions ? > I've seen there is specific code for FPU registers handling but can't > find the equivalent for GPR. > > FYI, I'm running on PowerPC 603e core with Linux 2.6.23, Adeos 2.0-09 > (latest) and Xenomai 2.3.4 (latest). > I've seen there are adeos updates (but for updated kernels) but is there > some ChangeLog of Adeos changes ? > Maybe this is a known bug that has been fixed in updated Adeos release ? > > Thx to anyone who can help me on this, > 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. > Ben > > > ___ > Xenomai-core mailing list > Xenomai-core@gna.org > https://mail.gna.org/listinfo/xenomai-core > -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PowerPC] Registers Corruption at Context Switch
Benjamin ZORES wrote: > Philippe Gerum a écrit : >> 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. >> > Thx for the info. > Can you tell me why GPR registers would be saved there and FPU ones in > another function ? > Because FPU management with Xenomai involves additional handling, e.g. FPU state fixup during primary/secondary mode switch, Linux to Xenomai real-time transitions. That support has to be provided independently from the pure task switching code. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PowerPC] Registers Corruption at Context Switch
Benjamin ZORES wrote: > 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 */ > >lwzr1,KSP(r4)/* Load new stack pointer */ > >mrr3,r2 >lwzr0,PGDIR(r4) >cmpwi r0, 0 >beq-same_current > >tophys(r0,r4) >CLR_TOP32(r0) >mtsprSPRN_SPRG3,r0/* Update current THREAD phys addr */ >addir2,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) >mtsprSPRN_SPRG3,r0/* Update current THREAD phys addr */ >lwzr1,KSP(r4)/* Load new stack pointer */ > >/* save the old current 'last' for return value */ >mrr3,r2 >addir2,r4,-THREAD/* Update current */ > > > As we can see, the code differs from kernel, as > >tophys(r0,r4) >CLR_TOP32(r0) >mtsprSPRN_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 ?? > It's just code placement to avoid additional branches depending on whether we want to update SPRG3 upon switch or not (when switching to a Xenomai kernel thread, we don't). I see no dependency from that code on the stack pointer and conversely. Do you see any? -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PowerPC] Registers Corruption at Context Switch
Philippe Gerum a écrit : > 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. > Thx for the info. Can you tell me why GPR registers would be saved there and FPU ones in another function ? Ben ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PowerPC] Registers Corruption at Context Switch
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 */ lwzr1,KSP(r4)/* Load new stack pointer */ mrr3,r2 lwzr0,PGDIR(r4) cmpwi r0, 0 beq-same_current tophys(r0,r4) CLR_TOP32(r0) mtsprSPRN_SPRG3,r0/* Update current THREAD phys addr */ addir2,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) mtsprSPRN_SPRG3,r0/* Update current THREAD phys addr */ lwzr1,KSP(r4)/* Load new stack pointer */ /* save the old current 'last' for return value */ mrr3,r2 addir2,r4,-THREAD/* Update current */ As we can see, the code differs from kernel, as tophys(r0,r4) CLR_TOP32(r0) mtsprSPRN_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
