[Xenomai-core] Xenomai v2.2-rc2

[Xenomai-core] Xenomai v2.2-rc2

[Philippe Gerum]

Here is the second release candidate for the v2.2 branch. Short log
follows:

[x86,ppc64] Fix ugly Adeos-related SMP bug involving kernel-based
             Xenomai threads.

[nucleus] Extend pipeline head optimizations.
           Provide  thread "held" state for later temporal partitioning
           support.
           Add PIP resource stealing.
           Add support for per-process data.
           Add cleanup handler to synchronization objects.
           Work around SuSE-originated GCC 4.x bug (optimizer
           issue) in message pipe support.
           Fix xnpod_unblock_thread() (don't raise XNBREAK for
           ready threads).
           Fix xnpod_start_thread() (error code propagation).
           Add missing symbol exports.

[posix]   Update for PIP resource stealing.
           Set default mutex priority protocol to PTHREAD_PRIO_NONE.

[rtdm]    Refactor mutex, sema4 and event implementation.
           Fix rtdm_strncpy_from_user().
           Fix PIP handling code.

[vxworks] Update for PIP resource stealing.
           Reset timer upon unload.
           Fix tick handler return value.
	  Fix stack overflow in demo program.

[native]  Update for PIP resource stealing.
           Fix rt_task_delete() when killing a non-shadowed thread.
           Fix T_JOINABLE bit conflict.

[vrtx]    Update for PIP resource stealing.

[rtai]    Update for PIP resource stealing.

[testsuite]  Allow running multiple tests in parallel.
              Allow pinning down the sampling task to a specified
              CPU.

Aside of this, all Adeos patches have been upgraded.

Please see the ChangeLog for details.

http://download.gna.org/xenomai/testing/xenomai-2.2-rc2.tar.bz2

-- 

Philippe.

Re: [Xenomai-core] Xenomai v2.2-rc2

[Niklaus Giger]

Am Samstag, 20. Mai 2006 23:07 schrieb Philippe Gerum:
> Here is the second release candidate for the v2.2 branch. Short log
> follows:
Could you please apply the patch below to make xeno-test send e-mails to 
xenomai-data@domain.hid.

I am unsure whether setting sentby='xenotest.sender@domain.hid' is a good 
idea. Or is this a way to accept e-mails from unkown senders? In any way I 
think it would be nice if one could accept xeno-test messages from 
unsubscribed senders.

I really would like to collect some real data.

Thanks in advance.

Niklaus Giger

Index: scripts/xeno-test.in
===================================================================
--- scripts/xeno-test.in        (Revision 1135)
+++ scripts/xeno-test.in        (Arbeitskopie)
@@ -19,7 +19,7 @@
                name can be full or relative pathname
   -v           verbose
   -M <email>   sends output to given addr
-  -m           sends output to xenotest.output@domain.hid
+  -m           sends output to xenomai-data@domain.hid
   -U <url>     uploads output to given URL

   # following options are passed thru to latency
@@ -167,7 +167,7 @@
 logprefix=/tmp/        # someplace usually there
 prepost=       # command to run pre, and post test (ex ntpq -p)

-email='xenotest.output@domain.hid'      # until formalized
+email='xenomai-data@domain.hid'
 sentby='xenotest.sender@domain.hid'
 url=
 sendit=                # send it by m-mail, u-url

Re: [Xenomai-core] Xenomai v2.2-rc2

[Niklaus Giger]

Am Samstag, 20. Mai 2006 23:07 schrieb Philippe Gerum:
> Here is the second release candidate for the v2.2 branch. Short log
The trunks builds fine on my four targets on 
http://ngiger.dyndns.org/buildbot/

I have however still the following errors running the posix simulators
(see http://ngiger.dyndns.org/buildbot/sim/builds/59/step-check_sim/0). All 
others posix and vxworks test pass.
The output is:

Some problems were reported in:
posix->tthread:tthread.c:141: Expected sequence: SEQ("slicer1",1); got 
SEQ("slicer1",4)
posix->tthread:tthread.c:142: Expected sequence: SEQ("slicer2",1); got 
SEQ("slicer2",4)
posix->tthread:tthread.c:143: Expected sequence: SEQ("slicer1",1); got 
SEQ("root",1)
posix->tthread:tthread.c:144: Expected sequence: SEQ("slicer2",1); reached end 
of recorded sequence.
posix->tthread:tthread.c:145: Expected sequence: SEQ("slicer1",1); reached end 
of recorded sequence.
posix->tthread:tthread.c:146: Expected sequence: SEQ("slicer2",1); reached end 
of recorded sequence.
posix->tthread:tthread.c:147: Expected sequence: SEQ("slicer1",1); reached end 
of recorded sequence.
posix->tthread:tthread.c:148: Expected sequence: SEQ("slicer2",1); reached end 
of recorded sequence.
posix->tthread:tthread.c:149: Expected sequence: SEQ("root",1); reached end of 
recorded sequence.
posix->tthread:tthread.c:153, test finished: 9 failures/ 46 tests

I have however no time to try to fix them, as I am investing more time into 
making xeno-test run automatically on my PPC 405GPr target board.

Best regards

-- 
Niklaus Giger

Re: [Xenomai-core] Xenomai v2.2-rc2

[Gilles Chanteperdrix]

Niklaus Giger wrote:
 > Am Samstag, 20. Mai 2006 23:07 schrieb Philippe Gerum:
 > > Here is the second release candidate for the v2.2 branch. Short log
 > The trunks builds fine on my four targets on 
 > http://ngiger.dyndns.org/buildbot/
 > 
 > I have however still the following errors running the posix simulators
 > (see http://ngiger.dyndns.org/buildbot/sim/builds/59/step-check_sim/0). All 
 > others posix and vxworks test pass.
 > The output is:

The tested feature is round-robin scheduling, which only works when the
system timer is configured in periodic mode; so, when the system timer
is configured in periodic mode, the test should pass.

-- 


					    Gilles Chanteperdrix.

[Xenomai-core] Re: Xenomai v2.2-rc2. PowerPC 405GPr board does not start up

[Niklaus Giger]

Hi everybody

Philippe Gerum wrote:
> Here is the second release candidate for the v2.2 branch. Short log
> follows:
Sorry for reporting so late.

But as my tests did not yet include starting up my board I did not notice
that changes (probably between 2006-05-10 19:30 and 2006-05-11 20:31) made
my board unbootable. 

The board hangs after emitting "(Engines Of Creation) loaded." output is:
ocp: exit
arch: exit
Linux version 2.6.14hcu3 (buildslave@domain.hid) (gcc version 3.4.4) #17 Tue May 16
19:24:07 CEST 2006
HCU3 Netstal Maschinen AG with U-Boot 1.1.2.
Built 1 zonelists
Kernel command line: console=ttyS0,9600 root=/dev/nfs rw
nfsroot=172.25.1.58:/home/hcu/rootfs ip=172.25.1.5:172.15.1.58:::hcu4::off
panic=30
PID hash table entries: 256 (order: 8, 4096 bytes)
I-pipe 1.3-02: pipeline enabled.
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 29756k available (1856k kernel code, 604k data, 100k init, 0k
highmem)
Mount-cache hash table entries: 512
softlockup thread 0 started up.
NET: Registered protocol family 16

TIMER IRQ is 32
I-pipe: Domain Xenomai registered.
Xenomai: hal/powerpc started.
Xenomai: real-time nucleus v2.2-rc1 (Engines Of Creation) loaded.

I have no ideas why, as my PowerBook is running fine with an actual Xenomai
based kernel. But I now that the timer architecture for the PPC40x family
is quite different to the PPC en general.

Any ideas where to begin debugging? I am familiar whith the timer/interrupt
architecture of the PPC405 but a hint would be welcome. I will take my BDI
debugger from Abatron home to have a look where the processor hangs, but
will not have time till tomorrow or Wednesday to dig into this problem.

Best regards

Niklaus Giger

Re: [Xenomai-core] Re: Xenomai v2.2-rc2. PowerPC 405GPr board does not start up

[Philippe Gerum]

Niklaus Giger wrote:
> Hi everybody
> 
> Philippe Gerum wrote:
> 
>>Here is the second release candidate for the v2.2 branch. Short log
>>follows:
> 
> Sorry for reporting so late.
> 
> But as my tests did not yet include starting up my board I did not notice
> that changes (probably between 2006-05-10 19:30 and 2006-05-11 20:31) made
> my board unbootable. 
> 
> The board hangs after emitting "(Engines Of Creation) loaded." output is:
> ocp: exit
> arch: exit
> Linux version 2.6.14hcu3 (buildslave@domain.hid) (gcc version 3.4.4) #17 Tue May 16
> 19:24:07 CEST 2006
> HCU3 Netstal Maschinen AG with U-Boot 1.1.2.
> Built 1 zonelists
> Kernel command line: console=ttyS0,9600 root=/dev/nfs rw
> nfsroot=172.25.1.58:/home/hcu/rootfs ip=172.25.1.5:172.15.1.58:::hcu4::off
> panic=30
> PID hash table entries: 256 (order: 8, 4096 bytes)
> I-pipe 1.3-02: pipeline enabled.
> Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
> Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
> Memory: 29756k available (1856k kernel code, 604k data, 100k init, 0k
> highmem)
> Mount-cache hash table entries: 512
> softlockup thread 0 started up.
> NET: Registered protocol family 16
> 
> TIMER IRQ is 32
> I-pipe: Domain Xenomai registered.
> Xenomai: hal/powerpc started.
> Xenomai: real-time nucleus v2.2-rc1 (Engines Of Creation) loaded.
> 
> I have no ideas why, as my PowerBook is running fine with an actual Xenomai
> based kernel. But I now that the timer architecture for the PPC40x family
> is quite different to the PPC en general.
> 
> Any ideas where to begin debugging? I am familiar whith the timer/interrupt
> architecture of the PPC405 but a hint would be welcome. I will take my BDI
> debugger from Abatron home to have a look where the processor hangs, but
> will not have time till tomorrow or Wednesday to dig into this problem.

Could you try building all skins as modules with only the nucleus
statically built into the kernel? I'd like to know whether the lockup
occurs when one of the skin attempts to initialize, or if the problem is
in the early Xenomai bootstrap. TIA,

-- 

Philippe.

Re: [Xenomai-core] Re: Xenomai v2.2-rc2. PowerPC 405GPr board does not start up

[Niklaus Giger]

Am Montag, 22. Mai 2006 17:40 schrieb Philippe Gerum:
> Niklaus Giger wrote:
> > Hi everybody
> >
> > Philippe Gerum wrote:
> >>Here is the second release candidate for the v2.2 branch. Short log
> >>follows:
<...>
> Could you try building all skins as modules with only the nucleus
> statically built into the kernel? I'd like to know whether the lockup
> occurs when one of the skin attempts to initialize, or if the problem is
> in the early Xenomai bootstrap. TIA,
Okay. With the following .config XENOMAI settings my target starts up without 
any problem till the login:

CONFIG_XENOMAI=y
CONFIG_XENO_OPT_NUCLEUS=y
CONFIG_XENO_OPT_PERVASIVE=y
CONFIG_XENO_OPT_SECURITY_ACCESS=y
CONFIG_XENO_OPT_REGISTRY=y
CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512
CONFIG_XENO_OPT_SYS_HEAPSZ=128
# CONFIG_XENO_OPT_ISHIELD is not set
CONFIG_XENO_OPT_PIPELINE_HEAD=y
CONFIG_XENO_OPT_STATS=y
# CONFIG_XENO_OPT_DEBUG is not set
CONFIG_XENO_OPT_WATCHDOG=y
CONFIG_XENO_OPT_TIMING_PERIODIC=y
CONFIG_XENO_OPT_TIMING_PERIOD=1000000
CONFIG_XENO_OPT_TIMING_TIMERLAT=0
CONFIG_XENO_OPT_TIMING_SCHEDLAT=0
# CONFIG_XENO_OPT_SCALABLE_SCHED is not set
CONFIG_XENO_OPT_TIMER_LIST=y
# CONFIG_XENO_OPT_TIMER_HEAP is not set
# CONFIG_XENO_OPT_SHIRQ_LEVEL is not set
# CONFIG_XENO_OPT_SHIRQ_EDGE is not set
# CONFIG_XENO_HW_FPU is not set
CONFIG_XENO_SKIN_NATIVE=m
# CONFIG_XENO_OPT_NATIVE_PIPE is not set
CONFIG_XENO_OPT_NATIVE_REGISTRY=y
CONFIG_XENO_OPT_NATIVE_SEM=y
CONFIG_XENO_OPT_NATIVE_EVENT=y
CONFIG_XENO_OPT_NATIVE_MUTEX=y
CONFIG_XENO_OPT_NATIVE_COND=y
CONFIG_XENO_OPT_NATIVE_QUEUE=y
CONFIG_XENO_OPT_NATIVE_HEAP=y
CONFIG_XENO_OPT_NATIVE_ALARM=y
CONFIG_XENO_OPT_NATIVE_MPS=y
CONFIG_XENO_OPT_NATIVE_INTR=y
CONFIG_XENO_SKIN_POSIX=m
# CONFIG_XENO_SKIN_PSOS is not set
# CONFIG_XENO_SKIN_UITRON is not set
# CONFIG_XENO_SKIN_VRTX is not set
CONFIG_XENO_SKIN_VXWORKS=m
CONFIG_XENO_SKIN_RTAI=m
CONFIG_XENO_OPT_RTAI_SEM=y
CONFIG_XENO_OPT_RTAI_SHM=y
CONFIG_XENO_SKIN_RTDM=m
CONFIG_XENO_OPT_RTDM_FILDES=128
CONFIG_XENO_SKIN_UVM=m
# CONFIG_XENO_DRIVERS_16550A is not set
CONFIG_XENO_DRIVERS_TIMERBENCH=m

Diff to my old .config is:
4c4
< # Mon May 22 18:02:59 2006
---
> # Sun May 21 00:23:12 2006
74a75,76
> CONFIG_XENO_OPT_PIPE=y
> CONFIG_XENO_OPT_PIPE_NRDEV=32
113,114c115,117
< CONFIG_XENO_SKIN_NATIVE=m
< # CONFIG_XENO_OPT_NATIVE_PIPE is not set
---
> CONFIG_XENO_SKIN_NATIVE=y
> CONFIG_XENO_OPT_NATIVE_PIPE=y
> CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=4096
125c128
< CONFIG_XENO_SKIN_POSIX=m
---
> CONFIG_XENO_SKIN_POSIX=y
129,133c132,137
< CONFIG_XENO_SKIN_VXWORKS=m
< CONFIG_XENO_SKIN_RTAI=m
< CONFIG_XENO_OPT_RTAI_SEM=y
< CONFIG_XENO_OPT_RTAI_SHM=y
< CONFIG_XENO_SKIN_RTDM=m
---
> CONFIG_XENO_SKIN_VXWORKS=y
>
> #
> # RTAI emulator unavailable, disable native API or build it as module
> #
> CONFIG_XENO_SKIN_RTDM=y
135c139
< CONFIG_XENO_SKIN_UVM=m
---
> CONFIG_XENO_SKIN_UVM=y
141c145
< CONFIG_XENO_DRIVERS_TIMERBENCH=m
---
> CONFIG_XENO_DRIVERS_TIMERBENCH=y

Thanks a lot for your help
-- 
Niklaus Giger

Re: [Xenomai-core] Re: Xenomai v2.2-rc2. PowerPC 405GPr board does not start up

[Philippe Gerum]

Niklaus Giger wrote:
> Am Montag, 22. Mai 2006 17:40 schrieb Philippe Gerum:
> 
>>Niklaus Giger wrote:
>>
>>>Hi everybody
>>>
>>>Philippe Gerum wrote:
>>>
>>>>Here is the second release candidate for the v2.2 branch. Short log
>>>>follows:
> 
> <...>
> 
>>Could you try building all skins as modules with only the nucleus
>>statically built into the kernel? I'd like to know whether the lockup
>>occurs when one of the skin attempts to initialize, or if the problem is
>>in the early Xenomai bootstrap. TIA,
> 
> Okay. With the following .config XENOMAI settings my target starts up without 
> any problem till the login:
>

Does the board still boot with only the native skin enabled statically? 
If it does not, wild guess: does the following patch prevent the lockup 
in the latter case?

--- pod.c~	2006-05-15 15:03:52.000000000 +0200
+++ pod.c	2006-05-22 18:45:21.000000000 +0200
@@ -509,12 +509,14 @@

      xnarch_notify_ready();

+#if 0
      err = xnpod_reset_timer();

      if (err) {
          xnpod_shutdown(XNPOD_FATAL_EXIT);
          return err;
      }
+#endif

      return 0;
  }

-- 

Philippe.

Re: [Xenomai-core] Re: Xenomai v2.2-rc2. PowerPC 405GPr board does not start up

[Niklaus Giger]

Hi

Am Montag, 22. Mai 2006 18:47 schrieb Philippe Gerum:
> Niklaus Giger wrote:
> > Am Montag, 22. Mai 2006 17:40 schrieb Philippe Gerum:
> >>Niklaus Giger wrote:
> >>>Hi everybody
> >>>
> >>>Philippe Gerum wrote:
> >>>>Here is the second release candidate for the v2.2 branch. Short log
> >>>>follows:
> >
> > <...>
> >
> >>Could you try building all skins as modules with only the nucleus
> >>statically built into the kernel? I'd like to know whether the lockup
> >>occurs when one of the skin attempts to initialize, or if the problem is
> >>in the early Xenomai bootstrap. TIA,
> >
> > Okay. With the following .config XENOMAI settings my target starts up
> > without any problem till the login:
>
> Does the board still boot with only the native skin enabled statically?
No. It does not.
> If it does not, wild guess: does the following patch prevent the lockup
> in the latter case?
>
> --- pod.c~	2006-05-15 15:03:52.000000000 +0200
> +++ pod.c	2006-05-22 18:45:21.000000000 +0200
> @@ -509,12 +509,14 @@
>
>       xnarch_notify_ready();
>
> +#if 0
>       err = xnpod_reset_timer();
>
>       if (err) {
>           xnpod_shutdown(XNPOD_FATAL_EXIT);
>           return err;
>       }
> +#endif
>
>       return 0;
>   }
Excellent wild guess! With this patch I get my target up and running. First 
test is with only the native skin worked. Then I restore my original .config, 
touched it and rebuilt. Still boots without any problems.

Thanks a lot for your help.

Best regards

-- 
Niklaus Giger

Re: [Xenomai-core] Re: Xenomai v2.2-rc2. PowerPC 405GPr board does not start up

[Philippe Gerum]

Niklaus Giger wrote:
> Hi
> 
> Am Montag, 22. Mai 2006 18:47 schrieb Philippe Gerum:
> 
>>Niklaus Giger wrote:
>>
>>>Am Montag, 22. Mai 2006 17:40 schrieb Philippe Gerum:
>>>
>>>>Niklaus Giger wrote:
>>>>
>>>>>Hi everybody
>>>>>
>>>>>Philippe Gerum wrote:
>>>>>
>>>>>>Here is the second release candidate for the v2.2 branch. Short log
>>>>>>follows:
>>>
>>><...>
>>>
>>>>Could you try building all skins as modules with only the nucleus
>>>>statically built into the kernel? I'd like to know whether the lockup
>>>>occurs when one of the skin attempts to initialize, or if the problem is
>>>>in the early Xenomai bootstrap. TIA,
>>>
>>>Okay. With the following .config XENOMAI settings my target starts up
>>>without any problem till the login:
>>
>>Does the board still boot with only the native skin enabled statically?
> 
> No. It does not.
> 
>>If it does not, wild guess: does the following patch prevent the lockup
>>in the latter case?
>>
>>--- pod.c~	2006-05-15 15:03:52.000000000 +0200
>>+++ pod.c	2006-05-22 18:45:21.000000000 +0200
>>@@ -509,12 +509,14 @@
>>
>>      xnarch_notify_ready();
>>
>>+#if 0
>>      err = xnpod_reset_timer();
>>
>>      if (err) {
>>          xnpod_shutdown(XNPOD_FATAL_EXIT);
>>          return err;
>>      }
>>+#endif
>>
>>      return 0;
>>  }
> 
> Excellent wild guess! With this patch I get my target up and running. First 
> test is with only the native skin worked. Then I restore my original .config, 
> touched it and rebuilt. Still boots without any problems.
>

Ok, relatively good news. Now I need to find why starting the timer 
early breaks the system...

> Thanks a lot for your help.
> 
> Best regards
> 


-- 

Philippe.

Re: [Xenomai-core] Re: Xenomai v2.2-rc2. PowerPC 405GPr board does not start up

[Niklaus Giger]

Am Montag, 22. Mai 2006 23:31 schrieb Philippe Gerum:
> Niklaus Giger wrote:
<..>
>
> Ok, relatively good news. Now I need to find why starting the timer
> early breaks the system...
>
I do not know whether this is related to our problem.

I started to adapt xeno-test to my busybox environment. I used the kernel with 
only native built-in and all others as modules. Then I discovered that 
running manually latency on a freshly booted system gets the following 
segmentation fault.
Here the relevant output 
/usr/xenomai/testsuite/latency # mount -a
/usr/xenomai/testsuite/latency # modprobe xeno_native
/usr/xenomai/testsuite/latency # modprobe xeno_rtdm
/usr/xenomai/testsuite/latency # modprobe xeno_timerbench
/usr/xenomai/testsuite/latency # lsmod
Module                  Size  Used by    Not tainted
xeno_timerbench 7460 0 - Live 0xc3030000
xeno_rtdm 27412 1 xeno_timerbench, Live 0xc3091000
xeno_native 84780 0 - Live 0xc3130000
/usr/xenomai/testsuite/latency # ./latency
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microsecondOops: kernel access of bad area, sig: 11 [#1]
NIP: C001C5EC LR: C004CEA8 SP: C19ABDB0 REGS: c19abd00 TRAP: 0300    Not 
tainted
MSR: 00029030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 0000000C, DSISR: 00000000
TASK = c198f830[36] 'display-34' THREAD: c19aa000
Last syscall: 50332203
GPR00: 00000000 C19ABDB0 C198F830 00000000 00000001 00000062 00000000 00000000
GPR08: 04FB0D6D C01FF720 00000001 C020AF40 000009F3 1001EA64 01FFBC00 007FFF77
GPR16: 00000000 00000001 FFFFFFFF 00000000 C19ABF50 C020AF40 00000000 C01E0000
GPR24: C01E0000 00000001 00000000 00000062 00000001 C01E0000 00000000 00000000
NIP [c001c5ec] ipipe_reenter_root+0x30/0xe8
LR [c004cea8] xnshadow_relax+0x11c/0x18c
Call trace:
 [c004cea8] xnshadow_relax+0x11c/0x18c
 [c0047a88] xnpod_fault_handler+0x8c/0xf0
 [c004892c] xnpod_trap_fault+0x64/0x7c
 [c00432cc] xnarch_trap_fault+0x1c/0x2c
 [c0117b84] exception_event+0x6c/0x7c
 [c003fbec] __ipipe_dispatch_event+0xf0/0x158
 [c000aecc] do_page_fault+0x50/0x52c
 [c0003258] handle_page_fault+0xc/0x80
s
Segmentation fault

Best regards

-- 
Niklaus Giger

Re: [Xenomai-core] Xenomai v2.2-rc2

[Niklaus Giger]

Am Montag, 22. Mai 2006 13:38 schrieb Gilles Chanteperdrix:
> Niklaus Giger wrote:
>  > Am Samstag, 20. Mai 2006 23:07 schrieb Philippe Gerum:
>  > > Here is the second release candidate for the v2.2 branch. Short log
>  >
>  > The trunks builds fine on my four targets on
>  > http://ngiger.dyndns.org/buildbot/
>  >
>  > I have however still the following errors running the posix simulators
>  > (see http://ngiger.dyndns.org/buildbot/sim/builds/59/step-check_sim/0).
>  > All others posix and vxworks test pass.
>  > The output is:
>
> The tested feature is round-robin scheduling, which only works when the
> system timer is configured in periodic mode; so, when the system timer
> is configured in periodic mode, the test should pass.
Where does the simulator get this configuration from? Can it be changed to run 
tests in periodic and aperiodic mode? 

Would  the test be adapedt to emit a "skipping: periodic mode not configured" 
if it is not properly configured?

Best regards

-- 
Niklaus Giger

Re: [Xenomai-core] Xenomai v2.2-rc2

[Hannes Mayer]

Hi all!

I'm back :-)
After some "time on Mars" (http://www.austromars.at) and some
vaccation, here are my test results:

kernel 2.4.32
Xeno2.2rc2

=> testsuite works
=> RTDM Driver Skeleton works

Best regards,
Hannes.

Re: [Xenomai-core] Xenomai v2.2-rc2

[Gilles Chanteperdrix]

Niklaus Giger wrote:
 > Am Montag, 22. Mai 2006 13:38 schrieb Gilles Chanteperdrix:
 > > Niklaus Giger wrote:
 > >  > Am Samstag, 20. Mai 2006 23:07 schrieb Philippe Gerum:
 > >  > > Here is the second release candidate for the v2.2 branch. Short log
 > >  >
 > >  > The trunks builds fine on my four targets on
 > >  > http://ngiger.dyndns.org/buildbot/
 > >  >
 > >  > I have however still the following errors running the posix simulators
 > >  > (see http://ngiger.dyndns.org/buildbot/sim/builds/59/step-check_sim/0).
 > >  > All others posix and vxworks test pass.
 > >  > The output is:
 > >
 > > The tested feature is round-robin scheduling, which only works when the
 > > system timer is configured in periodic mode; so, when the system timer
 > > is configured in periodic mode, the test should pass.
 > Where does the simulator get this configuration from? Can it be changed to run 
 > tests in periodic and aperiodic mode? 

The nucleus look for the parameter "tick_arg". Over kernel-space, this
parameter is a module parameter; over simulator, this parameter is an
environment variable. So, running: 
tick_arg=10000000 ./tthread
should make the test run.

 > 
 > Would  the test be adapedt to emit a "skipping: periodic mode not configured" 
 > if it is not properly configured?

An example of bit decay. This test used to be skipped over non periodic mode.

Now, it is repaired.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] Xenomai v2.2-rc2

[Niklaus Giger]

Am Freitag, 26. Mai 2006 18:27 schrieb Gilles Chanteperdrix:
> Niklaus Giger wrote:
<..>
>  > Where does the simulator get this configuration from? Can it be changed
>  > to run tests in periodic and aperiodic mode?
>
> The nucleus look for the parameter "tick_arg". Over kernel-space, this
> parameter is a module parameter; over simulator, this parameter is an
> environment variable. So, running:
> tick_arg=10000000 ./tthread
> should make the test run.
Thanks for your explanation. I will try to integrate this in the test suite.
>
>  > Would  the test be adapedt to emit a "skipping: periodic mode not
>  > configured" if it is not properly configured?
>
> An example of bit decay. This test used to be skipped over non periodic
> mode.
That is exactly the point why I try to run the buildbot. Automatic regression 
tests should catch these kind of errors.
>
> Now, it is repaired.
Thanks a lot. Such quick fixes motivate me to continue my work.

But I get now in 
http://ngiger.dyndns.org/buildbot/sim/builds/60/step-check_sim/0
the following error:
Some problems were reported in:
posix->tthread:: tthread.c:91 pthread_join(child1, &tmp) == ESRCH
tthread.c:91 pthread_join(child1, &tmp) == ESRCH

Running libtool --mode=execute gdb ./tthread I can give you the following call 
stack:
tthread.c:89 TEST passed.
tthread.c:91 pthread_join(child1, &tmp) == ESRCH

Program received signal SIGSEGV, Segmentation fault.
0x1000e81c in pse51_thread_join (thread=0x6061ff71, value_ptr=0x100f9f00) 
at ../../../ksrc/skins/posix/thread.c:409
409         if (!pse51_obj_active(thread, PSE51_THREAD_MAGIC, struct 
pse51_thread)
(gdb) info stack
#0  0x1000e81c in pse51_thread_join (thread=0x6061ff71, value_ptr=0x100f9f00) 
at ../../../ksrc/skins/posix/thread.c:409
#1  0x10006734 in root_thread (cookie=0x0) at tthread.c:91
#2  0x1000d728 in thread_trampoline (cookie=0x100d1838) 
at ../../../ksrc/skins/posix/thread.c:56
#3  0x10050f78 in mvm_thread_trampoline_kroot_ ()
#4  0x0ffd10b4 in XenoThread::trampoline_kroot_ () 
from /home/buildslave/buildbot/quick-sim/build/sim/vm/.libs/libmvm.so.2
#5  0x0ffd1150 in XenoThread::body () 
from /home/buildslave/buildbot/quick-sim/build/sim/vm/.libs/libmvm.so.2
#6  0x0ffd2c58 in MvmThread::life () 
from /home/buildslave/buildbot/quick-sim/build/sim/vm/.libs/libmvm.so.2
#7  0x0fba6ad0 in makecontext () from /lib/tls/libc.so.6
Previous frame inner to this frame (corrupt stack?)
(gdb)                                                

Do you have any clue? (Doubling the stack in vm/thread.cc didn't help.)

Best regards

-- 
Niklaus Giger

Re: [Xenomai-core] Xenomai v2.2-rc2

[Gilles Chanteperdrix]

Niklaus Giger wrote:
 > Do you have any clue? (Doubling the stack in vm/thread.cc didn't help.)

Automatic re-building does not work for the simulator. So, in case of
segmentation fault, try:

make clean all check

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] Xenomai v2.2-rc2

[Niklaus Giger]

Am Freitag, 26. Mai 2006 19:49 schrieb Gilles Chanteperdrix:
> Niklaus Giger wrote:
>  > Do you have any clue? (Doubling the stack in vm/thread.cc didn't help.)
>
> Automatic re-building does not work for the simulator. So, in case of
> segmentation fault, try:
>
> make clean all check
Yes, I noticed this as I was looking for a compile of thread.cc. Therefore I 
did a clean rebuild (but a little bit different than your receipt). After 
rebuilding using "make clean all check" under sim and 
sim/skin/posix/testsuite, I still get the same failure.

Regards
-- 
Niklaus Giger

Re: [Xenomai-core] Xenomai v2.2-rc2

[Gilles Chanteperdrix]

Niklaus Giger wrote:
 > posix->tthread:: tthread.c:91 pthread_join(child1, &tmp) == ESRCH
 > tthread.c:91 pthread_join(child1, &tmp) == ESRCH
 > 
 > Running libtool --mode=execute gdb ./tthread I can give you the following call 
 > stack:
 > tthread.c:89 TEST passed.
 > tthread.c:91 pthread_join(child1, &tmp) == ESRCH
 > 
 > Program received signal SIGSEGV, Segmentation fault.
 > 0x1000e81c in pse51_thread_join (thread=0x6061ff71, value_ptr=0x100f9f00) 
 > at ../../../ksrc/skins/posix/thread.c:409
 > 409         if (!pse51_obj_active(thread, PSE51_THREAD_MAGIC, struct 
 > pse51_thread)
 > (gdb) info stack
 > #0  0x1000e81c in pse51_thread_join (thread=0x6061ff71, value_ptr=0x100f9f00) 
 > at ../../../ksrc/skins/posix/thread.c:409
 > #1  0x10006734 in root_thread (cookie=0x0) at tthread.c:91
 > #2  0x1000d728 in thread_trampoline (cookie=0x100d1838) 
 > at ../../../ksrc/skins/posix/thread.c:56
 > #3  0x10050f78 in mvm_thread_trampoline_kroot_ ()
 > #4  0x0ffd10b4 in XenoThread::trampoline_kroot_ () 
 > from /home/buildslave/buildbot/quick-sim/build/sim/vm/.libs/libmvm.so.2
 > #5  0x0ffd1150 in XenoThread::body () 
 > from /home/buildslave/buildbot/quick-sim/build/sim/vm/.libs/libmvm.so.2
 > #6  0x0ffd2c58 in MvmThread::life () 
 > from /home/buildslave/buildbot/quick-sim/build/sim/vm/.libs/libmvm.so.2
 > #7  0x0fba6ad0 in makecontext () from /lib/tls/libc.so.6
 > Previous frame inner to this frame (corrupt stack?)
 > (gdb)                                                
 > 
 > Do you have any clue? (Doubling the stack in vm/thread.cc didn't help.)

This test is really questionable, it tests that pthread_join returns
ESRCH when passed a pthread_t argument that is not yet initialized. But
if the not yet initialized pthread_t value is an invalid address, it
may cause a segmentation fault. The best thing to do is to remove this
test.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] Xenomai v2.2-rc2

[Philippe Gerum]

Niklaus Giger wrote:
> Am Samstag, 20. Mai 2006 23:07 schrieb Philippe Gerum:
> 
>>Here is the second release candidate for the v2.2 branch. Short log
>>follows:
> 
> Could you please apply the patch below to make xeno-test send e-mails to 
> xenomai-data@domain.hid.
> 
> I am unsure whether setting sentby='xenotest.sender@domain.hid' is a good 
> idea. Or is this a way to accept e-mails from unkown senders? In any way I 
> think it would be nice if one could accept xeno-test messages from 
> unsubscribed senders.
> 
> I really would like to collect some real data.
> 

Applied, thanks.

> Thanks in advance.
> 
> Niklaus Giger
> 
> Index: scripts/xeno-test.in
> ===================================================================
> --- scripts/xeno-test.in        (Revision 1135)
> +++ scripts/xeno-test.in        (Arbeitskopie)
> @@ -19,7 +19,7 @@
>                 name can be full or relative pathname
>    -v           verbose
>    -M <email>   sends output to given addr
> -  -m           sends output to xenotest.output@domain.hid
> +  -m           sends output to xenomai-data@domain.hid
>    -U <url>     uploads output to given URL
> 
>    # following options are passed thru to latency
> @@ -167,7 +167,7 @@
>  logprefix=/tmp/        # someplace usually there
>  prepost=       # command to run pre, and post test (ex ntpq -p)
> 
> -email='xenotest.output@domain.hid'      # until formalized
> +email='xenomai-data@domain.hid'
>  sentby='xenotest.sender@domain.hid'
>  url=
>  sendit=                # send it by m-mail, u-url
> 


-- 

Philippe.

Re: [Xenomai-core] Re: Xenomai v2.2-rc2. PowerPC 405GPr board does not start up

[Niklaus Giger]

Hi Philippe

I redid my testing wit revision 1188 (+ modification from me for the 
xeno-test). 

The lockup at startup is still there if CONFIG_XENO_OPT_TIMING_PERIOD !=  0 
and if the skins native, posix, rtdm, uvm and skins skins are compiled in.
Timing settings was always CONFIG_XENO_OPT_TIMING_PERIODIC=y.

Linux version 2.6.14-1188M-hcu3 (root@domain.hid) (gcc version 3.4.4) #4 Sun Jun 11 
19:45:36 CEST 2006
HCU3 Netstal Maschinen AG with U-Boot 1.1.2.
Built 1 zonelists
Kernel command line: console=ttyS0,9600 root=/dev/nfs rw 
nfsroot=172.25.1.58:/home/hcu/rootfs ip=172.25.1.5:172.15.1.58:::hcu4::off 
panic=30
PID hash table entries: 256 (order: 8, 4096 bytes)
I-pipe 1.3-03: pipeline enabled.
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 29884k available (1740k kernel code, 608k data, 92k init, 0k highmem)
Mount-cache hash table entries: 512
softlockup thread 0 started up.
NET: Registered protocol family 16

I-pipe: Domain Xenomai registered.
Xenomai: hal/powerpc started.
Xenomai: real-time nucleus v2.2-rc2 (Engines Of Creation) loaded.
Xenomai: starting native API services.
Xenomai: starting POSIX services.
Xenomai: starting RTDM services.
Xenomai: starting UVM services.
Xenomai: incompatible timer mode (aperiodic found, need periodic).
Xenomai: VxWorks skin init failed, code -16.
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
<..>

Best regards 

-- 
Niklaus Giger

Re: [Xenomai-core] Re: Xenomai v2.2-rc2. PowerPC 405GPr board does not start up

[Philippe Gerum]

Niklaus Giger wrote:
> Hi Philippe
> 
> I redid my testing wit revision 1188 (+ modification from me for the 
> xeno-test). 
> 
> The lockup at startup is still there if CONFIG_XENO_OPT_TIMING_PERIOD !=  0 
> and if the skins native, posix, rtdm, uvm and skins skins are compiled in.
> Timing settings was always CONFIG_XENO_OPT_TIMING_PERIODIC=y.
> 
> Linux version 2.6.14-1188M-hcu3 (root@domain.hid) (gcc version 3.4.4) #4 Sun Jun 11 
> 19:45:36 CEST 2006
> HCU3 Netstal Maschinen AG with U-Boot 1.1.2.
> Built 1 zonelists
> Kernel command line: console=ttyS0,9600 root=/dev/nfs rw 
> nfsroot=172.25.1.58:/home/hcu/rootfs ip=172.25.1.5:172.15.1.58:::hcu4::off 
> panic=30
> PID hash table entries: 256 (order: 8, 4096 bytes)
> I-pipe 1.3-03: pipeline enabled.
> Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
> Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
> Memory: 29884k available (1740k kernel code, 608k data, 92k init, 0k highmem)
> Mount-cache hash table entries: 512
> softlockup thread 0 started up.
> NET: Registered protocol family 16
> 
> I-pipe: Domain Xenomai registered.
> Xenomai: hal/powerpc started.
> Xenomai: real-time nucleus v2.2-rc2 (Engines Of Creation) loaded.
> Xenomai: starting native API services.
> Xenomai: starting POSIX services.
> Xenomai: starting RTDM services.
> Xenomai: starting UVM services.
> Xenomai: incompatible timer mode (aperiodic found, need periodic).
> Xenomai: VxWorks skin init failed, code -16.

This error (-EBUSY) is expected, since native, posix and uvm need 
aperiodic setup and vxworks wants periodic. Since all are built-ins and 
initialize immediately during the kernel boot up, a conflict arises.

I initially thought reading your post about the issue a few weeks ago 
that a lockup would occur even with:

CONFIG_XENO_SKIN_NATIVE=y
CONFIG_XENO_OPT_TIMING_PERIODIC=y
# CONFIG_XENO_SKIN_POSIX is unset
# CONFIG_XENO_SKIN_UVM is unset
# CONFIG_XENO_SKIN_VXWORKS is unset
# CONFIG_XENO_SKIN_PSOS is unset
# CONFIG_XENO_SKIN_VRTX is unset
# CONFIG_XENO_SKIN_UITRON is unset

but would not with:

CONFIG_XENO_SKIN_NATIVE=m
CONFIG_XENO_OPT_TIMING_PERIODIC=y
# CONFIG_XENO_SKIN_POSIX is unset
# CONFIG_XENO_SKIN_UVM is unset
# CONFIG_XENO_SKIN_VXWORKS is unset
# CONFIG_XENO_SKIN_PSOS is unset
# CONFIG_XENO_SKIN_VRTX is unset
# CONFIG_XENO_SKIN_UITRON is unset

Is it the case, or is the VxWorks skin always involved when the lockup 
occurs?

> Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
> <..>
> 
> Best regards 
> 


-- 

Philippe.