On Mon, 2011-04-11 at 16:32 +0200, Jesper Christensen wrote:
> How do i see that?
> 

diff --git a/include/asm-powerpc/system.h b/include/asm-powerpc/system.h
index 5cc4a23..8dbc537 100644
--- a/include/asm-powerpc/system.h
+++ b/include/asm-powerpc/system.h
@@ -104,7 +104,7 @@ typedef struct xnarch_fltinfo {
 #define xnarch_fault_trap(fi)   ((unsigned int)(fi)->regs->trap)
 #define xnarch_fault_code(fi)   ((fi)->regs->dar)
 #define xnarch_fault_pc(fi)     ((fi)->regs->nip)
-#define xnarch_fault_pc(fi)     ((fi)->regs->nip)
+#define xnarch_fault_lr(fi)     ((fi)->regs->link)
 /* FIXME: FPU faults ignored by the nanokernel on PPC. */
 #define xnarch_fault_fpu_p(fi)  (0)
 /* The following predicates are only usable over a regular Linux stack
diff --git a/ksrc/nucleus/pod.c b/ksrc/nucleus/pod.c
index b5ddbaa..c1722e7 100644
--- a/ksrc/nucleus/pod.c
+++ b/ksrc/nucleus/pod.c
@@ -2591,8 +2591,8 @@ int xnpod_trap_fault(xnarch_fltinfo_t *fltinfo)
 
        if (!xnpod_userspace_p()) {
                xnprintf
-                   ("suspending kernel thread %p ('%s') at 0x%lx after 
exception #%u\n",
-                    thread, thread->name, xnarch_fault_pc(fltinfo),
+                   ("suspending kernel thread %p ('%s') at nip=0x%lx, lr=0x%lx 
after exception #%u\n",
+                    thread, thread->name, xnarch_fault_pc(fltinfo), 
xnarch_fault_lr(fltinfo),
                     xnarch_fault_trap(fltinfo));
 
                xnpod_suspend_thread(thread, XNSUSP, XN_INFINITE, XN_RELATIVE, 
NULL);
> /Jesper
> 
> 
> On 2011-04-11 16:27, Philippe Gerum wrote:
> > On Mon, 2011-04-11 at 16:20 +0200, Jesper Christensen wrote:
> >   
> >> Problem is the NIP in question is the address of the thread structure as
> >> seen in the error message.
> >>     
> > LR?
> >
> >   
> >> /Jesper
> >>
> >>
> >> On 2011-04-11 16:18, Philippe Gerum wrote:
> >>     
> >>> On Mon, 2011-04-11 at 16:13 +0200, Jesper Christensen wrote:
> >>>   
> >>>       
> >>>> I have updated to xenomai 2.5.6, but i'm still seeing exceptions
> >>>> (considerably less often though):
> >>>>
> >>>> Xenomai: suspending kernel thread b92a39d0 ('tt_upgw_0') at 0xb92a39d0
> >>>> after exception #1792
> >>>>     
> >>>>         
> >>> You should build your code statically into the kernel, not as a module,
> >>> and find out which code raises the MCE.
> >>>
> >>> CONFIG_DEBUG_INFO=y, then objdump -dl vmlinux, looking for the NIP
> >>> mentioned.
> >>>
> >>>   
> >>>       
> >>>> /Jesper
> >>>>
> >>>>
> >>>> On 2011-04-08 15:12, Philippe Gerum wrote:
> >>>>     
> >>>>         
> >>>>> On Fri, 2011-04-08 at 14:58 +0200, Jesper Christensen wrote:
> >>>>>   
> >>>>>       
> >>>>>           
> >>>>>> Hi
> >>>>>>
> >>>>>> I'm trying to implement some gateway functionality in the kernel on a
> >>>>>> emerson CPCI6200 board, but have run into some strange errors. The
> >>>>>> kernel module is made up of two threads that run every 1 ms. I have 
> >>>>>> also
> >>>>>> made use of the rtpc dispatcher in rtnet to dispatch control messages
> >>>>>> from a netlink socket to the RT part of my kernel module.
> >>>>>>
> >>>>>> The problem is that when loaded the threads get suspended due to 
> >>>>>> exceptions:
> >>>>>>
> >>>>>> Xenomai: suspending kernel thread b929cbc0 ('tt_upgw_0') at 0xb929cbc0
> >>>>>> after exception #1792
> >>>>>>
> >>>>>> or
> >>>>>>
> >>>>>> Xenomai: suspending kernel thread b929cbc0 ('tt_upgw_0') at 0x0 after
> >>>>>> exception #1025
> >>>>>>
> >>>>>> or
> >>>>>>
> >>>>>> Xenomai: suspending kernel thread b911f518 ('rtnet-rtpc') at 0xb911f940
> >>>>>> after exception #1792
> >>>>>>
> >>>>>>
> >>>>>> I have ported the "gianfar" driver from linux to rtnet.
> >>>>>>
> >>>>>> The versions and hardware are listed below. The errors are most likely
> >>>>>> due to faulty software on my part, but i would like to ask if there are
> >>>>>> any known issues with the versions or hardware i'm using. I would also
> >>>>>> like to ask if there are any ways of further debugging the errors as i
> >>>>>> am not getting very far with the above messages.
> >>>>>>     
> >>>>>>         
> >>>>>>             
> >>>>> A severe bug at kthread init was fixed in the 2.5.5.2 - 2.5.6 timeframe,
> >>>>> which would cause exactly the kind of weird behavior you are seeing
> >>>>> right now. The bug triggered random code execution due to stack memory
> >>>>> pollution at init on powerpc for Xenomai kthreads:
> >>>>> http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=90699565cbce41f2cec193d57857bb5817efc19a
> >>>>> http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=da20c20d4b4d892d40c657ad1d32ddb6d0ceb47c
> >>>>> http://git.xenomai.org/?p=xenomai-rpm.git;a=commit;h=a5886b354dc18f054b187b58cfbacfb60bccaf47
> >>>>>
> >>>>> You need at the very least those three patches (from the top of my
> >>>>> head), but it would be much better to upgrade to 2.5.6.
> >>>>>
> >>>>>   
> >>>>>       
> >>>>>           
> >>>>>> System info:
> >>>>>>
> >>>>>> Linux kernel: 2.6.29.6
> >>>>>> i-pipe version: 2.7-04
> >>>>>> processor: powerpc mpc8572
> >>>>>> xenomai version: 2.5.3
> >>>>>> rtnet version: 0.9.12
> >>>>>>
> >>>>>>     
> >>>>>>         
> >>>>>>             
> >>>>>   
> >>>>>       
> >>>>>           
> >>>> _______________________________________________
> >>>> 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

Reply via email to