Re: [Xenomai-core] Bug in taskSuspend for user mode vxworks

[Philippe Gerum <rpm@xenomai.org>]

On Sat, 2006-10-28 at 19:40 +0200, Niklaus Giger wrote:
> > I recompiled the kernel with CONFIG_XENO_OPT_DEBUG disabled and the error
> > went away.
> Actually I think the problem did not go away, as I did see that 
> in /proc/xenomai/faults the following error is incremented when I call the 
> attache simple program.
> TRAP         CPU0
>   0:            5    (Data or instruction access)
> (Btw which exception is it attached on a PPC405 system?)
> 

0x400, e.g. page fault.

> Here is the stack trace of the simplified example attached as seen by the BDI 
> with a hardware breakpoint at 0x300
> #0  0x00000300 in ?? ()
> No symbol table info available.
> #1  0x100b8c48 in ?? ()
> No symbol table info available.
> #2  0x100b8c48 in ?? ()
> No symbol table info available.
> Previous frame inner to this frame (corrupt stack?)
> (gdb)                                     
> 
> Setting a breakpoint at xnpod_fault_handler and a full backtrace gives me 
> (gdb) bt full
> #0  xnpod_fault_handler (fltinfo=0xc1839e18) 
> at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/include/asm-generic/xenomai/system.h:200
>         thread = (xnthread_t *) 0xc0214f40
> #1  0xc0048e90 in xnpod_trap_fault (fltinfo=0xc1839e18) 
> at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/kernel/xenomai/nucleus/pod.c:2907
> No locals.
> #2  0xc00438f4 in xnarch_trap_fault (event=3246628376, domid=1480937039, 
> data=0xc1839f50) at include2/asm/xenomai/bits/init.h:46
>         fltinfo = {exception = 0, regs = 0xc1839f50}
> #3  0xc011ffb8 in exception_event (event=3221520296, ipd=0x58454e4f, 
> data=0xc1839f50)
>     at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/arch/ppc/xenomai/hal.c:385
> No locals.
> #4  0xc003fecc in __ipipe_dispatch_event (event=0, data=0xc1839f50) 
> at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/kernel/ipipe/core.c:668
>         start_domain = (struct ipipe_domain *) 0xc0214f40
>         this_domain = (struct ipipe_domain *) 0xc0214f40
>         evhand = (ipipe_event_handler_t) 0xc0048e90 <xnpod_trap_fault+100>
>         pos = (struct list_head *) 0xc0214f40
>         npos = (struct list_head *) 0xc01c6540
>         flags = 167984
>         propagate = 1
> #5  0xc000b02c in do_page_fault (regs=0xc1839f50, address=266719224, 
> error_code=0)
>     at /mnt/data.ng/hcu/kernel/ppc/linux-2.6.14/arch/ppc/mm/fault.c:119
>         vma = (struct vm_area_struct *) 0xff86120
>         mm = (struct mm_struct *) 0xc0200260
>         info = {si_signo = 1, si_errno = -1071644672, si_code = -1071579136, 
> _sifields = {_pad = {0, -1048338784, -1048338608,
>       -1071554848, -1070595192, -1048338768, -1073423884, -1048338608, -1070595192, -1048338752, -1073422700, 
> 0, 1, -1048338704,
>       -1073418440, -1071710208, 14, 1, -1071733764, -1071710208, -1071880896, 
> 167984, 0, 16384, -1071880896, -1048338640, -1073479988,
>       0, 0}, _kill = {_pid = 0, _uid = 3246628512}, _timer = {_tid = 0, 
> _overrun = -1048338784,
>       _pad = 
> 0xc1839e94 "Á\203\237PÀ!^àÀ0\003\210Á\203\236°À\004ÙôÁ\203\237PÀ0\003\210Á\203\236ÀÀ\004Þ\224", 
> _sigval = {
>         sival_int = -1048338608, sival_ptr = 0xc1839f50}, _sys_private 
> = -1071554848}, _rt = {_pid = 0, _uid = 3246628512, _sigval = {
>         sival_int = -1048338608, sival_ptr = 0xc1839f50}}, _sigchld = {_pid = 
> 0, _uid = 3246628512, _status = -1048338608,
>       _utime = -1071554848, _stime = -1070595192}, _sigfault = {_addr = 0x0}, 
> _sigpoll = {_band = 0, _fd = -1048338784}}}
>         code = 196609
>         is_write = 0
>         __func__ = "do_page_fault"
> #6  0xc0003258 in handle_page_fault ()
> No locals.
> (gdb)   
> 
> But I think it has something to do with my toolchain/compiler or my root file 
> system setup. I just found out, that compiling it with the same gcc 3.4 
> compiler for my PowerBook and linking it statically the error got away.
> 

I tried to reproduce the issue on a lite5200 here, to no avail. I'm
using gcc 4.0 from Denx's ELDK 4.0, but I've never had such problem when
using gcc 3.3.3 from ELDK 3.1 either.

I wonder if something fishy is not happening with the code gcc generates
to emit syscalls in some place of the library support.

> I think I really have to reactivate my old Walnut board to have common 
> platform to test with Wolfgang Grandegger.
>              
> Best regards
>            
-- 
Philippe.