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
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
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
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: 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] Compile-time bug, and problem with PPC440 ethernet
Steven A. Falco wrote:
Philippe Gerum wrote:
Steven A. Falco wrote:
I am using the patch that came with Xenomai 2.4.4, namely:
adeos-ipipe-2.6.25-powerpc-DENX-2.2-02.patch
I can't reproduce this issue on a 440EP board, but I still have to to put
my
hands on a 440EPX to check this. However, both should be using the common
44x
PIC support, so I don't expect big changes here.
Are you using the powerpc/ branch, or legacy ppc/ one for building the
sequoia
kernel?
ARCH=powerpc.
Ah. So it's the UIC support that likely breaks. Could you try this patch?
diff --git a/arch/powerpc/sysdev/uic.c b/arch/powerpc/sysdev/uic.c
index dd40f64..4eff1ab 100644
--- a/arch/powerpc/sysdev/uic.c
+++ b/arch/powerpc/sysdev/uic.c
@@ -111,7 +111,6 @@ static void uic_mask_ack_irq(unsigned int virq)
sr = 1 (31-src);
spin_lock_irqsave(uic-lock, flags);
-ipipe_irq_lock(virq);
er = mfdcr(uic-dcrbase + UIC_ER);
er = ~sr;
mtdcr(uic-dcrbase + UIC_ER, er);
In case it is not enough, try removing all the ipipe_irq_lock/unlock calls
from
arch/powerpc/sysdev/uic.c. If that works eventually, I'll sort the mess out
later.
Beautiful. The patch works! I now get DHCP replies.
Is this the patch you will put into the official tree, or do you still
need to do more?
One thing, could you confirm that your network card relies on edge interrupts
(and not level)?
Aside of that, it should be ok. It's the same IRQ lock out issue fixed in the
ppc/ branch recently.
Also, please include my compile-time patch, if that is acceptible.
I recently committed a different fix for the same issue after you reported it.
This should work without requiring additional #ifdef'ing as well. Thanks for the
heads up.
--- a/include/asm-powerpc/ipipe.h
+++ b/include/asm-powerpc/ipipe.h
@@ -62,8 +62,6 @@
local_irq_enable_hw(); x; \
} )
-#define ipipe_update_tick_evtdev(evtdev) do { } while (0)
-
struct ipipe_domain;
struct ipipe_sysinfo {
@@ -209,4 +207,6 @@ do {
\
#endif /* CONFIG_IPIPE */
+#define ipipe_update_tick_evtdev(evtdev) do { } while (0)
+
#endif /* !__ASM_POWERPC_IPIPE_H */
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Compile-time bug, and problem with PPC440 ethernet
Steven A. Falco wrote: Philippe Gerum wrote: Steven A. Falco wrote: I am building kernel 2.6.25.4 from DENX with Xenomai 2.4.4 for PPC440EPx (sequoia development board). The kernel tries to use DHCP to obtain network settings. With IPIPE disabled, this works perfectly. However, when I enable IPIPE, the board sends packets ok, but does not receive packets - I can see the DHCP with a sniffer, but the development board does not receive them. External interrupts are probably locked out by the pipeline engine; I've fixed a similar issue in recent patches for other PICs. Which I-pipe patch release are you using? I am using the patch that came with Xenomai 2.4.4, namely: adeos-ipipe-2.6.25-powerpc-DENX-2.2-02.patch I can't reproduce this issue on a 440EP board, but I still have to to put my hands on a 440EPX to check this. However, both should be using the common 44x PIC support, so I don't expect big changes here. Are you using the powerpc/ branch, or legacy ppc/ one for building the sequoia kernel? -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
