[Xenomai-help] [ARM-MV88F6290] Xenomai 2.5.1 latency test results (still negative and huge)

[Xenomai-help] [ARM-MV88F6290] Xenomai 2.5.1 latency test results (still negative and huge)

[Sergey Didenko]

[-- Attachment #1.1: Type: text/plain, Size: 4606 bytes --]

Hello

As a unit:
1) Board MV88F6290
2) Linux Kernel 2.6.29
3) Xenomai version 2.5.1

I have new latency test results for Xenomai 2.5.1!

I adjusted /proc/xenomai/latency value for kernel mode from 9503 to 5099
(making minimum latency more close to 0)
And there is a big difference (in comparission with xenomai 2.4.9 version)
in case of user-mode, with xenomai 2.4.9, adjusted value was 4400, but with
xenomai 2.5.1 I have to set it to 44300 (! 10 times bigger) to get the
minimum latency very close to 0.
All test for user mode I did with value /proc/xenomai/latency = 0
All test for kernel mode I did with value /proc/xenomai/latency = 5100

(user-mode, no workload)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat
worst
RTD|     44.321|     45.077|     53.639|       0|     0|     -7.854|
59.141
RTD|     44.045|     45.053|     53.675|       0|     0|     -7.854|
59.141
RTD|     44.369|     45.113|     53.651|       0|     0|     -7.854|
59.141
RTD|     44.273|     45.065|     55.349|       0|     0|     -7.854|
59.141
RTD|     44.261|     45.113|     53.837|       0|     0|     -7.854|
59.141
RTD|     44.369|     45.143|     53.939|       0|     0|     -7.854|
59.141
RTD|     44.345|     45.083|     53.579|       0|     0|     -7.854|
59.141
RTD|     44.237|     45.113|     54.203|       0|     0|     -7.854|
59.141

(user-mode, workload)
RTT|  00:00:53  (periodic user-mode task, 1000 us period, priority 90)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat
worst
RTD|     43.529|     45.431|     73.103|      12|     0|     25.301|
6212.578
RTD|     22.823|   4093.319|-253909.961|    4053|     0|
22.823|-253909.961
RTD|     43.253|   1146.665| 552468.141|    5145|     0|
22.823|-253909.961
RTD|     43.319|     66.593|   6622.336|    5154|     0|
22.823|-253909.961
RTD|     43.733|   4653.617|-249022.722|    9751|     0|
22.823|-249022.722
RTD|     43.181|     50.891|    261.377|    9751|     0|
22.823|-249022.722
RTD|     43.235|    600.203| 537511.848|   10292|     0|
22.823|-249022.722
RTD|     28.007|   4266.755|-249056.664|   14503|     0|
22.823|-249022.722
RTD|     15.209|    506.411|  11999.643|   14931|     0|
15.209|-249022.722
RTD|     43.667|    475.481|  10511.487|   15334|     0|
15.209|-249022.722
RTD|     43.727|    434.309|  10607.205|   15696|     0|
15.209|-249022.722
RTD|     43.619|     57.443|   5973.988|   15701|     0|
15.209|-249022.722
RTD|     43.583|     51.875|     76.613|   15701|     0|
15.209|-249022.722

(kernel-mode, no workload)
RTT|  00:00:01  (in-kernel periodic task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat
worst
RTD|      0.044|      0.491|      4.058|       0|     0|      0.044|
4.058
RTD|      0.044|      0.568|     14.878|       0|     0|      0.044|
14.878
RTD|      0.057|      0.574|     16.746|       0|     0|      0.044|
16.746
RTD|      0.061|      0.526|     13.464|       0|     0|      0.044|
16.746
RTD|      0.060|      0.413|     19.013|       0|     0|      0.044|
19.013
RTD|      0.048|      0.421|     18.868|       0|     0|      0.044|
19.013
RTD|      0.055|      0.464|     21.172|       0|     0|      0.044|
21.172
RTD|      0.059|      0.537|     13.167|       0|     0|      0.044|
21.172

(kernel-mode, workload)
RTT|  00:01:03  (in-kernel periodic task, 1000 us period, priority 99)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat
worst
RTD|      0.189|      9.531|    180.356|       0|     0|      0.189|
462.132
RTD|      0.215|      9.658|    359.376|       2|     0|      0.134|
1400.898
RTD|-1408018.932|-909124.937| -10000.000|       7|     0|-1408018.932|
5813.438
RTD|-2147115.692|-1313618.790|2146852.804|    2153|
0|-2147115.692|2146852.804
RTD|      0.122|    444.989| 429994.441|    2587|
0|-2147115.692|2146852.804
RTD|      0.436|    638.703| 521405.046|    3219|
0|-2147115.692|2146852.804
RTD|-2010491.628|-1511599.828| -10000.000|    3219|
0|-2147115.692|2146852.804
RTD|-2036462.437|-1537573.753| -10000.000|    6018|
0|-2147325.434|2146852.804
RTD|-2147327.407|-229395.059|2146641.095|    8866|
0|-2147327.407|2146852.804
RTD|      0.389|    443.264|  12054.734|    9280|
0|-2147327.407|2146852.804

I have attached the jpg files with graphs for Kernel and User mode (min, avg
and max latency).

I'am attaching the diff file which shows the difference between original
Xenomai 2.5.1 patch and mine.

Please let me know:
1) The reason for such huge and negative values?
2) What could be the algorithm to fix it for my board?

Thanks,
Sergey

[-- Attachment #1.2: Type: text/html, Size: 6065 bytes --]

[-- Attachment #2: kernmode_xen251_lat_avg.jpg --]
[-- Type: image/jpeg, Size: 118726 bytes --]

[-- Attachment #3: kernmode_xen251_lat_max.jpg --]
[-- Type: image/jpeg, Size: 119106 bytes --]

[-- Attachment #4: kernmode_xen251_lat_min.jpg --]
[-- Type: image/jpeg, Size: 112915 bytes --]

[-- Attachment #5: usermode_xen251_lat_avg.jpg --]
[-- Type: image/jpeg, Size: 103241 bytes --]

[-- Attachment #6: usermode_xen251_lat_max.jpg --]
[-- Type: image/jpeg, Size: 137707 bytes --]

[-- Attachment #7: usermode_xen251_lat_min.jpg --]
[-- Type: image/jpeg, Size: 164239 bytes --]

[-- Attachment #8: arch_arm.diff --]
[-- Type: text/x-patch, Size: 8319 bytes --]

diff -r /home/d.sergey/Version2_kernel/linux-xenomai251/arch/arm/include/asm/ipipe.h /home/d.sergey/Version2_kernel/linux-2.6.29-v02.00.29_new/arch/arm/include/asm/ipipe.h
90d89
< #define IPIPE_TSC_TYPE_FREERUNNING_COUNTDOWN	3
diff -r /home/d.sergey/Version2_kernel/linux-xenomai251/arch/arm/mach-mv88f6290/common.c /home/d.sergey/Version2_kernel/linux-2.6.29-v02.00.29_new/arch/arm/mach-mv88f6290/common.c
572,578d571
< #ifdef CONFIG_CACHE_FEROCEON_L2
< #ifdef CONFIG_CACHE_FEROCEON_L2_WRITETHROUGH
< 	feroceon_l2_init(1);
< #else
< 	feroceon_l2_init(0);
< #endif
< #endif
diff -r /home/d.sergey/Version2_kernel/linux-xenomai251/arch/arm/mach-mv88f6290/include/mach/irqs.h /home/d.sergey/Version2_kernel/linux-2.6.29-v02.00.29_new/arch/arm/mach-mv88f6290/include/mach/irqs.h
45,51d44
< #ifdef CONFIG_IPIPE
< #ifdef CONFIG_ARCH_MV88F6290
< #define __ipipe_mach_irq_mux_p(irq)					\
< 	((unsigned)((irq) - IRQ_MV88F6290_GPIO7_0) <=			\
< 	 IRQ_MV88F6290_GPIO31_24 - IRQ_MV88F6290_GPIO7_0)
< #endif
< #endif /* CONFIG_IPIPE */
diff -r /home/d.sergey/Version2_kernel/linux-xenomai251/arch/arm/plat-orion/gpio.c /home/d.sergey/Version2_kernel/linux-2.6.29-v02.00.29_new/arch/arm/plat-orion/gpio.c
18,19d17
< #include <linux/ipipe.h>
< #include <linux/ipipe_trace.h>
22c20
< static IPIPE_DEFINE_SPINLOCK(gpio_lock);
---
> static DEFINE_SPINLOCK(gpio_lock);
223,236c221,224
< 
< 	u32 u;
< #ifdef CONFIG_IPIPE		
< 	unsigned long flags;
< 
< 	local_irq_save_hw(flags);
< #endif	
< 	u = readl(reg);
<  	u &= ~(1 << (pin & 31));
<  	writel(u, reg);
< #ifdef CONFIG_IPIPE
< 	local_irq_restore_hw(flags);
< #endif
<  }
---
> 	u32 u = readl(reg);
> 	u &= ~(1 << (pin & 31));
> 	writel(u, reg);
> }
244,256c232,234
< 
< 	u32 u;
< #ifdef CONFIG_IPIPE		
< 	unsigned long flags;
< 
< 	local_irq_save_hw(flags);
< #endif
< 	u = readl(reg);
<  	u |= 1 << (pin & 31);
<  	writel(u, reg);
< #ifdef CONFIG_IPIPE	
< 	local_irq_restore_hw(flags);
< #endif	
---
> 	u32 u = readl(reg);
> 	u |= 1 << (pin & 31);
> 	writel(u, reg);
278,282c256
< #ifdef CONFIG_IPIPE
< 		desc->handle_irq = handle_level_irq;
< #else
<  		desc->handle_irq = handle_edge_irq;
< #endif
---
> 		desc->handle_irq = handle_edge_irq;
357,389d330
< #ifdef CONFIG_IPIPE
< 
< void __ipipe_mach_demux_irq(unsigned pinoff, struct pt_regs *regs)
< {
< 	u32 cause;
< 	int pin;
< 
< 	cause = readl(GPIO_DATA_IN(pinoff)) & readl(GPIO_LEVEL_MASK(pinoff));
< 	cause |= readl(GPIO_EDGE_CAUSE(pinoff)) & readl(GPIO_EDGE_MASK(pinoff));
< 
< 	for (pin = pinoff; pin < pinoff + 8; pin++) {
< 		int irq = pin + orion_irq_gpio_start;
< 		struct irq_desc *desc = irq_desc + irq;
< 
< 		if (!(cause & (1 << (pin & 31))))
< 			continue;
< 
< 		if ((desc->status & IRQ_TYPE_SENSE_MASK) == IRQ_TYPE_EDGE_BOTH) {
< 			/* Swap polarity (race with GPIO line) */
< 			u32 polarity;
< 
< 			polarity = readl(GPIO_IN_POL(pin));
< 			polarity ^= 1 << (pin & 31);
< 			writel(polarity, GPIO_IN_POL(pin));
< 		}
< 		ipipe_trace_irq_entry(irq);
< 		__ipipe_handle_irq(irq, regs);
< 		ipipe_trace_irq_exit(irq);
< 	}
< }
< 
< #endif /* CONFIG_IPIPE */
< 
diff -r /home/d.sergey/Version2_kernel/linux-xenomai251/arch/arm/plat-orion/irq.c /home/d.sergey/Version2_kernel/linux-2.6.29-v02.00.29_new/arch/arm/plat-orion/irq.c
20d19
< 	unsigned long flags;
23d21
< 	local_irq_save_hw(flags);
27d24
< 	local_irq_restore_hw(flags);
33d29
< 	unsigned long flags;
36d31
< 	local_irq_save_hw(flags);
40d34
< 	local_irq_restore_hw(flags);
diff -r /home/d.sergey/Version2_kernel/linux-xenomai251/arch/arm/plat-orion/time.c /home/d.sergey/Version2_kernel/linux-2.6.29-v02.00.29_new/arch/arm/plat-orion/time.c
22,34d21
<  * Reprogram the timer
<  */
< #define TIMER_CTRL			(TIMER_VIRT_BASE + 0x0000)
< #define  TIMER0_EN			0x0001
< #define  TIMER0_RELOAD_EN	0x0002
< #define  TIMER1_EN			0x0004
< #define  TIMER1_RELOAD_EN	0x0008
< #define TIMER0_RELOAD		(TIMER_VIRT_BASE + 0x0010)
< #define TIMER0_VAL			(TIMER_VIRT_BASE + 0x0014)
< #define TIMER1_RELOAD		(TIMER_VIRT_BASE + 0x0018)
< #define TIMER1_VAL			(TIMER_VIRT_BASE + 0x001c)
< 
< /*
39,85d25
< #ifdef CONFIG_IPIPE
< 
< #ifdef CONFIG_NO_IDLE_HZ
< #error "dynamic tick timer not yet supported with IPIPE"
< #endif /* CONFIG_NO_IDLE_HZ */
< 
< int __ipipe_mach_timerint;
< EXPORT_SYMBOL(__ipipe_mach_timerint);
< 
< int __ipipe_mach_timerstolen;
< EXPORT_SYMBOL(__ipipe_mach_timerstolen);
< 
< unsigned int __ipipe_mach_ticks_per_jiffy;
< EXPORT_SYMBOL(__ipipe_mach_ticks_per_jiffy);
< 
< static int orion_timer_initialized;
< 
< union tsc_reg {
< #ifdef __BIG_ENDIAN
< 	struct {
< 		unsigned long high;
< 		unsigned long low;
< 	};
< #else /* __LITTLE_ENDIAN */
< 	struct {
< 		unsigned long low;
< 		unsigned long high;
< 	};
< #endif /* __LITTLE_ENDIAN */
< 	unsigned long long full;
< };
< 
< static union tsc_reg *tsc;
< 
< void __ipipe_mach_get_tscinfo(struct __ipipe_tscinfo *info)
< {
< 	info->type = IPIPE_TSC_TYPE_FREERUNNING_COUNTDOWN;
< 	info->u.fr.counter = (unsigned *)
< 	  (TIMER0_VAL - MV88F6290_REGS_VIRT_BASE + MV88F6290_REGS_PHYS_BASE);
< 	info->u.fr.mask = 0xffffffff;
< 	info->u.fr.tsc = &tsc->full;
< }
< 
< void __ipipe_mach_acktimer(void)
< {
< 	writel(BRIDGE_INT_TIMER1_CLR, BRIDGE_CAUSE);
< }
87,163c27,38
< static void ipipe_mach_update_tsc(void)
< {
< 	unsigned long stamp, flags;
< 	union tsc_reg *local_tsc;
< 
< 	if (unlikely(!orion_timer_initialized))
< 		return;
< 
< 	local_irq_save_hw(flags);
< 	local_tsc = &tsc[ipipe_processor_id()];
< 	stamp = 0xffffffff - readl(TIMER0_VAL);
< 	if (unlikely(stamp < local_tsc->low))
< 		/* 32 bit counter wrapped, increment high word. */
< 		local_tsc->high++;
< 	local_tsc->low = stamp;
< 	local_irq_restore_hw(flags);
< }
< 
< notrace unsigned long long __ipipe_mach_get_tsc(void)
< {
< 	union tsc_reg *local_tsc, result;
< 	unsigned long stamp;
< 
< 	if (unlikely(!orion_timer_initialized))
< 		return 0;
< 
< 	local_tsc = &tsc[ipipe_processor_id()];
< 
< 	__asm__ ("ldmia %1, %M0\n" :
< 		 "=r"(result.full) : "r"(local_tsc), "m"(*local_tsc));
< 	barrier();
< 	stamp = 0xffffffff - readl(TIMER0_VAL);
< 	if (unlikely(stamp < result.low))
< 		/* 32 bit counter wrapped, increment high word. */
< 		result.high++;
< 	result.low = stamp;
< 
< 	return result.full;
< }
< EXPORT_SYMBOL(__ipipe_mach_get_tsc);
<  
<  /*
< - * Timer block registers.
< + * Reprogram the timer
<   */
< 
<  
< void __ipipe_mach_set_dec(unsigned long delay)
< {
<     u32 u;
< 	if (delay <= 3) {
< 		ipipe_trigger_irq(__ipipe_mach_timerint);
< 		return;
< 	}
< 
< 	/*
< 	 * Clear and enable clockevent timer interrupt.
< 	 */
< 	writel(BRIDGE_INT_TIMER1_CLR, BRIDGE_CAUSE);
< 
< 	u = readl(BRIDGE_MASK);
< 	u |= BRIDGE_INT_TIMER1;
< 	writel(u, BRIDGE_MASK);
< 
< 	/*
< 	 * Setup new clockevent timer value.
< 	 */
< 	writel(delay, TIMER1_VAL);
< 
< 	/*
< 	 * Enable the timer.
< 	 */
< 	u = readl(TIMER_CTRL);
< 	u = (u & ~TIMER1_RELOAD_EN) | TIMER1_EN;
< 	writel(u, TIMER_CTRL);
< }
< EXPORT_SYMBOL(__ipipe_mach_set_dec);
---
> /*
>  * Timer block registers.
>  */
> #define TIMER_CTRL		(TIMER_VIRT_BASE + 0x0000)
> #define  TIMER0_EN		0x0001
> #define  TIMER0_RELOAD_EN	0x0002
> #define  TIMER1_EN		0x0004
> #define  TIMER1_RELOAD_EN	0x0008
> #define TIMER0_RELOAD		(TIMER_VIRT_BASE + 0x0010)
> #define TIMER0_VAL		(TIMER_VIRT_BASE + 0x0014)
> #define TIMER1_RELOAD		(TIMER_VIRT_BASE + 0x0018)
> #define TIMER1_VAL		(TIMER_VIRT_BASE + 0x001c)
165,168d39
< unsigned long __ipipe_mach_get_dec(void)
< {
< 	return readl(TIMER0_VAL);
< }
170,171d40
< #endif /* CONFIG_IPIPE */
<  
286,292d154
<  
< #ifdef CONFIG_IPIPE
< int __ipipe_check_tickdev(const char *devname)
< {
< 	return !strcmp(devname, orion_clkevt.name);
< }
< #endif
299d160
< #ifndef CONFIG_IPIPE
301,303d161
< #else /* CONFIG_IPIPE */
< 	ipipe_mach_update_tsc();
< #endif
315,325d172
< #ifdef CONFIG_IPIPE
< void __ipipe_mach_release_timer(void)
< {
< 	struct clock_event_device *ckdev = &orion_clkevt;
< 	ckdev->set_mode(ckdev->mode, ckdev);
< 	if (ckdev->mode == CLOCK_EVT_MODE_ONESHOT)
< 		ckdev->set_next_event(__ipipe_mach_ticks_per_jiffy, ckdev);
< }
< EXPORT_SYMBOL(__ipipe_mach_release_timer);
< #endif
< 
347,353d193
< #ifdef CONFIG_IPIPE
< 	__ipipe_mach_timerint = irq;
< 	__ipipe_mach_ticks_per_jiffy = ticks_per_jiffy;
< 	tsc = (union tsc_reg *) __ipipe_tsc_area;
< 	barrier();
< 	orion_timer_initialized = 1;
< #endif /* CONFIG_IPIPE */

Re: [Xenomai-help] [ARM-MV88F6290] Xenomai 2.5.1 latency test results (still negative and huge)

[Gilles Chanteperdrix]

Sergey Didenko wrote:
> Hello
> 
> As a unit:
> 1) Board MV88F6290
> 2) Linux Kernel 2.6.29
> 3) Xenomai version 2.5.1
> 
> I have new latency test results for Xenomai 2.5.1!
> 
> I adjusted /proc/xenomai/latency value for kernel mode from 9503 to 5099
> (making minimum latency more close to 0)
> And there is a big difference (in comparission with xenomai 2.4.9 version)
> in case of user-mode, with xenomai 2.4.9, adjusted value was 4400, but with
> xenomai 2.5.1 I have to set it to 44300 (! 10 times bigger) to get the
> minimum latency very close to 0.
> All test for user mode I did with value /proc/xenomai/latency = 0
> All test for kernel mode I did with value /proc/xenomai/latency = 5100

I can confirm that Xenomai is working well on other ARM platforms. So,
this issue is specific to your platform. Look for the bug in your code.


-- 
					    Gilles.

Re: [Xenomai-help] [ARM-MV88F6290] Xenomai 2.5.1 latency test results (still negative and huge)

[Sergey Didenko]

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

Thank you, Gilles

1) Yeah, I understand that my application (originally written for VxWorks)
is not adapted somehow to work properly under Xenomai (the threads are
switching to secondary mode very often, for example)..ok..but, test
application is also running under xenomai and if I define the highest
priority for my test task it should show the best latency it can ever get
from Xenomai, I'm I right?
Could you please comment what kind of BUG I should try find out...in how
should I optimize my application?

2) which options you usualy use for diff command to make the proper (I mean
the format which is commonly used by Xenomai guys) diff file?

3) Do you have enough documentation where I can find the answers for my
questions?
Looks like yes, since you ignore answering the questions I asked you. Give
me the links on it then, please!

Thank you,
Sergey

On 11 February 2010 20:43, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> Sergey Didenko wrote:
> > Hello
> >
> > As a unit:
> > 1) Board MV88F6290
> > 2) Linux Kernel 2.6.29
> > 3) Xenomai version 2.5.1
> >
> > I have new latency test results for Xenomai 2.5.1!
> >
> > I adjusted /proc/xenomai/latency value for kernel mode from 9503 to 5099
> > (making minimum latency more close to 0)
> > And there is a big difference (in comparission with xenomai 2.4.9
> version)
> > in case of user-mode, with xenomai 2.4.9, adjusted value was 4400, but
> with
> > xenomai 2.5.1 I have to set it to 44300 (! 10 times bigger) to get the
> > minimum latency very close to 0.
> > All test for user mode I did with value /proc/xenomai/latency = 0
> > All test for kernel mode I did with value /proc/xenomai/latency = 5100
>
> I can confirm that Xenomai is working well on other ARM platforms. So,
> this issue is specific to your platform. Look for the bug in your code.
>
>
> --
>                                             Gilles.
>

[-- Attachment #2: Type: text/html, Size: 3426 bytes --]

Re: [Xenomai-help] [ARM-MV88F6290] Xenomai 2.5.1 latency test results (still negative and huge)

[Gilles Chanteperdrix]

Sergey Didenko wrote:
> Thank you, Gilles
> 
> 1) Yeah, I understand that my application (originally written for VxWorks)
> is not adapted somehow to work properly under Xenomai (the threads are
> switching to secondary mode very often, for example)..ok..but, test
> application is also running under xenomai and if I define the highest
> priority for my test task it should show the best latency it can ever get
> from Xenomai, I'm I right?
> Could you please comment what kind of BUG I should try find out...in how
> should I optimize my application?

The bug is not in the applications, since the application in question
(latency) is running fine on other platforms, including ARM ones. The
bug is in your port.

> 
> 2) which options you usualy use for diff command to make the proper (I mean
> the format which is commonly used by Xenomai guys) diff file?

diff -u
git diff does it just fine. And if you do not use git, you should.

> 
> 3) Do you have enough documentation where I can find the answers for my
> questions?
> Looks like yes, since you ignore answering the questions I asked you. Give
> me the links on it then, please!

I do not think there is a general documentation on how to debug code. It
really depends on what code you debug, and what are the symptoms you
observe.

-- 
					    Gilles.

Re: [Xenomai-help] [ARM-MV88F6290] Xenomai 2.5.1 latency test results (still negative and huge)

[Sergey Didenko]

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

Hi Gilles

On 13 February 2010 16:42, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> Sergey Didenko wrote:
> > Thank you, Gilles
> >
> > 1) Yeah, I understand that my application (originally written for
> VxWorks)
> > is not adapted somehow to work properly under Xenomai (the threads are
> > switching to secondary mode very often, for example)..ok..but, test
> > application is also running under xenomai and if I define the highest
> > priority for my test task it should show the best latency it can ever get
> > from Xenomai, I'm I right?
> > Could you please comment what kind of BUG I should try find out...in how
> > should I optimize my application?
>
> The bug is not in the applications, since the application in question
> (latency) is running fine on other platforms, including ARM ones. The
> bug is in your port.


Ok, than...my previous questions was like "what cause such huge latencies,
especially negative?" and there were no any hints from you on it like "what
I have to focus on to fix it" please give me some!
What is wrong with the timer or interrupts, what kind of problem is there?
Help me to understand, guys!
I'm new in this area, but I'm eager to find and solve this problem, just
give me some tips where to dig.

> 2) which options you usualy use for diff command to make the proper (I
> mean
> > the format which is commonly used by Xenomai guys) diff file?
>
> diff -u
> git diff does it just fine. And if you do not use git, you should.


I'm using git, but not so a long time to know all the beauty of it, thanks a
lot!

Thank you in advance for support.
Sergey.

[-- Attachment #2: Type: text/html, Size: 2264 bytes --]