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

2006-06-11 Thread 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 ([EMAIL PROTECTED]) (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

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


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

2006-05-23 Thread 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 byNot tainted
xeno_timerbench 7460 0 - Live 0xc303
xeno_rtdm 27412 1 xeno_timerbench, Live 0xc3091000
xeno_native 84780 0 - Live 0xc313
/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: 0300Not 
tainted
MSR: 00029030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 000C, DSISR: 
TASK = c198f830[36] 'display-34' THREAD: c19aa000
Last syscall: 50332203
GPR00:  C19ABDB0 C198F830  0001 0062  
GPR08: 04FB0D6D C01FF720 0001 C020AF40 09F3 1001EA64 01FFBC00 007FFF77
GPR16:  0001   C19ABF50 C020AF40  C01E
GPR24: C01E 0001  0062 0001 C01E  
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

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


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

2006-05-22 Thread 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 ([EMAIL PROTECTED]) (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.


___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


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

2006-05-22 Thread 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=100
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

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


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

2006-05-22 Thread 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.0 +0200
+++ pod.c   2006-05-22 18:45:21.0 +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.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


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

2006-05-22 Thread 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.0 +0200
 +++ pod.c 2006-05-22 18:45:21.0 +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

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core


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

2006-05-22 Thread 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.0 +0200
+++ pod.c   2006-05-22 18:45:21.0 +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.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core