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

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

[Niklaus Giger]

[-- Attachment #1: Type: text/plain, Size: 1544 bytes --]

Hi

While trying to make a small demo app for Xenomai's registry I stumbled about 
the following bug of the vxWorks skin.

taskSuspend provokes (sometimes) a switch to the secondary mode, e.g. the 
output of the attached demo gives:
>  reg_demo &
> ~ $ Xenomai: Switching ConsumerTask to secondary mode after exception #1025
> from user-space at 0xfe5cff8 (pid 27) consumer_task: 13129 Started
> producer_task: 13258 Started  xx
> lockForward: 13259 Started
> producer_task: 13260 msg sent 0
> lockForward: 13260 got both mutexes
> lockBackward: 13260 Started
> producer_task: 13261 msg sent 0
> producer_task: 13261 done
> Now playing first msg...
> consumer_task: 13262 Suspending myself. After receiving sz 16
>
> This is a small demo for the debugging option CONFIG_XENO_EXPORT_REGISTRY.
> If you compile the xenomai kernel with CONFIG_XENO_EXPORT_REGISTRY=y
> in your kernel .config you will find files under /proc/xenomai/registry.
> tasks/*:      gives information about running vxworks tasks
> semaphores/*: gives information about the vxworks semaphores
> msgqs/*:      gives information about the vxworks message queues
>
> Some vxWorks tasks should be blocked. Now enter:
> ls -R /proc/xenomai/registry/vxworks/* && cat
> /proc/xenomai/registry/vxworks/*/* lockForward: 13271 will give both
> mutexes
> lockForward: 13271 Done

Running the same program under the simulator gave me the expected output

I had not yet time to track down the error, but any help would be appreciated.

Thanks in advance

Best regards

-- 
Niklaus Giger

[-- Attachment #2: reg_demo.c --]
[-- Type: text/x-csrc, Size: 6015 bytes --]

/*
 * Copyright (C) 2006 Niklaus Giger <niklaus.giger@domain.hid>.
 *
 * VxWorks is a registered trademark of Wind River Systems, Inc.
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License as
 * published by the Free Software Foundation; either version 2 of the
 * License, or (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
 */

#include <vxworks/vxworks.h>

#define ROOT_TASK_PRI        100
#define ROOT_STACK_SIZE      16*1024

#define CONSUMER_TASK_PRI    115
#define CONSUMER_STACK_SIZE  24*1024

#define PRODUCER_TASK_PRI    110
#define PRODUCER_STACK_SIZE  24*1024

#define CONSUMER_WAIT 150
#define PRODUCER_TRIG 40

int root_thread_init(void);
void root_thread_exit(void);

#if !defined(__KERNEL__) && !defined(__XENO_SIM__)

#include <sys/mman.h>
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>

#define MODULE_LICENSE(x)

#define xnprintf printf

int main (int argc, char *argv[])
{
    int tid;
    mlockall(MCL_CURRENT|MCL_FUTURE);

    atexit(&root_thread_exit);

    tid = taskSpawn("RootTask",
		    ROOT_TASK_PRI,
		    0,
		    ROOT_STACK_SIZE,
		    (FUNCPTR)&root_thread_init,
		    0,0,0,0,0,0,0,0,0,0);
    if (tid)
	pause();

    return 1;
}

#endif /* Native, user-space execution */

MODULE_LICENSE("GPL");

static int producer_tid,
           consumer_tid,
           message_qid,
           emptySema,
           fullSema,
           countingSema,
           mutexForward,
           mutexBackward;

void lockForward (int a0, int a1, int a2, int a3, int a4,
		    int a5, int a6, int a7, int a8, int a9)
{
    xnprintf("%s: %d Started\n",__FUNCTION__, tickGet());
    semTake(mutexForward,  WAIT_FOREVER);
    semTake(mutexBackward, WAIT_FOREVER);
    xnprintf("%s: %d got both mutexes\n",__FUNCTION__, tickGet());
    taskDelay(10);
    xnprintf("%s: %d will give both mutexes\n",__FUNCTION__, tickGet());
    semGive(mutexBackward);
    semGive(mutexForward);
    xnprintf("%s: %d Done\n",__FUNCTION__, tickGet());
    taskExit(0);
}

void lockBackward (int a0, int a1, int a2, int a3, int a4,
		    int a5, int a6, int a7, int a8, int a9)
{
    xnprintf("%s: %d Started\n",__FUNCTION__, tickGet());
    semTake(mutexBackward, WAIT_FOREVER);
    semTake(mutexForward,  WAIT_FOREVER);
    xnprintf("%s: %d got both mutexes\n",__FUNCTION__, tickGet());
    taskDelay(10);
    xnprintf("%s: %d will give both mutexes\n",__FUNCTION__, tickGet());
    semGive(mutexForward);
    semGive(mutexBackward);
    xnprintf("%s: %d Done\n",__FUNCTION__, tickGet());
    taskExit(0);
}

#define MSG_SIZE 16
void consumer_task (int a0, int a1, int a2, int a3, int a4,
		    int a5, int a6, int a7, int a8, int a9)
{
    char msg[MSG_SIZE];
    int sz;
    xnprintf("%s: %d Started\n",__FUNCTION__, tickGet());
    if ((sz = msgQReceive(message_qid,(char *)&msg,sizeof(msg), 100)) != ERROR)
	    xnprintf("Now playing %s...\n",msg);
    xnprintf("%s: %d Suspending myself. After receiving sz %d\n",__FUNCTION__, tickGet(), sz);
    taskSuspend(taskIdSelf());
    xnprintf("%s: %d Done\n",__FUNCTION__, tickGet());
    taskExit(0);
}

void producer_task (int a0, int a1, int a2, int a3, int a4,
		    int a5, int a6, int a7, int a8, int a9)
{
    int res;
    const char s1[MSG_SIZE] = "first msg";
    const char s2[MSG_SIZE] = "second msg";
    xnprintf("%s: %d Started  xx\n",__FUNCTION__, tickGet());
    res = msgQSend(message_qid,(char *)&s1,sizeof(s1),WAIT_FOREVER,MSG_PRI_NORMAL);
    xnprintf("%s: %d msg sent %d\n",__FUNCTION__, tickGet(), res);
    res = msgQSend(message_qid,(char *)&s2,sizeof(s2),WAIT_FOREVER,MSG_PRI_NORMAL);
    xnprintf("%s: %d msg sent %d\n",__FUNCTION__, tickGet(), res);
    xnprintf("%s: %d done\n",__FUNCTION__, tickGet());
    taskExit(0);
}

int root_thread_init (void)
{
    emptySema     = semBCreate(SEM_EMPTY, 0);
    fullSema      = semBCreate(SEM_FULL,  SEM_Q_FIFO);
    countingSema  = semCCreate(10,        SEM_Q_PRIORITY);
    mutexForward  = semMCreate(SEM_Q_PRIORITY);
    mutexBackward = semMCreate(SEM_Q_PRIORITY | SEM_INVERSION_SAFE | SEM_DELETE_SAFE);

    message_qid  = msgQCreate(16, MSG_SIZE, MSG_Q_FIFO);
    consumer_tid = taskSpawn("ConsumerTask",
			     CONSUMER_TASK_PRI,
			     0,
			     CONSUMER_STACK_SIZE,
			     (FUNCPTR)&consumer_task,
			     0,0,0,0,0,0,0,0,0,0);

    producer_tid = taskSpawn("ProducerTask",
			     PRODUCER_TASK_PRI,
			     0,
			     PRODUCER_STACK_SIZE,
			     (FUNCPTR)&producer_task,
			     0,0,0,0,0,0,0,0,0,0);
    producer_tid = taskSpawn("LockForward",
			     PRODUCER_TASK_PRI,
			     0,
			     PRODUCER_STACK_SIZE,
			     (FUNCPTR)&lockForward,
			     0,0,0,0,0,0,0,0,0,0);
    producer_tid = taskSpawn("LockBackward",
			     PRODUCER_TASK_PRI,
			     0,
			     PRODUCER_STACK_SIZE,
			     (FUNCPTR)&lockBackward,
			     0,0,0,0,0,0,0,0,0,0);
//    taskDelay(40);
    xnprintf("\n\
This is a small demo for the debugging option CONFIG_XENO_EXPORT_REGISTRY. \n\
If you compile the xenomai kernel with CONFIG_XENO_EXPORT_REGISTRY=y \n\
in your kernel .config you will find files under /proc/xenomai/registry.  \n\
tasks/*:      gives information about running vxworks tasks \n\
semaphores/*: gives information about the vxworks semaphores \n\
msgqs/*:      gives information about the vxworks message queues \n\
\n\
Some vxWorks tasks should be blocked. Now enter:\n\
ls -R /proc/xenomai/registry/vxworks/* && cat /proc/xenomai/registry/vxworks/*/* \n");

    return 0;
}

void root_thread_exit (void)

{
    xnprintf("%s: Done\n",__FUNCTION__);
}

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

[Philippe Gerum]

On Wed, 2006-10-25 at 23:46 +0200, Niklaus Giger wrote:
> Hi
> 
> While trying to make a small demo app for Xenomai's registry I stumbled about 
> the following bug of the vxWorks skin.
> 
> taskSuspend provokes (sometimes) a switch to the secondary mode, e.g. the 
> output of the attached demo gives:
> >  reg_demo &
> > ~ $ Xenomai: Switching ConsumerTask to secondary mode after exception #1025

This is the same issue that you raised back then, and that we did not
fix yet:
https://mail.gna.org/public/xenomai-core/2006-09/msg00177.html

#1025 looks like being an ISI exception due to some unmapped memory
being referred to. You mentioned CONFIG_XENO_OPT_DEBUG as possibly being
part of the problem/solution; could you check whether this error still
occurs when this option is disabled in the nucleus?

-- 
Philippe.

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

[Niklaus Giger]

Am Freitag, 27. Oktober 2006 18:38 schrieb Philippe Gerum:
> On Wed, 2006-10-25 at 23:46 +0200, Niklaus Giger wrote:
> > Hi
> >
> > While trying to make a small demo app for Xenomai's registry I stumbled
> > about the following bug of the vxWorks skin.
> >
> > taskSuspend provokes (sometimes) a switch to the secondary mode, e.g. the
> >
> > output of the attached demo gives:
> > >  reg_demo &
> > > ~ $ Xenomai: Switching ConsumerTask to secondary mode after exception
> > > #1025
>
> This is the same issue that you raised back then, and that we did not
> fix yet:
> https://mail.gna.org/public/xenomai-core/2006-09/msg00177.html
>
> #1025 looks like being an ISI exception due to some unmapped memory
> being referred to. You mentioned CONFIG_XENO_OPT_DEBUG as possibly being
> part of the problem/solution; could you check whether this error still
> occurs when this option is disabled in the nucleus?
I recompiled the kernel with CONFIG_XENO_OPT_DEBUG disabled and the error went 
away.

-- 
Niklaus Giger

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

[Philippe Gerum]

On Sat, 2006-10-28 at 14:54 +0200, Niklaus Giger wrote:
> Am Freitag, 27. Oktober 2006 18:38 schrieb Philippe Gerum:
> > On Wed, 2006-10-25 at 23:46 +0200, Niklaus Giger wrote:
> > > Hi
> > >
> > > While trying to make a small demo app for Xenomai's registry I stumbled
> > > about the following bug of the vxWorks skin.
> > >
> > > taskSuspend provokes (sometimes) a switch to the secondary mode, e.g. the
> > >
> > > output of the attached demo gives:
> > > >  reg_demo &
> > > > ~ $ Xenomai: Switching ConsumerTask to secondary mode after exception
> > > > #1025
> >
> > This is the same issue that you raised back then, and that we did not
> > fix yet:
> > https://mail.gna.org/public/xenomai-core/2006-09/msg00177.html
> >
> > #1025 looks like being an ISI exception due to some unmapped memory
> > being referred to. You mentioned CONFIG_XENO_OPT_DEBUG as possibly being
> > part of the problem/solution; could you check whether this error still
> > occurs when this option is disabled in the nucleus?
> I recompiled the kernel with CONFIG_XENO_OPT_DEBUG disabled and the error went 
> away.a

Does disabling CONFIG_XENO_OPT_DEBUG_QUEUES while keeping
CONFIG_XENO_OPT_DEBUG enabled change anything?

-- 
Philippe.

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

[Niklaus Giger]

[-- Attachment #1: Type: text/plain, Size: 4899 bytes --]

Am Samstag, 28. Oktober 2006 14:54 schrieb Niklaus Giger:
> Am Freitag, 27. Oktober 2006 18:38 schrieb Philippe Gerum:
> > On Wed, 2006-10-25 at 23:46 +0200, Niklaus Giger wrote:
> > > Hi
> > >
> > > While trying to make a small demo app for Xenomai's registry I stumbled
> > > about the following bug of the vxWorks skin.
> > >
> > > taskSuspend provokes (sometimes) a switch to the secondary mode, e.g.
> > > the
> > >
> > > output of the attached demo gives:
> > > >  reg_demo &
> > > > ~ $ Xenomai: Switching ConsumerTask to secondary mode after exception
> > > > #1025
> >
> > This is the same issue that you raised back then, and that we did not
> > fix yet:
> > https://mail.gna.org/public/xenomai-core/2006-09/msg00177.html
> >
> > #1025 looks like being an ISI exception due to some unmapped memory
> > being referred to. You mentioned CONFIG_XENO_OPT_DEBUG as possibly being
> > part of the problem/solution; could you check whether this error still
> > occurs when this option is disabled in the nucleus?
>
> 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?)

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 think I really have to reactivate my old Walnut board to have common 
platform to test with Wolfgang Grandegger.
             
Best regards
           
-- 
Niklaus Giger

[-- Attachment #2: simple.c --]
[-- Type: text/x-csrc, Size: 1642 bytes --]

/*
 * Copyright (C) 2006 Niklaus Giger <niklaus.giger@domain.hid>.
 *
 * VxWorks is a registered trademark of Wind River Systems, Inc.
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License as
 * published by the Free Software Foundation; either version 2 of the
 * License, or (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
 */

#include <vxworks/vxworks.h>

#define ROOT_TASK_PRI        100
#define ROOT_STACK_SIZE      32*1024

int root_thread_init(void);
void root_thread_exit(void);

#if !defined(__KERNEL__) && !defined(__XENO_SIM__)

#include <sys/mman.h>
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>

#define MODULE_LICENSE(x)

#define xnprintf printf

int main (int argc, char *argv[])
{
    int tid;
    mlockall(MCL_CURRENT|MCL_FUTURE);

    tid = taskSpawn("RootTask",
		    ROOT_TASK_PRI,
		    0,
		    ROOT_STACK_SIZE,
		    (FUNCPTR)&root_thread_init,
		    0,0,0,0,0,0,0,0,0,0);
    if (tid)
	pause();

    return 0;
}

#endif /* Native, user-space execution */

MODULE_LICENSE("GPL");

int root_thread_init (void)
{
    printf("\nroot_thread_init 3\n");
    exit(0);
    return 0;
}

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

[Philippe Gerum]

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.

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

[Philippe Gerum]

On Sat, 2006-10-28 at 19:40 +0200, Niklaus Giger wrote:
> 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)   

This looks like a sane kernel call frame for handling an invalid memory
dereference from user-space. Running the faulting application over GDB
would probably give us more information.

>            
-- 
Philippe.

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

[Niklaus Giger]

Am Samstag, 28. Oktober 2006 20:00 schrieb Philippe Gerum:
> 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/syst
> >em.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:290
> >7 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.
>
Could be. I have only a gdbserver running on the PPC405 system. I compiled 
again without ld -static. Then I do the following:
> This GDB was configured as "powerpc-linux-gnu"...Using host libthread_db
> library "/lib/tls/libthread_db.so.1".
>
> (gdb) set solib-absolute-prefix /mnt/data.ng/hcu/rootfs
> (gdb) dir /mnt/data.ng/hcu/rootfs
> Source directories searched: /mnt/data.ng/hcu/rootfs:$cdir:$cwd
> (gdb) target remote 172.25.1.5:2345
> Remote debugging using 172.25.1.5:2345
> 0x3000fa18 in ?? ()
> (gdb) cont
> Continuing.
> [New thread 16384]
>
> Program received signal SIGILL, Illegal instruction.
> [Switching to thread 16384]
> 0x3000ca1c in _dl_name_match_p () from /mnt/data.ng/hcu/rootfs/lib/ld.so.1
> (gdb) bt fu
> #0  0x3000ca1c in _dl_name_match_p () from
> /mnt/data.ng/hcu/rootfs/lib/ld.so.1 No symbol table info available.
> #1  0x30008878 in do_lookup_x () from /mnt/data.ng/hcu/rootfs/lib/ld.so.1
> No symbol table info available.
> #2  0x30008cd8 in _dl_lookup_symbol_x () from
> /mnt/data.ng/hcu/rootfs/lib/ld.so.1 No symbol table info available.
> #3  0x3000b2c8 in fixup () from /mnt/data.ng/hcu/rootfs/lib/ld.so.1
> No symbol table info available.
> #4  0x3000b528 in _dl_runtime_resolve () from
> /mnt/data.ng/hcu/rootfs/lib/ld.so.1 No symbol table info available.
> #5  0x3000b528 in _dl_runtime_resolve () from
> /mnt/data.ng/hcu/rootfs/lib/ld.so.1 No symbol table info available.
> #6  0x3000b528 in _dl_runtime_resolve () from
> /mnt/data.ng/hcu/rootfs/lib/ld.so.1 No symbol table info available.
> #7  0x3000b528 in _dl_runtime_resolve () from
> /mnt/data.ng/hcu/rootfs/lib/ld.so.1 No symbol table info available.
> #8  0x3000b528 in _dl_runtime_resolve () from
> /mnt/data.ng/hcu/rootfs/lib/ld.so.1 No symbol table info available.
> #9  0x3000b528 in _dl_runtime_resolve () from
> /mnt/data.ng/hcu/rootfs/lib/ld.so.1 No symbol table info available.
> #10 0x3000b528 in _dl_runtime_resolve () from
> /mnt/data.ng/hcu/rootfs/lib/ld.so.1 No symbol table info available.
> Previous frame inner to this frame (corrupt stack?)
> (gdb)
But I have no idea why I get this behaviour.
My toolchain is not a ELDK, but was also built using crosstool.

Setting a breakpoint at _dl_runtime_resolve gives:
> 0x3000fa18 in ?? ()
> (gdb) break _dl_runtime_resolve
> Function "_dl_runtime_resolve" not defined.
> Make breakpoint pending on future shared library load? (y or [n]) y
> Breakpoint 1 (_dl_runtime_resolve) pending.
> (gdb) cont
> Continuing.
> Breakpoint 2 at 0x3000b4f4
> Pending breakpoint "_dl_runtime_resolve" resolved
> [New thread 16384]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to thread 16384]
> 0x00000000 in ?? ()
> (gdb) info stack
> #0  0x00000000 in ?? ()
> Cannot access memory at address 0x4
> (gdb) bt full
> #0  0x00000000 in ?? ()
> No symbol table info available.
> Cannot access memory at address 0x4

Best regards

-- 
Niklaus Giger

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

[Wolfgang Grandegger]

Niklaus Giger wrote:
> Am Samstag, 28. Oktober 2006 14:54 schrieb Niklaus Giger:
>> Am Freitag, 27. Oktober 2006 18:38 schrieb Philippe Gerum:
>>> On Wed, 2006-10-25 at 23:46 +0200, Niklaus Giger wrote:
>>>> Hi
>>>>
>>>> While trying to make a small demo app for Xenomai's registry I stumbled
>>>> about the following bug of the vxWorks skin.
>>>>
>>>> taskSuspend provokes (sometimes) a switch to the secondary mode, e.g.
>>>> the
>>>>
>>>> output of the attached demo gives:
>>>>>  reg_demo &
>>>>> ~ $ Xenomai: Switching ConsumerTask to secondary mode after exception
>>>>> #1025
>>> This is the same issue that you raised back then, and that we did not
>>> fix yet:
>>> https://mail.gna.org/public/xenomai-core/2006-09/msg00177.html
>>>
>>> #1025 looks like being an ISI exception due to some unmapped memory
>>> being referred to. You mentioned CONFIG_XENO_OPT_DEBUG as possibly being
>>> part of the problem/solution; could you check whether this error still
>>> occurs when this option is disabled in the nucleus?
>> 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?)
> 
> 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.

My impression from our last discussion was that your toolchain is 
somehow broken as I was unable to reproduce your problems on (almost) 
the same hardware

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

It would make more sense to use the ELDK4 for comparison. I don't think 
it depends on the hardware.

Wolfgang.

> 
> 
> ------------------------------------------------------------------------
> 
> /*
>  * Copyright (C) 2006 Niklaus Giger <niklaus.giger@domain.hid>.
>  *
>  * VxWorks is a registered trademark of Wind River Systems, Inc.
>  *
>  * This program is free software; you can redistribute it and/or
>  * modify it under the terms of the GNU General Public License as
>  * published by the Free Software Foundation; either version 2 of the
>  * License, or (at your option) any later version.
>  *
>  * This program is distributed in the hope that it will be useful,
>  * but WITHOUT ANY WARRANTY; without even the implied warranty of
>  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>  * GNU General Public License for more details.
>  *
>  * You should have received a copy of the GNU General Public License
>  * along with this program; if not, write to the Free Software
>  * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
>  */
> 
> #include <vxworks/vxworks.h>
> 
> #define ROOT_TASK_PRI        100
> #define ROOT_STACK_SIZE      32*1024
> 
> int root_thread_init(void);
> void root_thread_exit(void);
> 
> #if !defined(__KERNEL__) && !defined(__XENO_SIM__)
> 
> #include <sys/mman.h>
> #include <stdlib.h>
> #include <stdio.h>
> #include <unistd.h>
> 
> #define MODULE_LICENSE(x)
> 
> #define xnprintf printf
> 
> int main (int argc, char *argv[])
> {
>     int tid;
>     mlockall(MCL_CURRENT|MCL_FUTURE);
> 
>     tid = taskSpawn("RootTask",
> 		    ROOT_TASK_PRI,
> 		    0,
> 		    ROOT_STACK_SIZE,
> 		    (FUNCPTR)&root_thread_init,
> 		    0,0,0,0,0,0,0,0,0,0);
>     if (tid)
> 	pause();
> 
>     return 0;
> }
> 
> #endif /* Native, user-space execution */
> 
> MODULE_LICENSE("GPL");
> 
> int root_thread_init (void)
> {
>     printf("\nroot_thread_init 3\n");
>     exit(0);
>     return 0;
> }
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core

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

[Niklaus Giger]

Am Samstag, 28. Oktober 2006 20:36 schrieb Wolfgang Grandegger:
> Niklaus Giger wrote:
> > Am Samstag, 28. Oktober 2006 14:54 schrieb Niklaus Giger:
> >> Am Freitag, 27. Oktober 2006 18:38 schrieb Philippe Gerum:
> >>> On Wed, 2006-10-25 at 23:46 +0200, Niklaus Giger wrote:
> >>>> Hi
> My impression from our last discussion was that your toolchain is
> somehow broken as I was unable to reproduce your problems on (almost)
> the same hardware
>
> > I think I really have to reactivate my old Walnut board to have common
> > platform to test with Wolfgang Grandegger.
>
> It would make more sense to use the ELDK4 for comparison. I don't think
> it depends on the hardware.
As I forced my son to run on his MacMini (Intel Core Duo) only Linux and no 
MacOsX (he discovered widelands and was quite happy), I had a platform where 
I could install the CD with ELDK 4.0, which I had laying around.

After some setting up of my environment and tweaking my scripts to work with 
ELDK (e.g. adding --host=ppc CC=ppc_4xx-gcc to my xenomai/configure) I ended 
up with a nice environment and rootfs with much more precompiled programs 
than I had ever before. Debugging on the platform is now as good as on my 
PowerBook.

My situation is now as follows:
- ELDK 4.0 installed on Debian Etch MacMini
- Using ELD 4.0 rootfs ppc_4xx
- compiled the kernel uImage, modules, xenomai using ppc_4xx-gcc 
   (but NOT adding any -mcpu=40x flag to the compiler) 

The trap 0 in  /proc/xenomai/fault seems to count on each invocation of simple
  0:           51    (Data or instruction access)
gdb however no does not show anything abnormal, as it says now
> This GDB was configured as "ppc-linux"...Using host libthread_db library
> "/lib/tls/libthread_db.so.1".
>
> (gdb) run
> Starting program: /bin/simple
> [Thread debugging using libthread_db enabled]
> [New Thread 805422032 (LWP 639)]
> root_thread_init 4[New Thread 805455088 (LWP 642)]
>
> Program exited normally.
> (gdb) quit

Though I am still puzzled.

Best regards

-- 
Niklaus Giger

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

[Philippe Gerum]

On Sun, 2006-10-29 at 22:02 +0100, Niklaus Giger wrote:

[...]

> The trap 0 in  /proc/xenomai/fault seems to count on each invocation of simple
>   0:           51    (Data or instruction access)

This means that we do encounter minor or major faults which end up being
gracefully handled. This could also happen upon request to expand the
process stack (conversely, does raising the size of the process stack at
init changes anything?). You may want to instrument
arch/ppc/mm/fault.c:do_page_fault, in order to identify which faults are
processed on behalf of the test thread.

> gdb however no does not show anything abnormal, as it says now
> > This GDB was configured as "ppc-linux"...Using host libthread_db library
> > "/lib/tls/libthread_db.so.1".
> >
> > (gdb) run
> > Starting program: /bin/simple
> > [Thread debugging using libthread_db enabled]
> > [New Thread 805422032 (LWP 639)]
> > root_thread_init 4[New Thread 805455088 (LWP 642)]
> >
> > Program exited normally.
> > (gdb) quit
> 
> Though I am still puzzled.
> 
> Best regards
> 
-- 
Philippe.

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

[Niklaus Giger]

Am Montag, 30. Oktober 2006 08:31 schrieb Wolfgang Grandegger:
> Niklaus Giger wrote:
> > Am Samstag, 28. Oktober 2006 20:36 schrieb Wolfgang Grandegger:
> >> Niklaus Giger wrote:
> >>> Am Samstag, 28. Oktober 2006 14:54 schrieb Niklaus Giger:
> >>>> Am Freitag, 27. Oktober 2006 18:38 schrieb Philippe Gerum:
> >>>>> On Wed, 2006-10-25 at 23:46 +0200, Niklaus Giger wrote:
> >>>>>> Hi
> >>
> >> My impression from our last discussion was that your toolchain is
> >> somehow broken as I was unable to reproduce your problems on (almost)
> >> the same hardware
> >>
> >>> I think I really have to reactivate my old Walnut board to have common
> >>> platform to test with Wolfgang Grandegger.
> >>
> >> It would make more sense to use the ELDK4 for comparison. I don't think
> >> it depends on the hardware.
> >
> > As I forced my son to run on his MacMini (Intel Core Duo) only Linux and
> > no MacOsX (he discovered widelands and was quite happy), I had a platform
> > where I could install the CD with ELDK 4.0, which I had laying around.
> >
> > After some setting up of my environment and tweaking my scripts to work
> > with ELDK (e.g. adding --host=ppc CC=ppc_4xx-gcc to my xenomai/configure)
> > I ended
>
> --host=ppc-linux is already enough with CROSS_COMPILE=ppc_4xx- set.
>
> > up with a nice environment and rootfs with much more precompiled programs
> > than I had ever before. Debugging on the platform is now as good as on my
> > PowerBook.
> >
> > My situation is now as follows:
> > - ELDK 4.0 installed on Debian Etch MacMini
> > - Using ELD 4.0 rootfs ppc_4xx
> > - compiled the kernel uImage, modules, xenomai using ppc_4xx-gcc
> >    (but NOT adding any -mcpu=40x flag to the compiler)
> >
> > The trap 0 in  /proc/xenomai/fault seems to count on each invocation of
> > simple 0:           51    (Data or instruction access)
> > gdb however no does not show anything abnormal, as it says now
> >
> >> This GDB was configured as "ppc-linux"...Using host libthread_db library
> >> "/lib/tls/libthread_db.so.1".
> >>
> >> (gdb) run
> >> Starting program: /bin/simple
> >> [Thread debugging using libthread_db enabled]
> >> [New Thread 805422032 (LWP 639)]
> >> root_thread_init 4[New Thread 805455088 (LWP 642)]
> >>
> >> Program exited normally.
> >> (gdb) quit
> >
> > Though I am still puzzled.
>
> Could you please send me your Makefile or the compile command to make
> "simple", then I would give it a try on my setup.
>
Here are the commands
ppc_4xx-gcc -I../.. -I/home/hcu/rootfs/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -I/net/ng/mnt/data.ng/hcu/project/vx_skin -D__XENO__ -g -DVXWORKS    -c -o 
simple.o simple.c
ppc_4xx-gcc -o simple 
simple.o -L/home/hcu/rootfs/usr/xenomai/lib -lpthread  -lvxworks

Thanks for your help.

Will be busy till tomorrow evening. 

Best regards

-- 
Niklaus Giger

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

[Wolfgang Grandegger]

Niklaus Giger wrote:
> Am Samstag, 28. Oktober 2006 20:36 schrieb Wolfgang Grandegger:
>> Niklaus Giger wrote:
>>> Am Samstag, 28. Oktober 2006 14:54 schrieb Niklaus Giger:
>>>> Am Freitag, 27. Oktober 2006 18:38 schrieb Philippe Gerum:
>>>>> On Wed, 2006-10-25 at 23:46 +0200, Niklaus Giger wrote:
>>>>>> Hi
>> My impression from our last discussion was that your toolchain is
>> somehow broken as I was unable to reproduce your problems on (almost)
>> the same hardware
>>
>>> I think I really have to reactivate my old Walnut board to have common
>>> platform to test with Wolfgang Grandegger.
>> It would make more sense to use the ELDK4 for comparison. I don't think
>> it depends on the hardware.
> As I forced my son to run on his MacMini (Intel Core Duo) only Linux and no 
> MacOsX (he discovered widelands and was quite happy), I had a platform where 
> I could install the CD with ELDK 4.0, which I had laying around.
> 
> After some setting up of my environment and tweaking my scripts to work with 
> ELDK (e.g. adding --host=ppc CC=ppc_4xx-gcc to my xenomai/configure) I ended 

--host=ppc-linux is already enough with CROSS_COMPILE=ppc_4xx- set.

> up with a nice environment and rootfs with much more precompiled programs 
> than I had ever before. Debugging on the platform is now as good as on my 
> PowerBook.
> 
> My situation is now as follows:
> - ELDK 4.0 installed on Debian Etch MacMini
> - Using ELD 4.0 rootfs ppc_4xx
> - compiled the kernel uImage, modules, xenomai using ppc_4xx-gcc 
>    (but NOT adding any -mcpu=40x flag to the compiler) 
> 
> The trap 0 in  /proc/xenomai/fault seems to count on each invocation of simple
>   0:           51    (Data or instruction access)
> gdb however no does not show anything abnormal, as it says now
>> This GDB was configured as "ppc-linux"...Using host libthread_db library
>> "/lib/tls/libthread_db.so.1".
>>
>> (gdb) run
>> Starting program: /bin/simple
>> [Thread debugging using libthread_db enabled]
>> [New Thread 805422032 (LWP 639)]
>> root_thread_init 4[New Thread 805455088 (LWP 642)]
>>
>> Program exited normally.
>> (gdb) quit
> 
> Though I am still puzzled.

Could you please send me your Makefile or the compile command to make 
"simple", then I would give it a try on my setup.

Wolfgang.

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

[Wolfgang Grandegger]

Niklaus Giger wrote:
> Am Montag, 30. Oktober 2006 08:31 schrieb Wolfgang Grandegger:
>> Niklaus Giger wrote:
>>> Am Samstag, 28. Oktober 2006 20:36 schrieb Wolfgang Grandegger:
>>>> Niklaus Giger wrote:
>>>>> Am Samstag, 28. Oktober 2006 14:54 schrieb Niklaus Giger:
>>>>>> Am Freitag, 27. Oktober 2006 18:38 schrieb Philippe Gerum:
>>>>>>> On Wed, 2006-10-25 at 23:46 +0200, Niklaus Giger wrote:
>>>>>>>> Hi
>>>> My impression from our last discussion was that your toolchain is
>>>> somehow broken as I was unable to reproduce your problems on (almost)
>>>> the same hardware
>>>>
>>>>> I think I really have to reactivate my old Walnut board to have common
>>>>> platform to test with Wolfgang Grandegger.
>>>> It would make more sense to use the ELDK4 for comparison. I don't think
>>>> it depends on the hardware.
>>> As I forced my son to run on his MacMini (Intel Core Duo) only Linux and
>>> no MacOsX (he discovered widelands and was quite happy), I had a platform
>>> where I could install the CD with ELDK 4.0, which I had laying around.
>>>
>>> After some setting up of my environment and tweaking my scripts to work
>>> with ELDK (e.g. adding --host=ppc CC=ppc_4xx-gcc to my xenomai/configure)
>>> I ended
>> --host=ppc-linux is already enough with CROSS_COMPILE=ppc_4xx- set.
>>
>>> up with a nice environment and rootfs with much more precompiled programs
>>> than I had ever before. Debugging on the platform is now as good as on my
>>> PowerBook.
>>>
>>> My situation is now as follows:
>>> - ELDK 4.0 installed on Debian Etch MacMini
>>> - Using ELD 4.0 rootfs ppc_4xx
>>> - compiled the kernel uImage, modules, xenomai using ppc_4xx-gcc
>>>    (but NOT adding any -mcpu=40x flag to the compiler)
>>>
>>> The trap 0 in  /proc/xenomai/fault seems to count on each invocation of
>>> simple 0:           51    (Data or instruction access)
>>> gdb however no does not show anything abnormal, as it says now
>>>
>>>> This GDB was configured as "ppc-linux"...Using host libthread_db library
>>>> "/lib/tls/libthread_db.so.1".
>>>>
>>>> (gdb) run
>>>> Starting program: /bin/simple
>>>> [Thread debugging using libthread_db enabled]
>>>> [New Thread 805422032 (LWP 639)]
>>>> root_thread_init 4[New Thread 805455088 (LWP 642)]
>>>>
>>>> Program exited normally.
>>>> (gdb) quit
>>> Though I am still puzzled.
>> Could you please send me your Makefile or the compile command to make
>> "simple", then I would give it a try on my setup.
>>
> Here are the commands
> ppc_4xx-gcc -I../.. -I/home/hcu/rootfs/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -I/net/ng/mnt/data.ng/hcu/project/vx_skin -D__XENO__ -g -DVXWORKS    -c -o 
> simple.o simple.c
> ppc_4xx-gcc -o simple 
> simple.o -L/home/hcu/rootfs/usr/xenomai/lib -lpthread  -lvxworks

Again the same question. What versions of kernel, ADEOS-IPIPE and 
Xenomai are you using.I have some problems to get the kernel booted with 
the VxWorks skin emulation. I understood, that I must build the Native 
and POSIX skin as modules and enable the periodic timer support with a 
resonable frequency.

Wolfgang.


 > Thanks for your help.
 >
 > Will be busy till tomorrow evening.
 >
 > Best regards
 >

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

[Niklaus Giger]

[-- Attachment #1: Type: text/plain, Size: 3582 bytes --]

Am Dienstag, 31. Oktober 2006 09:14 schrieb Wolfgang Grandegger:
> Niklaus Giger wrote:
> > Am Montag, 30. Oktober 2006 08:31 schrieb Wolfgang Grandegger:
> >> Niklaus Giger wrote:
> >>> Am Samstag, 28. Oktober 2006 20:36 schrieb Wolfgang Grandegger:
> >>>> Niklaus Giger wrote:
> >>>>> Am Samstag, 28. Oktober 2006 14:54 schrieb Niklaus Giger:
> >>>>>> Am Freitag, 27. Oktober 2006 18:38 schrieb Philippe Gerum:
> >>>>>>> On Wed, 2006-10-25 at 23:46 +0200, Niklaus Giger wrote:
> >>>>>>>> Hi
> >>>>
> >>>> My impression from our last discussion was that your toolchain is
> >>>> somehow broken as I was unable to reproduce your problems on (almost)
> >>>> the same hardware
> >>>>
> >>>>> I think I really have to reactivate my old Walnut board to have
> >>>>> common platform to test with Wolfgang Grandegger.
> >>>>
> >>>> It would make more sense to use the ELDK4 for comparison. I don't
> >>>> think it depends on the hardware.
> >>>
> >>> As I forced my son to run on his MacMini (Intel Core Duo) only Linux
> >>> and no MacOsX (he discovered widelands and was quite happy), I had a
> >>> platform where I could install the CD with ELDK 4.0, which I had laying
> >>> around.
> >>>
> >>> After some setting up of my environment and tweaking my scripts to work
> >>> with ELDK (e.g. adding --host=ppc CC=ppc_4xx-gcc to my
> >>> xenomai/configure) I ended
> >>
> >> --host=ppc-linux is already enough with CROSS_COMPILE=ppc_4xx- set.
> >>
> >>> up with a nice environment and rootfs with much more precompiled
> >>> programs than I had ever before. Debugging on the platform is now as
> >>> good as on my PowerBook.
> >>>
> >>> My situation is now as follows:
> >>> - ELDK 4.0 installed on Debian Etch MacMini
> >>> - Using ELD 4.0 rootfs ppc_4xx
> >>> - compiled the kernel uImage, modules, xenomai using ppc_4xx-gcc
> >>>    (but NOT adding any -mcpu=40x flag to the compiler)
> >>>
> >>> The trap 0 in  /proc/xenomai/fault seems to count on each invocation of
> >>> simple 0:           51    (Data or instruction access)
> >>> gdb however no does not show anything abnormal, as it says now
> >>>
> >>>> This GDB was configured as "ppc-linux"...Using host libthread_db
> >>>> library "/lib/tls/libthread_db.so.1".
> >>>>
> >>>> (gdb) run
> >>>> Starting program: /bin/simple
> >>>> [Thread debugging using libthread_db enabled]
> >>>> [New Thread 805422032 (LWP 639)]
> >>>> root_thread_init 4[New Thread 805455088 (LWP 642)]
> >>>>
> >>>> Program exited normally.
> >>>> (gdb) quit
> >>>
> >>> Though I am still puzzled.
> >>
> >> Could you please send me your Makefile or the compile command to make
> >> "simple", then I would give it a try on my setup.
> >
> > Here are the commands
> > ppc_4xx-gcc -I../.. -I/home/hcu/rootfs/usr/xenomai/include -D_GNU_SOURCE
> > -D_REENTRANT -I/net/ng/mnt/data.ng/hcu/project/vx_skin -D__XENO__ -g
> > -DVXWORKS    -c -o simple.o simple.c
> > ppc_4xx-gcc -o simple
> > simple.o -L/home/hcu/rootfs/usr/xenomai/lib -lpthread  -lvxworks
>
> Again the same question. What versions of kernel, ADEOS-IPIPE and
> Xenomai are you using.I have some problems to get the kernel booted with
> the VxWorks skin emulation. I understood, that I must build the Native
> and POSIX skin as modules and enable the periodic timer support with a
> resonable frequency.
I used revision 1747 of the xenomai trunk, linux 2.4.17 + some small patches 
(attached) for my system, the attached .config, 
adeos-ipipe-2.6.14-ppc-1.5-01.patch.

I have vxworks built-in to enforce that the timers get initialized into the 
periodic mode.

Best regards

-- 
Niklaus Giger

[-- Attachment #2: .config.bz2 --]
[-- Type: application/x-bzip2, Size: 4698 bytes --]

[-- Attachment #3: hcu3-2.6.14.patch.bz2 --]
[-- Type: application/x-bzip2, Size: 7747 bytes --]

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

[Wolfgang Grandegger]

Niklaus Giger wrote:
> Am Dienstag, 31. Oktober 2006 09:14 schrieb Wolfgang Grandegger:
>> Niklaus Giger wrote:
>>> Am Montag, 30. Oktober 2006 08:31 schrieb Wolfgang Grandegger:
>>>> Niklaus Giger wrote:
>>>>> Am Samstag, 28. Oktober 2006 20:36 schrieb Wolfgang Grandegger:
>>>>>> Niklaus Giger wrote:
>>>>>>> Am Samstag, 28. Oktober 2006 14:54 schrieb Niklaus Giger:
>>>>>>>> Am Freitag, 27. Oktober 2006 18:38 schrieb Philippe Gerum:
>>>>>>>>> On Wed, 2006-10-25 at 23:46 +0200, Niklaus Giger wrote:
>>>>>>>>>> Hi
>>>>>> My impression from our last discussion was that your toolchain is
>>>>>> somehow broken as I was unable to reproduce your problems on (almost)
>>>>>> the same hardware
>>>>>>
>>>>>>> I think I really have to reactivate my old Walnut board to have
>>>>>>> common platform to test with Wolfgang Grandegger.
>>>>>> It would make more sense to use the ELDK4 for comparison. I don't
>>>>>> think it depends on the hardware.
>>>>> As I forced my son to run on his MacMini (Intel Core Duo) only Linux
>>>>> and no MacOsX (he discovered widelands and was quite happy), I had a
>>>>> platform where I could install the CD with ELDK 4.0, which I had laying
>>>>> around.
>>>>>
>>>>> After some setting up of my environment and tweaking my scripts to work
>>>>> with ELDK (e.g. adding --host=ppc CC=ppc_4xx-gcc to my
>>>>> xenomai/configure) I ended
>>>> --host=ppc-linux is already enough with CROSS_COMPILE=ppc_4xx- set.
>>>>
>>>>> up with a nice environment and rootfs with much more precompiled
>>>>> programs than I had ever before. Debugging on the platform is now as
>>>>> good as on my PowerBook.
>>>>>
>>>>> My situation is now as follows:
>>>>> - ELDK 4.0 installed on Debian Etch MacMini
>>>>> - Using ELD 4.0 rootfs ppc_4xx
>>>>> - compiled the kernel uImage, modules, xenomai using ppc_4xx-gcc
>>>>>    (but NOT adding any -mcpu=40x flag to the compiler)
>>>>>
>>>>> The trap 0 in  /proc/xenomai/fault seems to count on each invocation of
>>>>> simple 0:           51    (Data or instruction access)
>>>>> gdb however no does not show anything abnormal, as it says now
>>>>>
>>>>>> This GDB was configured as "ppc-linux"...Using host libthread_db
>>>>>> library "/lib/tls/libthread_db.so.1".
>>>>>>
>>>>>> (gdb) run
>>>>>> Starting program: /bin/simple
>>>>>> [Thread debugging using libthread_db enabled]
>>>>>> [New Thread 805422032 (LWP 639)]
>>>>>> root_thread_init 4[New Thread 805455088 (LWP 642)]
>>>>>>
>>>>>> Program exited normally.
>>>>>> (gdb) quit
>>>>> Though I am still puzzled.
>>>> Could you please send me your Makefile or the compile command to make
>>>> "simple", then I would give it a try on my setup.
>>> Here are the commands
>>> ppc_4xx-gcc -I../.. -I/home/hcu/rootfs/usr/xenomai/include -D_GNU_SOURCE
>>> -D_REENTRANT -I/net/ng/mnt/data.ng/hcu/project/vx_skin -D__XENO__ -g
>>> -DVXWORKS    -c -o simple.o simple.c
>>> ppc_4xx-gcc -o simple
>>> simple.o -L/home/hcu/rootfs/usr/xenomai/lib -lpthread  -lvxworks
>> Again the same question. What versions of kernel, ADEOS-IPIPE and
>> Xenomai are you using.I have some problems to get the kernel booted with
>> the VxWorks skin emulation. I understood, that I must build the Native
>> and POSIX skin as modules and enable the periodic timer support with a
>> resonable frequency.
> I used revision 1747 of the xenomai trunk, linux 2.4.17 + some small patches 
                                                    ^^^^^^
                             I think you mean linux 2.4.14 here.

> (attached) for my system, the attached .config, 
> adeos-ipipe-2.6.14-ppc-1.5-01.patch.
> 
> I have vxworks built-in to enforce that the timers get initialized into the 
> periodic mode.

OK, I will use the same setup for my test.

Wolfgang.
> 
> Best regards
> 

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

[Niklaus Giger]

Am Dienstag, 31. Oktober 2006 20:02 schrieb Wolfgang Grandegger:
> > I used revision 1747 of the xenomai trunk, linux 2.4.17 + some small
> > patches
>
>                                                     ^^^^^^
>                              I think you mean linux 2.4.14 here.
Sorry. My mistake: Linux 2.6.14 to match adeos-ipipe-2.6.14-ppc-1.5-01.patch.
-- 
Niklaus Giger

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

[Wolfgang Grandegger]

[-- Attachment #1: Type: text/plain, Size: 3680 bytes --]

Niklaus Giger wrote:
> Am Dienstag, 31. Oktober 2006 09:14 schrieb Wolfgang Grandegger:
>> Niklaus Giger wrote:
>>> Am Montag, 30. Oktober 2006 08:31 schrieb Wolfgang Grandegger:
>>>> Niklaus Giger wrote:
>>>>> Am Samstag, 28. Oktober 2006 20:36 schrieb Wolfgang Grandegger:
>>>>>> Niklaus Giger wrote:
>>>>>>> Am Samstag, 28. Oktober 2006 14:54 schrieb Niklaus Giger:
>>>>>>>> Am Freitag, 27. Oktober 2006 18:38 schrieb Philippe Gerum:
>>>>>>>>> On Wed, 2006-10-25 at 23:46 +0200, Niklaus Giger wrote:
>>>>>>>>>> Hi
>>>>>> My impression from our last discussion was that your toolchain is
>>>>>> somehow broken as I was unable to reproduce your problems on (almost)
>>>>>> the same hardware
>>>>>>
>>>>>>> I think I really have to reactivate my old Walnut board to have
>>>>>>> common platform to test with Wolfgang Grandegger.
>>>>>> It would make more sense to use the ELDK4 for comparison. I don't
>>>>>> think it depends on the hardware.
>>>>> As I forced my son to run on his MacMini (Intel Core Duo) only Linux
>>>>> and no MacOsX (he discovered widelands and was quite happy), I had a
>>>>> platform where I could install the CD with ELDK 4.0, which I had laying
>>>>> around.
>>>>>
>>>>> After some setting up of my environment and tweaking my scripts to work
>>>>> with ELDK (e.g. adding --host=ppc CC=ppc_4xx-gcc to my
>>>>> xenomai/configure) I ended
>>>> --host=ppc-linux is already enough with CROSS_COMPILE=ppc_4xx- set.
>>>>
>>>>> up with a nice environment and rootfs with much more precompiled
>>>>> programs than I had ever before. Debugging on the platform is now as
>>>>> good as on my PowerBook.
>>>>>
>>>>> My situation is now as follows:
>>>>> - ELDK 4.0 installed on Debian Etch MacMini
>>>>> - Using ELD 4.0 rootfs ppc_4xx
>>>>> - compiled the kernel uImage, modules, xenomai using ppc_4xx-gcc
>>>>>    (but NOT adding any -mcpu=40x flag to the compiler)
>>>>>
>>>>> The trap 0 in  /proc/xenomai/fault seems to count on each invocation of
>>>>> simple 0:           51    (Data or instruction access)
>>>>> gdb however no does not show anything abnormal, as it says now
>>>>>
>>>>>> This GDB was configured as "ppc-linux"...Using host libthread_db
>>>>>> library "/lib/tls/libthread_db.so.1".
>>>>>>
>>>>>> (gdb) run
>>>>>> Starting program: /bin/simple
>>>>>> [Thread debugging using libthread_db enabled]
>>>>>> [New Thread 805422032 (LWP 639)]
>>>>>> root_thread_init 4[New Thread 805455088 (LWP 642)]
>>>>>>
>>>>>> Program exited normally.
>>>>>> (gdb) quit
>>>>> Though I am still puzzled.
>>>> Could you please send me your Makefile or the compile command to make
>>>> "simple", then I would give it a try on my setup.
>>> Here are the commands
>>> ppc_4xx-gcc -I../.. -I/home/hcu/rootfs/usr/xenomai/include -D_GNU_SOURCE
>>> -D_REENTRANT -I/net/ng/mnt/data.ng/hcu/project/vx_skin -D__XENO__ -g
>>> -DVXWORKS    -c -o simple.o simple.c
>>> ppc_4xx-gcc -o simple
>>> simple.o -L/home/hcu/rootfs/usr/xenomai/lib -lpthread  -lvxworks
>> Again the same question. What versions of kernel, ADEOS-IPIPE and
>> Xenomai are you using.I have some problems to get the kernel booted with
>> the VxWorks skin emulation. I understood, that I must build the Native
>> and POSIX skin as modules and enable the periodic timer support with a
>> resonable frequency.
> I used revision 1747 of the xenomai trunk, linux 2.4.17 + some small patches 
> (attached) for my system, the attached .config, 
> adeos-ipipe-2.6.14-ppc-1.5-01.patch.
> 
> I have vxworks built-in to enforce that the timers get initialized into the 
> periodic mode.

OK, with a similar setup I get the same results as you have seen on your 
(son's) MacMini. I have attached the output.

Wolfgang.


[-- Attachment #2: simple.log --]
[-- Type: text/x-log, Size: 2076 bytes --]

sh-3.00# export LD_LIBRARY_PATH=/home/wolf/xenomai/lib
bash-3.00# ./simple

root_thread_init 3
bash-3.00# cat /proc/xenomai/faults
TRAP         CPU0
  0:            1    (Data or instruction access)
  1:            0    (Alignment)
  2:            0    (Altivec unavailable)
  3:            0    (Program check exception)
  4:            0    (Machine check exception)
  5:            0    (Unknown)
  6:            0    (Instruction breakpoint)
  7:            0    (Run mode exception)
  8:            0    (Single-step exception)
  9:            0    (Non-recoverable exception)
 10:            0    (Software emulation)
 11:            0    (Debug)
 12:            0    (SPE)
 13:            0    (Altivec assist)
bash-3.00# ./simple

root_thread_init 3
bash-3.00# cat /proc/xenomai/faults
TRAP         CPU0
  0:            2    (Data or instruction access)
  1:            0    (Alignment)
  2:            0    (Altivec unavailable)
  3:            0    (Program check exception)
  4:            0    (Machine check exception)
  5:            0    (Unknown)
  6:            0    (Instruction breakpoint)
  7:            0    (Run mode exception)
  8:            0    (Single-step exception)
  9:            0    (Non-recoverable exception)
 10:            0    (Software emulation)
 11:            0    (Debug)
 12:            0    (SPE)
 13:            0    (Altivec assist)
bash-3.00# gdb simple
GNU gdb Red Hat Linux (6.3.0.0-1.21_1rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "ppc-linux"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run
Starting program: /home/wolf/simple
[Thread debugging using libthread_db enabled]
[New Thread 805422032 (LWP 260)]
[New Thread 805455088 (LWP 263)]

root_thread_init 3

Program exited normally.
(gdb)