[Xenomai] Xenomai installation on P1020RDB

[Xenomai] Xenomai installation on P1020RDB

[Lukasz Zemla]

Hello,

Has anyone some experience with installing Xenomai on P1020RDB board? I'd like to perform some benchmarks on this board.
I'm trying to install it using the latest Freescale SDK 1.2 based on Yocto. But hints for SDK 1.0.3 would be also fine. Finally every way for getting it working... ;-)

What I'm doing is getting Freescale kernel (3.0.34):
               bitbake -c unpack virtual/kernel
and then trying manually to run prepare-kernel.sh pointing to directory where sources where unpacked. I tried all i-pipe 3.x patches - but all of them returned error.

Is it true that i-pipe can be applied _only_ to the _vanilla_ kernel with version which _exactly_ matches i-pipe patch version?

Next I tried to install Xenomai on vanilla 3.1.10 kernel. I got compilation error:

        arch/powerpc/sysdev/fsl_lbc.c: In function 'fsl_lbc_ctrl_irq':
        arch/powerpc/sysdev/fsl_lbc.c:247:3: error: 'TASK_NORMAL' undeclared (first use in this function)


I fixed it by adding '#include <linux/sched.h>' in arch/powerpc/sysdev/fsl_lbc.c file. After successful build the kernel hung just after loading DTB.



Filename 'p1020rdb-pc.dtb'.

Load address: 0xc00000

Loading: ###

done

Bytes transferred = 12888 (3258 hex)

WARNING: adjusting available memory to 30000000

## Booting kernel from Legacy Image at 01000000 ...

   Image Name:   Linux-3.1.10

   Created:      2012-07-20  13:54:54 UTC

   Image Type:   PowerPC Linux Kernel Image (gzip compressed)

   Data Size:    3757211 Bytes = 3.6 MiB

   Load Address: 00000000

   Entry Point:  00000000

   Verifying Checksum ... OK

## Loading init Ramdisk from Legacy Image at 02000000 ...

   Image Name:   fsl-image-minimal-ww-p1020rdb-20

   Created:      2012-07-18   9:30:13 UTC

   Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)

   Data Size:    4596585 Bytes = 4.4 MiB

   Load Address: 00000000

   Entry Point:  00000000

   Verifying Checksum ... OK

## Flattened Device Tree blob at 00c00000

   Booting using the fdt blob at 0xc00000

   Uncompressing Kernel Image ... OK

   Loading Ramdisk to 2fb9d000, end 2ffff369 ... OK

   Loading Device Tree to 00ff9000, end 00fff257 ... OK


Thank you in advance for any hints.

Pozdrawiam / Best Regards / Mit freundlichen Grüßen
Łukasz Zemła



***
The information in this email is confidential and intended solely for the individual or entity to whom it is addressed. If you have received this email in error please notify the sender by return e-mail, delete this email, and refrain from any disclosure or action based on the information.
***

Re: [Xenomai] Xenomai installation on P1020RDB

[Wolfgang Grandegger]

Hi Lukasz,

On 07/20/2012 04:31 PM, Lukasz Zemla wrote:
> Hello,
> 
> Has anyone some experience with installing Xenomai on P1020RDB board? I'd like to perform some benchmarks on this board.
> I'm trying to install it using the latest Freescale SDK 1.2 based on Yocto. But hints for SDK 1.0.3 would be also fine. Finally every way for getting it working... ;-)
> 
> What I'm doing is getting Freescale kernel (3.0.34):

If you can, use a *mainline* kernel. The latest Xenomai patch is for
Linux 3.2.21 and that version does well support the P1020RDB, IIRC.

>                bitbake -c unpack virtual/kernel
> and then trying manually to run prepare-kernel.sh pointing to directory where sources where unpacked. I tried all i-pipe 3.x patches - but all of them returned error.
> 
> Is it true that i-pipe can be applied _only_ to the _vanilla_ kernel with version which _exactly_ matches i-pipe patch version?

If you are lucky it will apply to other (rather close) versions as
well, but it is no surprise if it fails. 

> Next I tried to install Xenomai on vanilla 3.1.10 kernel. I got compilation error:
> 
>         arch/powerpc/sysdev/fsl_lbc.c: In function 'fsl_lbc_ctrl_irq':
>         arch/powerpc/sysdev/fsl_lbc.c:247:3: error: 'TASK_NORMAL' undeclared (first use in this function)

That has nothing to do with Xenomai. Did you try to build the vanilla
kernel first?

> I fixed it by adding '#include <linux/sched.h>' in arch/powerpc/sysdev/fsl_lbc.c file. After successful build the kernel hung just after loading DTB.
> 
> 
> 
> Filename 'p1020rdb-pc.dtb'.
> 
> Load address: 0xc00000
> 
> Loading: ###
> 
> done
> 
> Bytes transferred = 12888 (3258 hex)
> 
> WARNING: adjusting available memory to 30000000
> 
> ## Booting kernel from Legacy Image at 01000000 ...
> 
>    Image Name:   Linux-3.1.10
> 
>    Created:      2012-07-20  13:54:54 UTC
> 
>    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
> 
>    Data Size:    3757211 Bytes = 3.6 MiB
> 
>    Load Address: 00000000
> 
>    Entry Point:  00000000
> 
>    Verifying Checksum ... OK
> 
> ## Loading init Ramdisk from Legacy Image at 02000000 ...
> 
>    Image Name:   fsl-image-minimal-ww-p1020rdb-20
> 
>    Created:      2012-07-18   9:30:13 UTC
> 
>    Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
> 
>    Data Size:    4596585 Bytes = 4.4 MiB
> 
>    Load Address: 00000000
> 
>    Entry Point:  00000000
> 
>    Verifying Checksum ... OK
> 
> ## Flattened Device Tree blob at 00c00000
> 
>    Booting using the fdt blob at 0xc00000
> 
>    Uncompressing Kernel Image ... OK
> 
>    Loading Ramdisk to 2fb9d000, end 2ffff369 ... OK
> 
>    Loading Device Tree to 00ff9000, end 00fff257 ... OK

This is also not related to Xenomai. Did you set the console properly?
You may be able to list the kernel log buffer after a soft-reset at
address "grep __log_buf System.map | cut -d" " -f1" - 0xc0000000
using the U-Boot command "md".

I tested Xenomai recently on a P2020 with mainline Linux 3.2.x with the
new iPipe-Patch and got very good latency results, especially with CPU
isolation: 65 us without and *8* us with CPU isolation. [I'm still puzzled
about the good results with CPU isolation. Maybe that's due to the new
iPipe-Patch. Need to re-test when time permits). I have listed the results
below.

Hope this info is useful.

Wolfgang.


Latency-Test *without* CPU isolation:
=====================================

- After 4 hours and concurrent load generation via

  # while sleep 5; do ./hackbench 50; done
  # while true; do ./calibrator 1200 256M calib.dat; done

in two separate ssh sessions I got:

  RTT|  04:15:31  (periodic user-mode task, 10000 us period, priority 99)
  RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
  RTD|     16.360|     20.640|     29.146|       0|     0|      0.666|     65.986
  RTD|     16.733|     21.093|     27.333|       0|     0|      0.666|     65.986
  ...
  ^C
  ---|-----------|-----------|-----------|--------|------|-------------------------
  RTS|      0.666|     14.493|     65.986|       0|     0|    04:15:43/04:15:43


Latency-Test *with* CPU isolation:
==================================

- Boot Linux with bootargs "isolcpus=1".

- Set smp_affinity for all interrupts:

  # echo 1 > /proc/irq/default_smp_affinity
  # for f in `ls /proc/irq/[0-9]*/smp_affinity`; do echo 1 > $f; done

- Generate load in two separate ssh sessions:

  # while sleep 5; do ./hackbench 50; done
  # while true; do ./calibrator 1200 256M calib.dat; done

- Run latency test on the second CPU:

  # cat /proc/xenomai/latency
  1986
  # latency -p10000 -c1
  ...
  RTT|  04:13:46  (periodic user-mode task, 10000 us period, priority 99)
  RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
  RTD|      0.946|      1.546|      2.280|       0|     0|      0.466|      7.386
  RTD|      1.013|      1.746|      3.053|       0|     0|      0.466|      7.386
  ...
  ^C
  ---|-----------|-----------|-----------|--------|------|-------------------------
  RTS|      0.466|      1.480|      7.386|       0|     0|    04:13:50/04:13:50

Re: [Xenomai] Xenomai installation on P1020RDB

[Richard Cochran]

On Fri, Jul 20, 2012 at 08:25:22PM +0200, Wolfgang Grandegger wrote:
> 
> I tested Xenomai recently on a P2020 with mainline Linux 3.2.x with the
> new iPipe-Patch and got very good latency results, especially with CPU
> isolation: 65 us without and *8* us with CPU isolation. [I'm still puzzled
> about the good results with CPU isolation. Maybe that's due to the new
> iPipe-Patch. Need to re-test when time permits). I have listed the results
> below.

Almost a year ago, around Linux 2.6.38 or so, I measured 13 us maximum
latency on the P2020 RBD when using CPU isolation.

Thanks,
Richard

Re: [Xenomai] Xenomai installation on P1020RDB

[Wolfgang Grandegger]

On 07/23/2012 10:48 AM, Richard Cochran wrote:
> On Fri, Jul 20, 2012 at 08:25:22PM +0200, Wolfgang Grandegger wrote:
>>
>> I tested Xenomai recently on a P2020 with mainline Linux 3.2.x with the
>> new iPipe-Patch and got very good latency results, especially with CPU
>> isolation: 65 us without and *8* us with CPU isolation. [I'm still puzzled
>> about the good results with CPU isolation. Maybe that's due to the new
>> iPipe-Patch. Need to re-test when time permits). I have listed the results
>> below.
> 
> Almost a year ago, around Linux 2.6.38 or so, I measured 13 us maximum
> latency on the P2020 RBD when using CPU isolation.

OK. Tests with FSL 2.6.35 on a P1025 showed latencies up to 40 us with
CPU isolation (an 65 us without). Similar results I measured with an ARM
i.MX6Q board.

Wolfgang.

Re: [Xenomai] Xenomai installation on P1020RDB

[Lukasz Zemla]

Hi Wolfgang,

Thank you for your mail, especially for sharing detailed latency results. 
Find my answers below.

> -----Original Message-----
> From: Wolfgang Grandegger [mailto:wg@grandegger.com]
> Sent: Friday, July 20, 2012 8:25 PM
> To: Lukasz Zemla
> Cc: Xenomai@xenomai.org
> Subject: Re: [Xenomai] Xenomai installation on P1020RDB
> 
> Hi Lukasz,
> 
> On 07/20/2012 04:31 PM, Lukasz Zemla wrote:
> > Hello,
> >
> > Has anyone some experience with installing Xenomai on P1020RDB board?
> I'd like to perform some benchmarks on this board.
> > I'm trying to install it using the latest Freescale SDK 1.2 based on
> > Yocto. But hints for SDK 1.0.3 would be also fine. Finally every way
> > for getting it working... ;-)
> >
> > What I'm doing is getting Freescale kernel (3.0.34):
> 
> If you can, use a *mainline* kernel. The latest Xenomai patch is for
> Linux 3.2.21 and that version does well support the P1020RDB, IIRC.

I tried to install Xenomai on 3.2.21 - it boots, but waits about 76 seconds after initialization of first eth0 controller: 

	[    0.905820] fsl-gianfar ethernet.1: eth0: TX BD ring size for Q[7]: 256
	[   77.451135] fsl-gianfar ethernet.2: eth1: mac: 00:04:9f:02:2d:11

There is no delay between eth1 and eth2. 

The vanilla 3.2.21 does not have any delays - it initializes eth0, eth1, eth2 immediately.

[...]

> > Next I tried to install Xenomai on vanilla 3.1.10 kernel. I got
> compilation error:
> >
> >         arch/powerpc/sysdev/fsl_lbc.c: In function
> 'fsl_lbc_ctrl_irq':
> >         arch/powerpc/sysdev/fsl_lbc.c:247:3: error: 'TASK_NORMAL'
> > undeclared (first use in this function)
> 
> That has nothing to do with Xenomai. Did you try to build the vanilla
> kernel first?

The vanilla 3.1.10 kernel builds and boots properly.
I double checked and confirm that 3.1.10 vanilla kernel after patching using adeos-ipipe-3.1.10-powerpc-2.13-08.patch has problem with compilation presented above.
After fsl_lbc.c file correction I can compile it and boot (what I forgot last time was rebuilding DTB file ('make ARCH=powerpc CROSS_COMPILE=powerpc-fsl-linux-gnuspe- p1020rdb.dtb'). With the new DTB system goes further but hangs for some time rises exception:

[    0.388188] audit: initializing netlink socket (disabled)
[    0.393538] type=2000 audit(0.332:1): initialized
[  240.395316] INFO: task kworker/1:0:8 blocked for more than 120 seconds.
[  240.401858] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  240.409665] kworker/1:0     D 00000000     0     8      2 0x00000000
[  240.416000] Call Trace:
[  240.418421] [ef065cc0] [42022024] 0x42022024 (unreliable)
[  240.423809] [ef065d80] [c0007948] __switch_to+0xa4/0xf4
[  240.429017] [ef065da0] [c051a9ac] __schedule+0x2c0/0x810
[  240.434306] [ef065e20] [c051b5d8] schedule_timeout+0x1c8/0x228
[  240.440121] [ef065e70] [c051a47c] wait_for_common+0xac/0x184
[  240.445770] [ef065eb0] [c0067b7c] kthread_create_on_node+0x90/0x10c
[  240.452012] [ef065f20] [c0060588] create_worker+0x140/0x1dc
[  240.457567] [ef065f50] [c0062b78] manage_workers.isra.24+0x118/0x208
[  240.463904] [ef065f70] [c0062f58] worker_thread+0x2f0/0x35c
[  240.469459] [ef065fb0] [c0067a58] kthread+0x7c/0x80
[  240.474320] [ef065ff0] [c000e69c] kernel_thread+0x4c/0x68

The presented exception is repeated every 120s. The system does not perform any other actions (further boot steps).


> > I fixed it by adding '#include <linux/sched.h>' in
> arch/powerpc/sysdev/fsl_lbc.c file. After successful build the kernel
> hung just after loading DTB.
> >
> >
> >
> > Filename 'p1020rdb-pc.dtb'.
> >
> > Load address: 0xc00000
> >
> > Loading: ###
> >
> > done
> >
> > Bytes transferred = 12888 (3258 hex)
> >
> > WARNING: adjusting available memory to 30000000
> >
> > ## Booting kernel from Legacy Image at 01000000 ...
> >
> >    Image Name:   Linux-3.1.10
> >
> >    Created:      2012-07-20  13:54:54 UTC
> >
> >    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
> >
> >    Data Size:    3757211 Bytes = 3.6 MiB
> >
> >    Load Address: 00000000
> >
> >    Entry Point:  00000000
> >
> >    Verifying Checksum ... OK
> >
> > ## Loading init Ramdisk from Legacy Image at 02000000 ...
> >
> >    Image Name:   fsl-image-minimal-ww-p1020rdb-20
> >
> >    Created:      2012-07-18   9:30:13 UTC
> >
> >    Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
> >
> >    Data Size:    4596585 Bytes = 4.4 MiB
> >
> >    Load Address: 00000000
> >
> >    Entry Point:  00000000
> >
> >    Verifying Checksum ... OK
> >
> > ## Flattened Device Tree blob at 00c00000
> >
> >    Booting using the fdt blob at 0xc00000
> >
> >    Uncompressing Kernel Image ... OK
> >
> >    Loading Ramdisk to 2fb9d000, end 2ffff369 ... OK
> >
> >    Loading Device Tree to 00ff9000, end 00fff257 ... OK
> 
> This is also not related to Xenomai. Did you set the console properly?
> You may be able to list the kernel log buffer after a soft-reset at
> address "grep __log_buf System.map | cut -d" " -f1" - 0xc0000000 using
> the U-Boot command "md".
> 
> I tested Xenomai recently on a P2020 with mainline Linux 3.2.x with the
> new iPipe-Patch and got very good latency results, especially with CPU
> isolation: 65 us without and *8* us with CPU isolation. [I'm still
> puzzled about the good results with CPU isolation. Maybe that's due to
> the new iPipe-Patch. Need to re-test when time permits). I have listed
> the results below.
> 
> Hope this info is useful.
> 
> Wolfgang.

[latency results] 


***
The information in this email is confidential and intended solely for the individual or entity to whom it is addressed. If you have received this email in error please notify the sender by return e-mail, delete this email, and refrain from any disclosure or action based on the information.
***

Re: [Xenomai] Xenomai installation on P1020RDB

[Gilles Chanteperdrix]

On 07/25/2012 06:18 PM, Lukasz Zemla wrote:

> I tried to install Xenomai on 3.2.21 - it boots, but waits about 76 seconds after initialization of first eth0 controller: 
> 
> 	[    0.905820] fsl-gianfar ethernet.1: eth0: TX BD ring size for Q[7]: 256
> 	[   77.451135] fsl-gianfar ethernet.2: eth1: mac: 00:04:9f:02:2d:11
> 
> There is no delay between eth1 and eth2. 
> 
> The vanilla 3.2.21 does not have any delays - it initializes eth0, eth1, eth2 immediately.
> 
> [...]


It is very much likely a timer issue. At the time it happens, is xenomai
started ?

-- 
                                                                Gilles.

Re: [Xenomai] Xenomai installation on P1020RDB

[Gilles Chanteperdrix]

On 07/25/2012 07:11 PM, Gilles Chanteperdrix wrote:

> On 07/25/2012 06:18 PM, Lukasz Zemla wrote:
> 
>> I tried to install Xenomai on 3.2.21 - it boots, but waits about 76 seconds after initialization of first eth0 controller: 
>>
>> 	[    0.905820] fsl-gianfar ethernet.1: eth0: TX BD ring size for Q[7]: 256
>> 	[   77.451135] fsl-gianfar ethernet.2: eth1: mac: 00:04:9f:02:2d:11
>>
>> There is no delay between eth1 and eth2. 
>>
>> The vanilla 3.2.21 does not have any delays - it initializes eth0, eth1, eth2 immediately.
>>
>> [...]
> 
> 
> It is very much likely a timer issue. At the time it happens, is xenomai
> started ?
> 


Also, it would be interesting to know a bit more about your kernel 
configuration, at least whether the following options are enabled:
CONFIG_HIGH_RES_TIMERS
CONFIG_NO_HZ
CONFIG_XENO_OPT_WATCHDOG

If the first two are on and the third is off, try the following patch:

diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 3ca10829..a752ca7 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -469,6 +469,14 @@ void arch_irq_work_raise(void)
 
 #endif /* CONFIG_IRQ_WORK */
 
+static inline void timer_ack(void)
+{
+	/* Ensure a positive value is written to the decrementer, or else
+	 * some CPUs will continue to take decrementer exceptions.
+	 */
+	set_dec(DECREMENTER_MAX);
+}
+
 /*
  * timer_interrupt - gets called when the decrementer overflows,
  * with interrupts disabled.
@@ -480,11 +488,8 @@ void timer_interrupt(struct pt_regs * regs)
 	struct clock_event_device *evt = &__get_cpu_var(decrementers);
 	u64 now;
 
-	/* Ensure a positive value is written to the decrementer, or else
-	 * some CPUs will continue to take decrementer exceptions.
-	 */
 	if (!clockevent_ipipe_stolen(evt))
-		set_dec(DECREMENTER_MAX);
+		timer_ack();
 
 	/* Some implementations of hotplug will get timer interrupts while
 	 * offline, just ignore these
@@ -836,6 +841,7 @@ static void register_decrementer_clockevent(int cpu)
 	dec->ipipe_timer = &per_cpu(itimers, cpu);
 	dec->ipipe_timer->irq = IPIPE_TIMER_VIRQ;
 	dec->ipipe_timer->set = itimer_set;
+	dec->ipipe_timer->ack = timer_ack;
 	dec->ipipe_timer->min_delay_ticks = 3;
 #endif /* CONFIG_IPIPE */
 


-- 
                                                                Gilles.

Re: [Xenomai] Xenomai installation on P1020RDB

[Wolfgang Grandegger]

Hi Lukasz,

On 07/25/2012 06:18 PM, Lukasz Zemla wrote:
> Hi Wolfgang,
> 
> Thank you for your mail, especially for sharing detailed latency results. 
> Find my answers below.
> 
>> -----Original Message-----
>> From: Wolfgang Grandegger [mailto:wg@grandegger.com]
>> Sent: Friday, July 20, 2012 8:25 PM
>> To: Lukasz Zemla
>> Cc: Xenomai@xenomai.org
>> Subject: Re: [Xenomai] Xenomai installation on P1020RDB
>>
>> Hi Lukasz,
>>
>> On 07/20/2012 04:31 PM, Lukasz Zemla wrote:
>>> Hello,
>>>
>>> Has anyone some experience with installing Xenomai on P1020RDB board?
>> I'd like to perform some benchmarks on this board.
>>> I'm trying to install it using the latest Freescale SDK 1.2 based on
>>> Yocto. But hints for SDK 1.0.3 would be also fine. Finally every way
>>> for getting it working... ;-)
>>>
>>> What I'm doing is getting Freescale kernel (3.0.34):
>>
>> If you can, use a *mainline* kernel. The latest Xenomai patch is for
>> Linux 3.2.21 and that version does well support the P1020RDB, IIRC.
> 
> I tried to install Xenomai on 3.2.21 - it boots, but waits about 76 seconds after initialization of first eth0 controller: 
> 
> 	[    0.905820] fsl-gianfar ethernet.1: eth0: TX BD ring size for Q[7]: 256
> 	[   77.451135] fsl-gianfar ethernet.2: eth1: mac: 00:04:9f:02:2d:11
> 
> There is no delay between eth1 and eth2. 
> 
> The vanilla 3.2.21 does not have any delays - it initializes eth0, eth1, eth2 immediately.

Strange. Could you please show us your .config. Is SMP enabled?

> [...]
> 
>>> Next I tried to install Xenomai on vanilla 3.1.10 kernel. I got
>> compilation error:
>>>
>>>         arch/powerpc/sysdev/fsl_lbc.c: In function
>> 'fsl_lbc_ctrl_irq':
>>>         arch/powerpc/sysdev/fsl_lbc.c:247:3: error: 'TASK_NORMAL'
>>> undeclared (first use in this function)
>>
>> That has nothing to do with Xenomai. Did you try to build the vanilla
>> kernel first?
> 
> The vanilla 3.1.10 kernel builds and boots properly.
> I double checked and confirm that 3.1.10 vanilla kernel after patching using adeos-ipipe-3.1.10-powerpc-2.13-08.patch has problem with compilation presented above.
> After fsl_lbc.c file correction I can compile it and boot (what I forgot last time was rebuilding DTB file ('make ARCH=powerpc CROSS_COMPILE=powerpc-fsl-linux-gnuspe- p1020rdb.dtb'). With the new DTB system goes further but hangs for some time rises exception:

I'm unable to reproduce that issue. What defconfig did you use? Could
you show use your .config. I used mpx85xx_smp_defconfig abd it compiled
fine.

> ***
> The information in this email is confidential and intended solely for the individual or entity to whom it is addressed. If you have received this email in error please notify the sender by return e-mail, delete this email, and refrain from any disclosure or action based on the information.
> ***

This note does not make sense when sending to a public mailing list.

Wolfgang.

Re: [Xenomai] Xenomai installation on P1020RDB

[Lukasz Zemla]

> -----Original Message-----
> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
> Sent: Wednesday, July 25, 2012 7:36 PM
> To: Lukasz Zemla
> Cc: Xenomai@xenomai.org
> Subject: Re: [Xenomai] Xenomai installation on P1020RDB
> 
> On 07/25/2012 07:11 PM, Gilles Chanteperdrix wrote:
> 
> > On 07/25/2012 06:18 PM, Lukasz Zemla wrote:
> >
> >> I tried to install Xenomai on 3.2.21 - it boots, but waits about 76
> seconds after initialization of first eth0 controller:
> >>
> >> 	[    0.905820] fsl-gianfar ethernet.1: eth0: TX BD ring size for
> Q[7]: 256
> >> 	[   77.451135] fsl-gianfar ethernet.2: eth1: mac:
> 00:04:9f:02:2d:11
> >>
> >> There is no delay between eth1 and eth2.
> >>
> >> The vanilla 3.2.21 does not have any delays - it initializes eth0,
> eth1, eth2 immediately.
> >>
> >> [...]
> >
> >
> > It is very much likely a timer issue. At the time it happens, is
> > xenomai started ?
> >
> 
> 
> Also, it would be interesting to know a bit more about your kernel
> configuration, at least whether the following options are enabled:
> CONFIG_HIGH_RES_TIMERS
> CONFIG_NO_HZ
> CONFIG_XENO_OPT_WATCHDOG
> 
> If the first two are on and the third is off, try the following patch:

The Xenomai is running at that time. 
[    0.385023] type=2000 audit(0.324:1): initialized
[    0.389902] I-pipe: head domain Xenomai registered.
[    0.394795] Xenomai: hal/powerpc started.
[    0.398762] Xenomai: scheduling class idle registered.
[    0.403848] Xenomai: scheduling class rt registered.
[    0.415567] Xenomai: real-time nucleus v2.6.1 (Light Years Away) loaded.
[    0.422217] Xenomai: debug mode enabled.
[    0.426434] Xenomai: starting native API services.
[    0.431160] Xenomai: starting POSIX services.
[    0.435609] Xenomai: starting RTDM services.
[    0.448964] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).

Here are the values of mentioned parameters:
	CONFIG_HIGH_RES_TIMERS=y
	CONFIG_NO_HZ=y
	CONFIG_XENO_OPT_WATCHDOG=y
	CONFIG_XENO_OPT_WATCHDOG_TIMEOUT=4

The third one is on, eventually I could try patch, but I'll have access to hardware in the morning (I'm working in Europe).

Best regards,
 Lukasz


***
The information in this email is confidential and intended solely for the individual or entity to whom it is addressed. If you have received this email in error please notify the sender by return e-mail, delete this email, and refrain from any disclosure or action based on the information.
***

Re: [Xenomai] Xenomai installation on P1020RDB

[Lukasz Zemla]

> -----Original Message-----
> From: Wolfgang Grandegger [mailto:wg@grandegger.com]
> Sent: Wednesday, July 25, 2012 9:27 PM
> To: Lukasz Zemla
> Cc: Xenomai@xenomai.org
> Subject: Re: [Xenomai] Xenomai installation on P1020RDB
> 
> Hi Lukasz,
> 
> On 07/25/2012 06:18 PM, Lukasz Zemla wrote:
> > Hi Wolfgang,
> >
> > Thank you for your mail, especially for sharing detailed latency
> results.
> > Find my answers below.
> >
> >> -----Original Message-----
> >> From: Wolfgang Grandegger [mailto:wg@grandegger.com]
> >> Sent: Friday, July 20, 2012 8:25 PM
> >> To: Lukasz Zemla
> >> Cc: Xenomai@xenomai.org
> >> Subject: Re: [Xenomai] Xenomai installation on P1020RDB
> >>
> >> Hi Lukasz,
> >>
> >> On 07/20/2012 04:31 PM, Lukasz Zemla wrote:
> >>> Hello,
> >>>
> >>> Has anyone some experience with installing Xenomai on P1020RDB
> board?
> >> I'd like to perform some benchmarks on this board.
> >>> I'm trying to install it using the latest Freescale SDK 1.2 based
> on
> >>> Yocto. But hints for SDK 1.0.3 would be also fine. Finally every
> way
> >>> for getting it working... ;-)
> >>>
> >>> What I'm doing is getting Freescale kernel (3.0.34):
> >>
> >> If you can, use a *mainline* kernel. The latest Xenomai patch is for
> >> Linux 3.2.21 and that version does well support the P1020RDB, IIRC.
> >
> > I tried to install Xenomai on 3.2.21 - it boots, but waits about 76
> seconds after initialization of first eth0 controller:
> >
> > 	[    0.905820] fsl-gianfar ethernet.1: eth0: TX BD ring size for
> Q[7]: 256
> > 	[   77.451135] fsl-gianfar ethernet.2: eth1: mac:
> 00:04:9f:02:2d:11
> >
> > There is no delay between eth1 and eth2.
> >
> > The vanilla 3.2.21 does not have any delays - it initializes eth0,
> eth1, eth2 immediately.
> 
> Strange. Could you please show us your .config. Is SMP enabled?

Yes, SMP is enabled. I attached the .config.
 

> > [...]
> >
> >>> Next I tried to install Xenomai on vanilla 3.1.10 kernel. I got
> >> compilation error:
> >>>
> >>>         arch/powerpc/sysdev/fsl_lbc.c: In function
> >> 'fsl_lbc_ctrl_irq':
> >>>         arch/powerpc/sysdev/fsl_lbc.c:247:3: error: 'TASK_NORMAL'
> >>> undeclared (first use in this function)
> >>
> >> That has nothing to do with Xenomai. Did you try to build the
> vanilla
> >> kernel first?
> >
> > The vanilla 3.1.10 kernel builds and boots properly.
> > I double checked and confirm that 3.1.10 vanilla kernel after
> patching using adeos-ipipe-3.1.10-powerpc-2.13-08.patch has problem
> with compilation presented above.
> > After fsl_lbc.c file correction I can compile it and boot (what I
> forgot last time was rebuilding DTB file ('make ARCH=powerpc
> CROSS_COMPILE=powerpc-fsl-linux-gnuspe- p1020rdb.dtb'). With the new
> DTB system goes further but hangs for some time rises exception:
> 
> I'm unable to reproduce that issue. What defconfig did you use? Could
> you show use your .config. I used mpx85xx_smp_defconfig abd it compiled
> fine.

I'm using defconfig delivered by Freescale in their first SDK 1.0.3. It was designed for kernel 2.6.35 or 2.6.37. It was migrated to the current stage by using mainly default settings in 'make oldconfig' + additional modifications (mainly removal of not necessary features). I'll try use defconfig in the morning.
 

> > ***
> > The information in this email is confidential and intended solely for
> the individual or entity to whom it is addressed. If you have received
> this email in error please notify the sender by return e-mail, delete
> this email, and refrain from any disclosure or action based on the
> information.
> > ***
> 
> This note does not make sense when sending to a public mailing list.
> 

Yes, I know it sounds stupid in public mailing list context. :) Unfortunately this text is added automatically by the company mail server. I'm working on having unblocked access to public mail servers.

Best regards,
 Lukasz



***
The information in this email is confidential and intended solely for the individual or entity to whom it is addressed. If you have received this email in error please notify the sender by return e-mail, delete this email, and refrain from any disclosure or action based on the information.
***
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config_3.2.21
Type: application/octet-stream
Size: 57405 bytes
Desc: config_3.2.21
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20120725/d6930a2c/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config_3.1.10
Type: application/octet-stream
Size: 57229 bytes
Desc: config_3.1.10
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20120725/d6930a2c/attachment-0001.obj>

Re: [Xenomai] Xenomai installation on P1020RDB

[Gilles Chanteperdrix]

On 07/25/2012 10:15 PM, Lukasz Zemla wrote:

> 
>> -----Original Message-----
>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
>> Sent: Wednesday, July 25, 2012 7:36 PM
>> To: Lukasz Zemla
>> Cc: Xenomai@xenomai.org
>> Subject: Re: [Xenomai] Xenomai installation on P1020RDB
>>
>> On 07/25/2012 07:11 PM, Gilles Chanteperdrix wrote:
>>
>>> On 07/25/2012 06:18 PM, Lukasz Zemla wrote:
>>>
>>>> I tried to install Xenomai on 3.2.21 - it boots, but waits about 76
>> seconds after initialization of first eth0 controller:
>>>>
>>>> 	[    0.905820] fsl-gianfar ethernet.1: eth0: TX BD ring size for
>> Q[7]: 256
>>>> 	[   77.451135] fsl-gianfar ethernet.2: eth1: mac:
>> 00:04:9f:02:2d:11
>>>>
>>>> There is no delay between eth1 and eth2.
>>>>
>>>> The vanilla 3.2.21 does not have any delays - it initializes eth0,
>> eth1, eth2 immediately.
>>>>
>>>> [...]
>>>
>>>
>>> It is very much likely a timer issue. At the time it happens, is
>>> xenomai started ?
>>>
>>
>>
>> Also, it would be interesting to know a bit more about your kernel
>> configuration, at least whether the following options are enabled:
>> CONFIG_HIGH_RES_TIMERS
>> CONFIG_NO_HZ
>> CONFIG_XENO_OPT_WATCHDOG
>>
>> If the first two are on and the third is off, try the following patch:
> 
> The Xenomai is running at that time. 
> [    0.385023] type=2000 audit(0.324:1): initialized
> [    0.389902] I-pipe: head domain Xenomai registered.
> [    0.394795] Xenomai: hal/powerpc started.
> [    0.398762] Xenomai: scheduling class idle registered.
> [    0.403848] Xenomai: scheduling class rt registered.
> [    0.415567] Xenomai: real-time nucleus v2.6.1 (Light Years Away) loaded.
> [    0.422217] Xenomai: debug mode enabled.
> [    0.426434] Xenomai: starting native API services.
> [    0.431160] Xenomai: starting POSIX services.
> [    0.435609] Xenomai: starting RTDM services.
> [    0.448964] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
> 
> Here are the values of mentioned parameters:
> 	CONFIG_HIGH_RES_TIMERS=y
> 	CONFIG_NO_HZ=y
> 	CONFIG_XENO_OPT_WATCHDOG=y
> 	CONFIG_XENO_OPT_WATCHDOG_TIMEOUT=4
> 

> The third one is on, eventually I could try patch, but I'll have

> access to hardware in the morning (I'm working in Europe).


No, the patch is probably needed for correctness, but will not solve the
issue you observe (with the watchdog on, there is always a timer
running, so, the decrementer is always programmed by xenomai).

What you can try is:
- putting a printk in __ipipe_grab_timer (say, print a dot every HZ ticks)
- and a similar printk in the "timer_interrupt" in
arch/powerpc/kernel/time.c

Now run the kernel and see if the two of them are ticking during the 76s
period.

-- 
                                                                Gilles.

Re: [Xenomai] Xenomai installation on P1020RDB

[Wolfgang Grandegger]

On 07/25/2012 10:26 PM, Lukasz Zemla wrote:
> 
>> -----Original Message-----
>> From: Wolfgang Grandegger [mailto:wg@grandegger.com]
>> Sent: Wednesday, July 25, 2012 9:27 PM
>> To: Lukasz Zemla
>> Cc: Xenomai@xenomai.org
>> Subject: Re: [Xenomai] Xenomai installation on P1020RDB
>>
>> Hi Lukasz,
>>
>> On 07/25/2012 06:18 PM, Lukasz Zemla wrote:
>>> Hi Wolfgang,
>>>
>>> Thank you for your mail, especially for sharing detailed latency
>> results.
>>> Find my answers below.
>>>
>>>> -----Original Message-----
>>>> From: Wolfgang Grandegger [mailto:wg@grandegger.com]
>>>> Sent: Friday, July 20, 2012 8:25 PM
>>>> To: Lukasz Zemla
>>>> Cc: Xenomai@xenomai.org
>>>> Subject: Re: [Xenomai] Xenomai installation on P1020RDB
>>>>
>>>> Hi Lukasz,
>>>>
>>>> On 07/20/2012 04:31 PM, Lukasz Zemla wrote:
>>>>> Hello,
>>>>>
>>>>> Has anyone some experience with installing Xenomai on P1020RDB
>> board?
>>>> I'd like to perform some benchmarks on this board.
>>>>> I'm trying to install it using the latest Freescale SDK 1.2 based
>> on
>>>>> Yocto. But hints for SDK 1.0.3 would be also fine. Finally every
>> way
>>>>> for getting it working... ;-)
>>>>>
>>>>> What I'm doing is getting Freescale kernel (3.0.34):
>>>>
>>>> If you can, use a *mainline* kernel. The latest Xenomai patch is for
>>>> Linux 3.2.21 and that version does well support the P1020RDB, IIRC.
>>>
>>> I tried to install Xenomai on 3.2.21 - it boots, but waits about 76
>> seconds after initialization of first eth0 controller:
>>>
>>> 	[    0.905820] fsl-gianfar ethernet.1: eth0: TX BD ring size for
>> Q[7]: 256
>>> 	[   77.451135] fsl-gianfar ethernet.2: eth1: mac:
>> 00:04:9f:02:2d:11
>>>
>>> There is no delay between eth1 and eth2.
>>>
>>> The vanilla 3.2.21 does not have any delays - it initializes eth0,
>> eth1, eth2 immediately.
>>
>> Strange. Could you please show us your .config. Is SMP enabled?
> 
> Yes, SMP is enabled. I attached the .config.
>  
> 
>>> [...]
>>>
>>>>> Next I tried to install Xenomai on vanilla 3.1.10 kernel. I got
>>>> compilation error:
>>>>>
>>>>>         arch/powerpc/sysdev/fsl_lbc.c: In function
>>>> 'fsl_lbc_ctrl_irq':
>>>>>         arch/powerpc/sysdev/fsl_lbc.c:247:3: error: 'TASK_NORMAL'
>>>>> undeclared (first use in this function)
>>>>
>>>> That has nothing to do with Xenomai. Did you try to build the
>> vanilla
>>>> kernel first?
>>>
>>> The vanilla 3.1.10 kernel builds and boots properly.
>>> I double checked and confirm that 3.1.10 vanilla kernel after
>> patching using adeos-ipipe-3.1.10-powerpc-2.13-08.patch has problem
>> with compilation presented above.
>>> After fsl_lbc.c file correction I can compile it and boot (what I
>> forgot last time was rebuilding DTB file ('make ARCH=powerpc
>> CROSS_COMPILE=powerpc-fsl-linux-gnuspe- p1020rdb.dtb'). With the new
>> DTB system goes further but hangs for some time rises exception:
>>
>> I'm unable to reproduce that issue. What defconfig did you use? Could
>> you show use your .config. I used mpx85xx_smp_defconfig abd it compiled
>> fine.
> 
> I'm using defconfig delivered by Freescale in their first SDK 1.0.3. It was designed for kernel 2.6.35 or 2.6.37. It was migrated to the current stage by using mainly default settings in 'make oldconfig' + additional modifications (mainly removal of not necessary features). I'll try use defconfig in the morning.

I can reproduce your build problem with your config. You may want to try
the mpc85xx_smp_defconfig instead (which did work for me).

Wolfgang.

Re: [Xenomai] Xenomai installation on P1020RDB

[Lukasz Zemla]

> -----Original Message-----
> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
> Sent: Wednesday, July 25, 2012 10:42 PM
> To: Lukasz Zemla
> Cc: Xenomai@xenomai.org
> Subject: Re: [Xenomai] Xenomai installation on P1020RDB
> 
> On 07/25/2012 10:15 PM, Lukasz Zemla wrote:
> 
> >
> >> -----Original Message-----
> >> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
> >> Sent: Wednesday, July 25, 2012 7:36 PM
> >> To: Lukasz Zemla
> >> Cc: Xenomai@xenomai.org
> >> Subject: Re: [Xenomai] Xenomai installation on P1020RDB
> >>
> >> On 07/25/2012 07:11 PM, Gilles Chanteperdrix wrote:
> >>
> >>> On 07/25/2012 06:18 PM, Lukasz Zemla wrote:
> >>>
> >>>> I tried to install Xenomai on 3.2.21 - it boots, but waits about
> 76
> >> seconds after initialization of first eth0 controller:
> >>>>
> >>>> 	[    0.905820] fsl-gianfar ethernet.1: eth0: TX BD ring size for
> >> Q[7]: 256
> >>>> 	[   77.451135] fsl-gianfar ethernet.2: eth1: mac:
> >> 00:04:9f:02:2d:11
> >>>>
> >>>> There is no delay between eth1 and eth2.
> >>>>
> >>>> The vanilla 3.2.21 does not have any delays - it initializes eth0,
> >> eth1, eth2 immediately.
> >>>>
> >>>> [...]
> >>>
> >>>
> >>> It is very much likely a timer issue. At the time it happens, is
> >>> xenomai started ?
> >>>
> >>
> >>
> >> Also, it would be interesting to know a bit more about your kernel
> >> configuration, at least whether the following options are enabled:
> >> CONFIG_HIGH_RES_TIMERS
> >> CONFIG_NO_HZ
> >> CONFIG_XENO_OPT_WATCHDOG
> >>
> >> If the first two are on and the third is off, try the following
> patch:
> >
> > The Xenomai is running at that time.
> > [    0.385023] type=2000 audit(0.324:1): initialized
> > [    0.389902] I-pipe: head domain Xenomai registered.
> > [    0.394795] Xenomai: hal/powerpc started.
> > [    0.398762] Xenomai: scheduling class idle registered.
> > [    0.403848] Xenomai: scheduling class rt registered.
> > [    0.415567] Xenomai: real-time nucleus v2.6.1 (Light Years Away)
> loaded.
> > [    0.422217] Xenomai: debug mode enabled.
> > [    0.426434] Xenomai: starting native API services.
> > [    0.431160] Xenomai: starting POSIX services.
> > [    0.435609] Xenomai: starting RTDM services.
> > [    0.448964] Installing knfsd (copyright (C) 1996
> okir@monad.swb.de).
> >
> > Here are the values of mentioned parameters:
> > 	CONFIG_HIGH_RES_TIMERS=y
> > 	CONFIG_NO_HZ=y
> > 	CONFIG_XENO_OPT_WATCHDOG=y
> > 	CONFIG_XENO_OPT_WATCHDOG_TIMEOUT=4
> >
> 
> > The third one is on, eventually I could try patch, but I'll have
> 
> > access to hardware in the morning (I'm working in Europe).
> 
> 
> No, the patch is probably needed for correctness, but will not solve
> the issue you observe (with the watchdog on, there is always a timer
> running, so, the decrementer is always programmed by xenomai).
> 
> What you can try is:
> - putting a printk in __ipipe_grab_timer (say, print a dot every HZ
> ticks)
> - and a similar printk in the "timer_interrupt" in
> arch/powerpc/kernel/time.c
> 
> Now run the kernel and see if the two of them are ticking during the
> 76s period.

__ipipe_grab_timer seems to be not called during that 76s period. It’s called before and after.
The timer_interrupt is working all the time.

Best regards,
 Lukasz



***
The information in this email is confidential and intended solely for the individual or entity to whom it is addressed. If you have received this email in error please notify the sender by return e-mail, delete this email, and refrain from any disclosure or action based on the information.
***

Re: [Xenomai] Xenomai installation on P1020RDB

[Gilles Chanteperdrix]

On 07/26/2012 01:20 PM, Lukasz Zemla wrote:

>> -----Original Message-----
>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
>> Sent: Wednesday, July 25, 2012 10:42 PM
>> To: Lukasz Zemla
>> Cc: Xenomai@xenomai.org
>> Subject: Re: [Xenomai] Xenomai installation on P1020RDB
>>
>> On 07/25/2012 10:15 PM, Lukasz Zemla wrote:
>>
>>>
>>>> -----Original Message-----
>>>> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
>>>> Sent: Wednesday, July 25, 2012 7:36 PM
>>>> To: Lukasz Zemla
>>>> Cc: Xenomai@xenomai.org
>>>> Subject: Re: [Xenomai] Xenomai installation on P1020RDB
>>>>
>>>> On 07/25/2012 07:11 PM, Gilles Chanteperdrix wrote:
>>>>
>>>>> On 07/25/2012 06:18 PM, Lukasz Zemla wrote:
>>>>>
>>>>>> I tried to install Xenomai on 3.2.21 - it boots, but waits about
>> 76
>>>> seconds after initialization of first eth0 controller:
>>>>>>
>>>>>> 	[    0.905820] fsl-gianfar ethernet.1: eth0: TX BD ring size for
>>>> Q[7]: 256
>>>>>> 	[   77.451135] fsl-gianfar ethernet.2: eth1: mac:
>>>> 00:04:9f:02:2d:11
>>>>>>
>>>>>> There is no delay between eth1 and eth2.
>>>>>>
>>>>>> The vanilla 3.2.21 does not have any delays - it initializes eth0,
>>>> eth1, eth2 immediately.
>>>>>>
>>>>>> [...]
>>>>>
>>>>>
>>>>> It is very much likely a timer issue. At the time it happens, is
>>>>> xenomai started ?
>>>>>
>>>>
>>>>
>>>> Also, it would be interesting to know a bit more about your kernel
>>>> configuration, at least whether the following options are enabled:
>>>> CONFIG_HIGH_RES_TIMERS
>>>> CONFIG_NO_HZ
>>>> CONFIG_XENO_OPT_WATCHDOG
>>>>
>>>> If the first two are on and the third is off, try the following
>> patch:
>>>
>>> The Xenomai is running at that time.
>>> [    0.385023] type=2000 audit(0.324:1): initialized
>>> [    0.389902] I-pipe: head domain Xenomai registered.
>>> [    0.394795] Xenomai: hal/powerpc started.
>>> [    0.398762] Xenomai: scheduling class idle registered.
>>> [    0.403848] Xenomai: scheduling class rt registered.
>>> [    0.415567] Xenomai: real-time nucleus v2.6.1 (Light Years Away)
>> loaded.
>>> [    0.422217] Xenomai: debug mode enabled.
>>> [    0.426434] Xenomai: starting native API services.
>>> [    0.431160] Xenomai: starting POSIX services.
>>> [    0.435609] Xenomai: starting RTDM services.
>>> [    0.448964] Installing knfsd (copyright (C) 1996
>> okir@monad.swb.de).
>>>
>>> Here are the values of mentioned parameters:
>>> 	CONFIG_HIGH_RES_TIMERS=y
>>> 	CONFIG_NO_HZ=y
>>> 	CONFIG_XENO_OPT_WATCHDOG=y
>>> 	CONFIG_XENO_OPT_WATCHDOG_TIMEOUT=4
>>>
>>
>>> The third one is on, eventually I could try patch, but I'll have
>>
>>> access to hardware in the morning (I'm working in Europe).
>>
>>
>> No, the patch is probably needed for correctness, but will not solve
>> the issue you observe (with the watchdog on, there is always a timer
>> running, so, the decrementer is always programmed by xenomai).
>>
>> What you can try is:
>> - putting a printk in __ipipe_grab_timer (say, print a dot every HZ
>> ticks)
>> - and a similar printk in the "timer_interrupt" in
>> arch/powerpc/kernel/time.c
>>
>> Now run the kernel and see if the two of them are ticking during the
>> 76s period.
> 
> __ipipe_grab_timer seems to be not called during that 76s period. It’s called before and after.
> The timer_interrupt is working all the time.


That is strange, whether xenomai intercepts the timer or not, the timer
interrupt normally always go through __ipipe_grab_timer first.

-- 
                                                                Gilles.

Re: [Xenomai] Xenomai installation on P1020RDB

[Lukasz Zemla]

Hello,

I'm able to use Xenomai on P1020RDB-PC using 3.2.21 kernel. The guilty was wrong .config. I apologize :( . When I use arch/powerpc/configs/mpc85xx_smp_defconfig then system does not have any 76s lags during boot. The only problem is that there is compilation error, but it can be easy to repair:

  CC      drivers/gpio/gpio-mpc8xxx.o
drivers/gpio/gpio-mpc8xxx.c: In function 'mpc8xxx_gpio_irq_cascade':
drivers/gpio/gpio-mpc8xxx.c:164:3: error: implicit declaration of function 'ipipe_handle_demuxed_irq' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors

make[2]: *** [drivers/gpio/gpio-mpc8xxx.o] Error 1
make[1]: *** [drivers/gpio] Error 2

What I discovered, the source of the '76s problem' could be preemption model. Now, when I set:
 - CONFIG_PREEMPT - the lag exists exactly after eth0 initialization. 
 - CONFIG_PREEMPT_VOLUNTARY - the boot process stops for a while (about 50-70s) in different places.
 - CONFIG_PREEMPT_NONE then all is fine, I cannot observe any described problems.



Pozdrawiam / Best Regards / Mit freundlichen Grüßen 
Łukasz Zemła


> -----Original Message-----
> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
> Sent: Thursday, July 26, 2012 2:00 PM
> To: Lukasz Zemla
> Cc: Xenomai@xenomai.org
> Subject: Re: [Xenomai] Xenomai installation on P1020RDB
> 
> On 07/26/2012 01:20 PM, Lukasz Zemla wrote:
> 
> >> -----Original Message-----
> >> From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]
> >> Sent: Wednesday, July 25, 2012 10:42 PM
> >> To: Lukasz Zemla
> >> Cc: Xenomai@xenomai.org
> >> Subject: Re: [Xenomai] Xenomai installation on P1020RDB
> >>
> >> On 07/25/2012 10:15 PM, Lukasz Zemla wrote:
> >>
> >>>
> >>>> -----Original Message-----
> >>>> From: Gilles Chanteperdrix
> >>>> [mailto:gilles.chanteperdrix@xenomai.org]
> >>>> Sent: Wednesday, July 25, 2012 7:36 PM
> >>>> To: Lukasz Zemla
> >>>> Cc: Xenomai@xenomai.org
> >>>> Subject: Re: [Xenomai] Xenomai installation on P1020RDB
> >>>>
> >>>> On 07/25/2012 07:11 PM, Gilles Chanteperdrix wrote:
> >>>>
> >>>>> On 07/25/2012 06:18 PM, Lukasz Zemla wrote:
> >>>>>
> >>>>>> I tried to install Xenomai on 3.2.21 - it boots, but waits about
> >> 76
> >>>> seconds after initialization of first eth0 controller:
> >>>>>>
> >>>>>> 	[    0.905820] fsl-gianfar ethernet.1: eth0: TX BD ring
> size for
> >>>> Q[7]: 256
> >>>>>> 	[   77.451135] fsl-gianfar ethernet.2: eth1: mac:
> >>>> 00:04:9f:02:2d:11
> >>>>>>
> >>>>>> There is no delay between eth1 and eth2.
> >>>>>>
> >>>>>> The vanilla 3.2.21 does not have any delays - it initializes
> >>>>>> eth0,
> >>>> eth1, eth2 immediately.
> >>>>>>
> >>>>>> [...]
> >>>>>
> >>>>>
> >>>>> It is very much likely a timer issue. At the time it happens, is
> >>>>> xenomai started ?
> >>>>>
> >>>>
> >>>>
> >>>> Also, it would be interesting to know a bit more about your kernel
> >>>> configuration, at least whether the following options are enabled:
> >>>> CONFIG_HIGH_RES_TIMERS
> >>>> CONFIG_NO_HZ
> >>>> CONFIG_XENO_OPT_WATCHDOG
> >>>>
> >>>> If the first two are on and the third is off, try the following
> >> patch:
> >>>
> >>> The Xenomai is running at that time.
> >>> [    0.385023] type=2000 audit(0.324:1): initialized
> >>> [    0.389902] I-pipe: head domain Xenomai registered.
> >>> [    0.394795] Xenomai: hal/powerpc started.
> >>> [    0.398762] Xenomai: scheduling class idle registered.
> >>> [    0.403848] Xenomai: scheduling class rt registered.
> >>> [    0.415567] Xenomai: real-time nucleus v2.6.1 (Light Years Away)
> >> loaded.
> >>> [    0.422217] Xenomai: debug mode enabled.
> >>> [    0.426434] Xenomai: starting native API services.
> >>> [    0.431160] Xenomai: starting POSIX services.
> >>> [    0.435609] Xenomai: starting RTDM services.
> >>> [    0.448964] Installing knfsd (copyright (C) 1996
> >> okir@monad.swb.de).
> >>>
> >>> Here are the values of mentioned parameters:
> >>> 	CONFIG_HIGH_RES_TIMERS=y
> >>> 	CONFIG_NO_HZ=y
> >>> 	CONFIG_XENO_OPT_WATCHDOG=y
> >>> 	CONFIG_XENO_OPT_WATCHDOG_TIMEOUT=4
> >>>
> >>
> >>> The third one is on, eventually I could try patch, but I'll have
> >>
> >>> access to hardware in the morning (I'm working in Europe).
> >>
> >>
> >> No, the patch is probably needed for correctness, but will not solve
> >> the issue you observe (with the watchdog on, there is always a timer
> >> running, so, the decrementer is always programmed by xenomai).
> >>
> >> What you can try is:
> >> - putting a printk in __ipipe_grab_timer (say, print a dot every HZ
> >> ticks)
> >> - and a similar printk in the "timer_interrupt" in
> >> arch/powerpc/kernel/time.c
> >>
> >> Now run the kernel and see if the two of them are ticking during the
> >> 76s period.
> >
> > __ipipe_grab_timer seems to be not called during that 76s period.
> It’s called before and after.
> > The timer_interrupt is working all the time.
> 
> 
> That is strange, whether xenomai intercepts the timer or not, the timer
> interrupt normally always go through __ipipe_grab_timer first.
> 
> --
>                                                                 Gilles.



***
The information in this email is confidential and intended solely for the individual or entity to whom it is addressed. If you have received this email in error please notify the sender by return e-mail, delete this email, and refrain from any disclosure or action based on the information.
***

Re: [Xenomai] Xenomai installation on P1020RDB

[Gilles Chanteperdrix]

On 07/27/2012 05:53 PM, Lukasz Zemla wrote:

> What I discovered, the source of the '76s problem' could be preemption model. Now, when I set:
>  - CONFIG_PREEMPT - the lag exists exactly after eth0 initialization. 
>  - CONFIG_PREEMPT_VOLUNTARY - the boot process stops for a while (about 50-70s) in different places.
>  - CONFIG_PREEMPT_NONE then all is fine, I cannot observe any described problems.


CONFIG_PREEMPT or PREEMPT_VOLUNTARY. Try this patch:

diff --git a/arch/powerpc/kernel/ipipe.c b/arch/powerpc/kernel/ipipe.c
index 45302c1..5b706da 100644
--- a/arch/powerpc/kernel/ipipe.c
+++ b/arch/powerpc/kernel/ipipe.c
@@ -344,8 +344,10 @@ static void __ipipe_do_IRQ(unsigned int irq, void
*cookie)

 static void __ipipe_do_timer(unsigned int irq, void *cookie)
 {
+	irq_enter();
 	check_stack_overflow();
 	timer_interrupt(__this_cpu_ptr(&ipipe_percpu.tick_regs));
+	irq_exit();
 }

 asmlinkage int __ipipe_grab_timer(struct pt_regs *regs)

Or to remove the #ifdef CONFIG_IPIPE / #endif around the calls to
irq_enter/irq_exit in arch/powerpc/kernel/time.c
-- 
                                                                Gilles.

Re: [Xenomai] Xenomai installation on P1020RDB

[Philippe Gerum]

On 07/27/2012 06:00 PM, Gilles Chanteperdrix wrote:
> On 07/27/2012 05:53 PM, Lukasz Zemla wrote:
>
>> What I discovered, the source of the '76s problem' could be preemption model. Now, when I set:
>>   - CONFIG_PREEMPT - the lag exists exactly after eth0 initialization.
>>   - CONFIG_PREEMPT_VOLUNTARY - the boot process stops for a while (about 50-70s) in different places.
>>   - CONFIG_PREEMPT_NONE then all is fine, I cannot observe any described problems.
>
>
> CONFIG_PREEMPT or PREEMPT_VOLUNTARY. Try this patch:
>
> diff --git a/arch/powerpc/kernel/ipipe.c b/arch/powerpc/kernel/ipipe.c
> index 45302c1..5b706da 100644
> --- a/arch/powerpc/kernel/ipipe.c
> +++ b/arch/powerpc/kernel/ipipe.c
> @@ -344,8 +344,10 @@ static void __ipipe_do_IRQ(unsigned int irq, void
> *cookie)
>
>   static void __ipipe_do_timer(unsigned int irq, void *cookie)
>   {
> +	irq_enter();
>   	check_stack_overflow();
>   	timer_interrupt(__this_cpu_ptr(&ipipe_percpu.tick_regs));
> +	irq_exit();
>   }
>
>   asmlinkage int __ipipe_grab_timer(struct pt_regs *regs)
>
> Or to remove the #ifdef CONFIG_IPIPE / #endif around the calls to
> irq_enter/irq_exit in arch/powerpc/kernel/time.c
>

Mm, no. On ppc, we use a virtual irq to map the decrementer, so the 
pipeline core already took care of marking the irq entry before calling 
the __ipipe_do_timer handler. The issue may be in the log syncer instead.

-- 
Philippe.

Re: [Xenomai] Xenomai installation on P1020RDB

[Lukasz Zemla]

> -----Original Message-----
> From: Philippe Gerum [mailto:rpm@xenomai.org]
> Sent: Friday, July 27, 2012 6:09 PM
> To: Gilles Chanteperdrix
> Cc: Lukasz Zemla; Xenomai@xenomai.org
> Subject: Re: [Xenomai] Xenomai installation on P1020RDB
> 
> On 07/27/2012 06:00 PM, Gilles Chanteperdrix wrote:
> > On 07/27/2012 05:53 PM, Lukasz Zemla wrote:
> >
> >> What I discovered, the source of the '76s problem' could be
> preemption model. Now, when I set:
> >>   - CONFIG_PREEMPT - the lag exists exactly after eth0
> initialization.
> >>   - CONFIG_PREEMPT_VOLUNTARY - the boot process stops for a while
> (about 50-70s) in different places.
> >>   - CONFIG_PREEMPT_NONE then all is fine, I cannot observe any
> described problems.
> >
> >
> > CONFIG_PREEMPT or PREEMPT_VOLUNTARY. Try this patch:
> >
> > diff --git a/arch/powerpc/kernel/ipipe.c
> b/arch/powerpc/kernel/ipipe.c
> > index 45302c1..5b706da 100644
> > --- a/arch/powerpc/kernel/ipipe.c
> > +++ b/arch/powerpc/kernel/ipipe.c
> > @@ -344,8 +344,10 @@ static void __ipipe_do_IRQ(unsigned int irq,
> void
> > *cookie)
> >
> >   static void __ipipe_do_timer(unsigned int irq, void *cookie)
> >   {
> > +	irq_enter();
> >   	check_stack_overflow();
> >   	timer_interrupt(__this_cpu_ptr(&ipipe_percpu.tick_regs));
> > +	irq_exit();
> >   }
> >
> >   asmlinkage int __ipipe_grab_timer(struct pt_regs *regs)
> >
> > Or to remove the #ifdef CONFIG_IPIPE / #endif around the calls to
> > irq_enter/irq_exit in arch/powerpc/kernel/time.c
> >
> 
> Mm, no. On ppc, we use a virtual irq to map the decrementer, so the
> pipeline core already took care of marking the irq entry before calling
> the __ipipe_do_timer handler. The issue may be in the log syncer
> instead.

Maybe I have some symptom which I forgot to write. When the system with CONFIG_PREEMPT stayed unused for last night I saw following errors:

Yocto (Built by Poky 6.0) 1.1 p1020rdb ttyS0

p1020rdb login: [  193.919436] INFO: rcu_preempt detected stalls on CPUs/tasks: { 1} (detected by 0, t=15002 jiffies)
[  193.928407] Call Trace:
[  193.930860] [c0799cb0] [c0008234] show_stack+0x4c/0x174 (unreliable)
[  193.937222] [c0799cf0] [c0092464] __rcu_pending+0x424/0x440
[  193.942794] [c0799d30] [c0092a84] rcu_check_callbacks+0x150/0x1f8
[  193.948893] [c0799d50] [c0056f40] update_process_times+0x3c/0x60
[  193.954904] [c0799d70] [c0079fe4] tick_sched_timer+0x8c/0xfc
[  193.960570] [c0799da0] [c006bdb4] __run_hrtimer.isra.28+0x58/0x100
[  193.966751] [c0799dc0] [c006cc3c] hrtimer_interrupt+0x160/0x408
[  193.972673] [c0799e50] [c0009d14] timer_interrupt+0x13c/0x1b8
[  193.978421] [c0799e80] [c000e2cc] __ipipe_do_timer+0x44/0x54
[  193.984082] [c0799e90] [c009467c] __ipipe_do_sync_stage+0x1e0/0x220
[  193.990350] [c0799ec0] [c000e9a0] __ipipe_grab_timer+0xa8/0xc0
[  193.996186] [c0799ed0] [c00107a4] __ipipe_ret_from_except+0x0/0xc
[  194.002282] --- Exception: 901 at cpu_idle+0x8c/0xf0
[  194.002286]     LR = cpu_idle+0x8c/0xf0
[  194.011067] [c0799f90] [c0008df8] cpu_idle+0xb0/0xf0 (unreliable)
[  194.017165] [c0799fb0] [c0002438] rest_init+0x88/0x98
[  194.022221] [c0799fc0] [c072778c] start_kernel+0x2e8/0x2fc
[  194.027706] [c0799ff0] [c00003fc] skpinv+0x2e8/0x324
[ 6662.479437] INFO: rcu_bh detected stalls on CPUs/tasks: { 1} (detected by 0, t=15002 jiffies)
[ 6662.487975] Call Trace:
[ 6662.490428] [c0799cb0] [c0008234] show_stack+0x4c/0x174 (unreliable)
[ 6662.496790] [c0799cf0] [c0092464] __rcu_pending+0x424/0x440
[ 6662.502363] [c0799d30] [c0092a68] rcu_check_callbacks+0x134/0x1f8
[ 6662.508460] [c0799d50] [c0056f40] update_process_times+0x3c/0x60
[ 6662.514473] [c0799d70] [c0079fe4] tick_sched_timer+0x8c/0xfc
[ 6662.520138] [c0799da0] [c006bdb4] __run_hrtimer.isra.28+0x58/0x100
[ 6662.526319] [c0799dc0] [c006cc3c] hrtimer_interrupt+0x160/0x408
[ 6662.532241] [c0799e50] [c0009d14] timer_interrupt+0x13c/0x1b8
[ 6662.537989] [c0799e80] [c000e2cc] __ipipe_do_timer+0x44/0x54
[ 6662.543650] [c0799e90] [c009467c] __ipipe_do_sync_stage+0x1e0/0x220
[ 6662.549917] [c0799ec0] [c000e9a0] __ipipe_grab_timer+0xa8/0xc0
[ 6662.555752] [c0799ed0] [c00107a4] __ipipe_ret_from_except+0x0/0xc
[ 6662.561849] --- Exception: 901 at cpu_idle+0x8c/0xf0
[ 6662.561852]     LR = cpu_idle+0x8c/0xf0
[ 6662.570635] [c0799f90] [c0008df8] cpu_idle+0xb0/0xf0 (unreliable)
[ 6662.576732] [c0799fb0] [c0002438] rest_init+0x88/0x98
[ 6662.581788] [c0799fc0] [c072778c] start_kernel+0x2e8/0x2fc
[ 6662.587273] [c0799ff0] [c00003fc] skpinv+0x2e8/0x324

-- 
Best regards,
 Lukasz


***
The information in this email is confidential and intended solely for the individual or entity to whom it is addressed. If you have received this email in error please notify the sender by return e-mail, delete this email, and refrain from any disclosure or action based on the information.
***

Re: [Xenomai] Xenomai installation on P1020RDB

[Philippe Gerum]

On 07/27/2012 06:12 PM, Lukasz Zemla wrote:
>
>> -----Original Message-----
>> From: Philippe Gerum [mailto:rpm@xenomai.org]
>> Sent: Friday, July 27, 2012 6:09 PM
>> To: Gilles Chanteperdrix
>> Cc: Lukasz Zemla; Xenomai@xenomai.org
>> Subject: Re: [Xenomai] Xenomai installation on P1020RDB
>>
>> On 07/27/2012 06:00 PM, Gilles Chanteperdrix wrote:
>>> On 07/27/2012 05:53 PM, Lukasz Zemla wrote:
>>>
>>>> What I discovered, the source of the '76s problem' could be
>> preemption model. Now, when I set:
>>>>    - CONFIG_PREEMPT - the lag exists exactly after eth0
>> initialization.
>>>>    - CONFIG_PREEMPT_VOLUNTARY - the boot process stops for a while
>> (about 50-70s) in different places.
>>>>    - CONFIG_PREEMPT_NONE then all is fine, I cannot observe any
>> described problems.
>>>
>>>
>>> CONFIG_PREEMPT or PREEMPT_VOLUNTARY. Try this patch:
>>>
>>> diff --git a/arch/powerpc/kernel/ipipe.c
>> b/arch/powerpc/kernel/ipipe.c
>>> index 45302c1..5b706da 100644
>>> --- a/arch/powerpc/kernel/ipipe.c
>>> +++ b/arch/powerpc/kernel/ipipe.c
>>> @@ -344,8 +344,10 @@ static void __ipipe_do_IRQ(unsigned int irq,
>> void
>>> *cookie)
>>>
>>>    static void __ipipe_do_timer(unsigned int irq, void *cookie)
>>>    {
>>> +	irq_enter();
>>>    	check_stack_overflow();
>>>    	timer_interrupt(__this_cpu_ptr(&ipipe_percpu.tick_regs));
>>> +	irq_exit();
>>>    }
>>>
>>>    asmlinkage int __ipipe_grab_timer(struct pt_regs *regs)
>>>
>>> Or to remove the #ifdef CONFIG_IPIPE / #endif around the calls to
>>> irq_enter/irq_exit in arch/powerpc/kernel/time.c
>>>
>>
>> Mm, no. On ppc, we use a virtual irq to map the decrementer, so the
>> pipeline core already took care of marking the irq entry before calling
>> the __ipipe_do_timer handler. The issue may be in the log syncer
>> instead.
>
> Maybe I have some symptom which I forgot to write. When the system with CONFIG_PREEMPT stayed unused for last night I saw following errors:

I should be able to reproduce this issue on some hw I have access to. 
I'll have a look and let you know. Thanks.

>
> Yocto (Built by Poky 6.0) 1.1 p1020rdb ttyS0
>
> p1020rdb login: [  193.919436] INFO: rcu_preempt detected stalls on CPUs/tasks: { 1} (detected by 0, t=15002 jiffies)
> [  193.928407] Call Trace:
> [  193.930860] [c0799cb0] [c0008234] show_stack+0x4c/0x174 (unreliable)
> [  193.937222] [c0799cf0] [c0092464] __rcu_pending+0x424/0x440
> [  193.942794] [c0799d30] [c0092a84] rcu_check_callbacks+0x150/0x1f8
> [  193.948893] [c0799d50] [c0056f40] update_process_times+0x3c/0x60
> [  193.954904] [c0799d70] [c0079fe4] tick_sched_timer+0x8c/0xfc
> [  193.960570] [c0799da0] [c006bdb4] __run_hrtimer.isra.28+0x58/0x100
> [  193.966751] [c0799dc0] [c006cc3c] hrtimer_interrupt+0x160/0x408
> [  193.972673] [c0799e50] [c0009d14] timer_interrupt+0x13c/0x1b8
> [  193.978421] [c0799e80] [c000e2cc] __ipipe_do_timer+0x44/0x54
> [  193.984082] [c0799e90] [c009467c] __ipipe_do_sync_stage+0x1e0/0x220
> [  193.990350] [c0799ec0] [c000e9a0] __ipipe_grab_timer+0xa8/0xc0
> [  193.996186] [c0799ed0] [c00107a4] __ipipe_ret_from_except+0x0/0xc
> [  194.002282] --- Exception: 901 at cpu_idle+0x8c/0xf0
> [  194.002286]     LR = cpu_idle+0x8c/0xf0
> [  194.011067] [c0799f90] [c0008df8] cpu_idle+0xb0/0xf0 (unreliable)
> [  194.017165] [c0799fb0] [c0002438] rest_init+0x88/0x98
> [  194.022221] [c0799fc0] [c072778c] start_kernel+0x2e8/0x2fc
> [  194.027706] [c0799ff0] [c00003fc] skpinv+0x2e8/0x324
> [ 6662.479437] INFO: rcu_bh detected stalls on CPUs/tasks: { 1} (detected by 0, t=15002 jiffies)
> [ 6662.487975] Call Trace:
> [ 6662.490428] [c0799cb0] [c0008234] show_stack+0x4c/0x174 (unreliable)
> [ 6662.496790] [c0799cf0] [c0092464] __rcu_pending+0x424/0x440
> [ 6662.502363] [c0799d30] [c0092a68] rcu_check_callbacks+0x134/0x1f8
> [ 6662.508460] [c0799d50] [c0056f40] update_process_times+0x3c/0x60
> [ 6662.514473] [c0799d70] [c0079fe4] tick_sched_timer+0x8c/0xfc
> [ 6662.520138] [c0799da0] [c006bdb4] __run_hrtimer.isra.28+0x58/0x100
> [ 6662.526319] [c0799dc0] [c006cc3c] hrtimer_interrupt+0x160/0x408
> [ 6662.532241] [c0799e50] [c0009d14] timer_interrupt+0x13c/0x1b8
> [ 6662.537989] [c0799e80] [c000e2cc] __ipipe_do_timer+0x44/0x54
> [ 6662.543650] [c0799e90] [c009467c] __ipipe_do_sync_stage+0x1e0/0x220
> [ 6662.549917] [c0799ec0] [c000e9a0] __ipipe_grab_timer+0xa8/0xc0
> [ 6662.555752] [c0799ed0] [c00107a4] __ipipe_ret_from_except+0x0/0xc
> [ 6662.561849] --- Exception: 901 at cpu_idle+0x8c/0xf0
> [ 6662.561852]     LR = cpu_idle+0x8c/0xf0
> [ 6662.570635] [c0799f90] [c0008df8] cpu_idle+0xb0/0xf0 (unreliable)
> [ 6662.576732] [c0799fb0] [c0002438] rest_init+0x88/0x98
> [ 6662.581788] [c0799fc0] [c072778c] start_kernel+0x2e8/0x2fc
> [ 6662.587273] [c0799ff0] [c00003fc] skpinv+0x2e8/0x324
>


-- 
Philippe.

Re: [Xenomai] Xenomai installation on P1020RDB

[Philippe Gerum]

On 07/25/2012 07:36 PM, Gilles Chanteperdrix wrote:

> If the first two are on and the third is off, try the following patch:
>
> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
> index 3ca10829..a752ca7 100644
> --- a/arch/powerpc/kernel/time.c
> +++ b/arch/powerpc/kernel/time.c
> @@ -469,6 +469,14 @@ void arch_irq_work_raise(void)
>
>   #endif /* CONFIG_IRQ_WORK */
>
> +static inline void timer_ack(void)
> +{
> +	/* Ensure a positive value is written to the decrementer, or else
> +	 * some CPUs will continue to take decrementer exceptions.
> +	 */
> +	set_dec(DECREMENTER_MAX);
> +}
> +
>   /*
>    * timer_interrupt - gets called when the decrementer overflows,
>    * with interrupts disabled.
> @@ -480,11 +488,8 @@ void timer_interrupt(struct pt_regs * regs)
>   	struct clock_event_device *evt = &__get_cpu_var(decrementers);
>   	u64 now;
>
> -	/* Ensure a positive value is written to the decrementer, or else
> -	 * some CPUs will continue to take decrementer exceptions.
> -	 */
>   	if (!clockevent_ipipe_stolen(evt))
> -		set_dec(DECREMENTER_MAX);
> +		timer_ack();
>
>   	/* Some implementations of hotplug will get timer interrupts while
>   	 * offline, just ignore these
> @@ -836,6 +841,7 @@ static void register_decrementer_clockevent(int cpu)
>   	dec->ipipe_timer = &per_cpu(itimers, cpu);
>   	dec->ipipe_timer->irq = IPIPE_TIMER_VIRQ;
>   	dec->ipipe_timer->set = itimer_set;
> +	dec->ipipe_timer->ack = timer_ack;
>   	dec->ipipe_timer->min_delay_ticks = 3;
>   #endif /* CONFIG_IPIPE */
>
>
>

Actually, we don't need this, __ipipe_grab_timer() does it early.

-- 
Philippe.

Re: [Xenomai] Xenomai installation on P1020RDB

[Philippe Gerum]

On 07/27/2012 06:19 PM, Philippe Gerum wrote:
> On 07/27/2012 06:12 PM, Lukasz Zemla wrote:
>>
>>> -----Original Message-----
>>> From: Philippe Gerum [mailto:rpm@xenomai.org]
>>> Sent: Friday, July 27, 2012 6:09 PM
>>> To: Gilles Chanteperdrix
>>> Cc: Lukasz Zemla; Xenomai@xenomai.org
>>> Subject: Re: [Xenomai] Xenomai installation on P1020RDB
>>>
>>> On 07/27/2012 06:00 PM, Gilles Chanteperdrix wrote:
>>>> On 07/27/2012 05:53 PM, Lukasz Zemla wrote:
>>>>
>>>>> What I discovered, the source of the '76s problem' could be
>>> preemption model. Now, when I set:
>>>>>    - CONFIG_PREEMPT - the lag exists exactly after eth0
>>> initialization.
>>>>>    - CONFIG_PREEMPT_VOLUNTARY - the boot process stops for a while
>>> (about 50-70s) in different places.
>>>>>    - CONFIG_PREEMPT_NONE then all is fine, I cannot observe any
>>> described problems.
>>>>
>>>>
>>>> CONFIG_PREEMPT or PREEMPT_VOLUNTARY. Try this patch:
>>>>
>>>> diff --git a/arch/powerpc/kernel/ipipe.c
>>> b/arch/powerpc/kernel/ipipe.c
>>>> index 45302c1..5b706da 100644
>>>> --- a/arch/powerpc/kernel/ipipe.c
>>>> +++ b/arch/powerpc/kernel/ipipe.c
>>>> @@ -344,8 +344,10 @@ static void __ipipe_do_IRQ(unsigned int irq,
>>> void
>>>> *cookie)
>>>>
>>>>    static void __ipipe_do_timer(unsigned int irq, void *cookie)
>>>>    {
>>>> +    irq_enter();
>>>>        check_stack_overflow();
>>>>        timer_interrupt(__this_cpu_ptr(&ipipe_percpu.tick_regs));
>>>> +    irq_exit();
>>>>    }
>>>>
>>>>    asmlinkage int __ipipe_grab_timer(struct pt_regs *regs)
>>>>
>>>> Or to remove the #ifdef CONFIG_IPIPE / #endif around the calls to
>>>> irq_enter/irq_exit in arch/powerpc/kernel/time.c
>>>>
>>>
>>> Mm, no. On ppc, we use a virtual irq to map the decrementer, so the
>>> pipeline core already took care of marking the irq entry before calling
>>> the __ipipe_do_timer handler. The issue may be in the log syncer
>>> instead.
>>
>> Maybe I have some symptom which I forgot to write. When the system
>> with CONFIG_PREEMPT stayed unused for last night I saw following errors:
>
> I should be able to reproduce this issue on some hw I have access to.
> I'll have a look and let you know. Thanks.
>

Unlucky. I can't reproduce this issue, enabling preemption on a P1022 
board. So we'll need to chase this bug differently.

Did you try disabling CONFIG_XENOMAI, while leaving CONFIG_IPIPE 
enabled? This would tells us whether the issue is triggered by having a 
high priority domain stacked.

Also, if you intend to debug further, I'd suggest that you enable 
CONFIG_IPIPE_DEBUG_CONTEXT and CONFIG_IPIPE_DEBUG_INTERNAL. Since you 
have CONFIG_SERIAL_8250_CONSOLE enabled already, you would have access 
to the __ipipe_serial_debug() service, which is a replacement for 
printk() in desperate cases, which does brute force output to the uart, 
and therefore does not suffer from any delay/buffering (*).

TIA,

(*) caution: this service only works after the 16650 MMIO area has been 
mapped in, so don't try it before the early serial devices have initialized.

-- 
Philippe.