Re: [Xenomai-core] rt_task_create and rt_task delete re-scheduling calling task

[Gilles Chanteperdrix]

On 05/14/2012 09:55 AM, Roberto Bielli wrote:
> P.S.  the imx25 now it's perfect. Was only the reentrant interrupt.

By the way, now that Linux runs all interrupt handlers with hardware irq
disabled, this option is completely useless: it will prevent a low
priority irq to interrupt a low priority irq while the high priority
interrupt handler is running, but since that handler is already running
with hardware interrupts off, this does not add anything.

-- 
Gilles.

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

Re: [Xenomai-core] rt_task_create and rt_task delete re-scheduling calling task

[Gilles Chanteperdrix]

On 05/14/2012 09:55 AM, Roberto Bielli wrote:
> Hi,
> 
> i saw in the documentation that rt_task_create and rt_task_delete should 
> re-scheduling the calling task.

rt_task_create may reschedule the calling task, only "may", not
"should". And it happens in the obvious case: when creating a task with
a higher priority than the current task.

The reason why rt_task_delete may reschedule is documented:
"Native tasks implement a mechanism by which they are immune from
deletion by other tasks while they run into a deemed safe section of
code. This feature is used internally by the native skin in order to
prevent tasks from being deleted in the middle of a critical section,
without resorting to interrupt masking when the latter is not an option.
For this reason, the caller of rt_task_delete() might be blocked and a
rescheduling take place, waiting for the target task to exit such
critical section."

Xenomai online documentation may be found here:
http://www.xenomai.org/documentation/xenomai-2.6/html/api/index.html

And a local copy is installed when you run xenomai package "make install".


-- 
Gilles.

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

Re: [Xenomai-core] porting xenomai on imx25

[Gilles Chanteperdrix]

On 04/19/2012 11:02 AM, Gilles Chanteperdrix wrote:
> On 04/19/2012 11:01 AM, Roberto Bielli wrote:
>> have you a .config for imx31 to give me so i can compare them?
> 
> http://sisyphus.hd.free.fr/~gilles/config-mx31ads-2.6.33
> 
> This said, looking at the code, I do not understand how it can break irq
> delivery.

I understand it now, yes, CONFIG_IMX_IRQ_PRIOR can not work with
CONFIG_IPIPE.

-- 
Gilles.

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

Re: [Xenomai-core] IMX25 timer access patch

[Gilles Chanteperdrix]

On 04/19/2012 01:04 PM, Michael Trimarchi wrote:
> Hi 
> On 04/19/2012 12:55 PM, Gilles Chanteperdrix wrote:
>> On 04/19/2012 12:02 PM, Michael Trimarchi wrote:
>>> Hi,
>>>
>>> I will send a proper patch. Is it possible to include in the ipipe-arm 
>>> branch?
>>>
>>> Michael
>>
>> Yes, OK. Please resend the patch to the xenomai-core, or adeos-main
>> mailing list, I see ipipe-arm is broken since at least 2.6.33. It
>> compiles but probably does not work.
>>
> 
> I will send the two patches for the imx25.

Yes, and please provide an accurate commit log: the patch fixes more
than imx25.

-- 
Gilles.

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

Re: [Xenomai-core] IMX25 timer access patch

[Gilles Chanteperdrix]

On 04/19/2012 12:02 PM, Michael Trimarchi wrote:
> Hi,
> 
> I will send a proper patch. Is it possible to include in the ipipe-arm branch?
> 
> Michael

Yes, OK. Please resend the patch to the xenomai-core, or adeos-main
mailing list, I see ipipe-arm is broken since at least 2.6.33. It
compiles but probably does not work.

-- 
Gilles.

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

Re: [Xenomai-core] IMX25 timer access patch

[Gilles Chanteperdrix]

On 04/19/2012 12:02 PM, Michael Trimarchi wrote:
> Hi,
> 
> I will send a proper patch. Is it possible to include in the ipipe-arm branch?

Please use the public mailing lists.

What exactly are you trying to fix ? What version of kernel ? The
ipipe-arm kernels are compile-tested, so, the code as is is correct
(except that maybe I did not compile-test imx25). If what you are trying
to fix is compilation for non-vanilla kernels, then the answer is no,
the ipipe-arm branches only support vanilla kernels.

-- 
Gilles.

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

Re: [Xenomai-core] porting xenomai on imx25

[Gilles Chanteperdrix]

On 04/19/2012 11:01 AM, Roberto Bielli wrote:
> have you a .config for imx31 to give me so i can compare them?

http://sisyphus.hd.free.fr/~gilles/config-mx31ads-2.6.33

This said, looking at the code, I do not understand how it can break irq
delivery.

-- 
Gilles.

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

Re: [Xenomai-core] porting xenomai on imx25

[Gilles Chanteperdrix]

On 04/19/2012 10:52 AM, Roberto Bielli wrote:
> Hi Gilles,
> 
> i found the problem that disable interrupts when execute a task.
> My kernel for imx25 uses the properties CONFIG_MXC_IRQ_PRIOR in the .config.
> This properties enable reentrant interrupts so it uses the NIMASK(normal 
> interrupt mask register ) register to disable interrupts with
> certain priority level. The interrupt of timer is disabled in that cases.
> i tried to disable this option in the kernel but i have other big 
> problems with the task and so i have to do other tests before saying the 
> conclusions.
> 
> Do you know if xenomai doesn't work with reentrant interrupts ?

Xenomai as it is will not work in that case, and this option is useless
as all interrupts handlers are executed with hardware irqs disabled, so
your best solution is to try and disable this option.

-- 
Gilles.

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

Re: [Xenomai-core] porting xenomai on imx25

[Gilles Chanteperdrix]

On 04/18/2012 12:28 PM, Roberto Bielli wrote:
> Hi Gilles,
> 
> i try to give only another accurate information.
> 
> i made another test:
> i write a xenomai driver for reading the timer and avic register and i 
> see a strange behaviour.
> when there is the problem the interrupt is NOT masqueraded in avic but 
> the timer has the interrupt not acked.

Ah, that is good news, at least now we have a clue. Note that it could
also mean that the timer has ticked, but the irq is not generated for
another reason. I think you should dump all the timer registers, and see
if anything is wrong by decoding their values with the datasheet.

A quick test also, assuming that the write to the MX3_TSTAT regiter in
gpt_irq_acknowledge may be posted, try rereading the register after
writing it.

> 
> After this i understand that now are my problems.
> Do you know somebody that can help me understanding the problem only for 
> xenomai side?

If you need someone's help, you need to give access to your board to
that person or company. Because indirect debugging is really
inefficient: look at how many mails I had to send you over how much time
to get you to do what anybody with xenomai experience would have done in
just a few hours.

-- 
Gilles.

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

Re: [Xenomai-core] porting xenomai on imx25

[Gilles Chanteperdrix]

On 04/18/2012 10:44 AM, Roberto Bielli wrote:
> Hi Gilles,
> 
> here find the answers.
> sorry for the delay.
> 
> Il 13/04/2012 15:47, Gilles Chanteperdrix ha scritto:
>> On 04/13/2012 10:44 AM, Roberto Bielli wrote:
>>> Hi Gilles,
>>>
>>> you don't feel like to repeat.
>>> I'm trying all the things that you told me and i will do all the missing
>>> test that you told me.
>> So, what is the result of running your test with unpatched Linux, but
>> with CONFIG_HIGH_RES_TIMERS enabled?
> the result is the same.
> With the base linux application and  CONFIG_HIGH_RES_TIMERS all it's ok,
> instead with xenomai application the task with less priority halt the 
> task with higher priority until it sleeps.
> I send you my .config file and the test with pthread base.

You know as well as me that this description of the problem is
inaccurate, what really happens is that the timer is programmed but does
not tick. What you have to do now is try and understand what is the
difference between the way xenomai and linux handle the timer to
understand what cause it not to work in xenomai case. If I were you, to
understand this difference, I would start by dumping all timer registers
values at the time when the problem is detected, that is, before the
timer is programmed again. But I am afraid I can not give you more help,
ultimately you are the one which is doing the port to imx25, so you are
on your own.

-- 
Gilles.

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

Re: [Xenomai-core] [PULL] rt-puts fix, mprotect testsuite

[Gilles Chanteperdrix]

On 04/04/2012 02:56 PM, Jan Kiszka wrote:
> The following changes since commit 0ef2410a2c9cf7102dead861241bd2d9957e4433:
> 
>   Mask signals in rt_print:printer_loop() (2012-04-02 00:16:41 +0200)
> 
> are available in the git repository at:
>   git://git.xenomai.org/xenomai-jki.git for-upstream
> 
> Jan Kiszka (3):
>   Append missing newline to rt_[f]puts output

Actually, only puts requires an additional newline, not fputs.

-- 
Gilles.

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

Re: [Xenomai-core] [PULL] rt-puts fix, mprotect testsuite

[Gilles Chanteperdrix]

On 04/04/2012 02:56 PM, Jan Kiszka wrote:
> The following changes since commit 0ef2410a2c9cf7102dead861241bd2d9957e4433:
> 
>   Mask signals in rt_print:printer_loop() (2012-04-02 00:16:41 +0200)
> 
> are available in the git repository at:
>   git://git.xenomai.org/xenomai-jki.git for-upstream
> 
> Jan Kiszka (3):
>   Append missing newline to rt_[f]puts output
>   testsuite: Add rt-print buffer flushes to native error paths
>   Add regression test for mprotect on pinned memory

Merged. Thanks.

-- 
Gilles.

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

Re: [Xenomai-core] porting xenomai on imx25

[Gilles Chanteperdrix]

On 04/13/2012 10:44 AM, Roberto Bielli wrote:
> Hi Gilles,
> 
> you don't feel like to repeat.
> I'm trying all the things that you told me and i will do all the missing 
> test that you told me.

So, what is the result of running your test with unpatched Linux, but
with CONFIG_HIGH_RES_TIMERS enabled?

> 
> And now this is the result of latency that i ran. It seems correct.

Is it with or without CONFIG_HIGH_RES_TIMERS?


-- 
Gilles.

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

Re: [Xenomai-core] porting xenomai on imx25

[Gilles Chanteperdrix]

On 04/12/2012 06:58 PM, Roberto Bielli wrote:
> Hi Gilles,
> 
> you tell me that you are working on imx.
> Do you know if there is a working xenomai on imx (any kernel or imx 
> version) ?

I have tested Xenomai  on imx31, imx51, imx53, imx6q. It works on these
platforms. Now, what you are doing is in fact porting xenomai on imx25,
nobody did that before you, and you are faced with a peculiarity of the
timer on this platform. What you should do is:
- try to reproduce the problem with an unpatched linux with
CONFIG_HIGH_RES_TIMERS
- or try and look at the timers registers value at the time when the bug
happens to see what is going wrong.

Also, the first thing to do when running xenomai on a new platform is to
run the "latency" test. Have you run this test?

I feel like I am starting to repeat myself, I do not know if I should
continue trying and answering you.

-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/12/2012 12:12 PM, Roberto Bielli wrote:
> Hi Gilles,
> 
> i found in my trace the function 'xnthread_timeout_handler' that is 
> called in the code where there is the problem.
> In xenomai there is a topic about that function. ( [Xenomai-core] [BUG?] 
> stalled xeno domain 
>  )
> 
> Do you think that can be a similar problem ?

No.

-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/11/2012 08:59 AM, Roberto Bielli wrote:
> Hi Gilles,
> 
> i try your workaround but nothing is changed.
> I make another test. I try to comment out all the content of 
> mxc_mask_irq() but the result is the same.
> (the mxc_mask_irq is used also for acking interrupts but is not correct 
> why it doesn't write in the processor manual)
> Do you know if there is a code over the mxc_mask_irq that disable the 
> interrupts ?
> 
> About interrupt gpio it should be a link with this behaviour ? ( i don't 
> want gpio as interrupts )

No,  I do not think it is possible. You do not get to decide whether you
want gpio as interrupts or not, the design of the board you use does.

-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/11/2012 08:59 AM, Roberto Bielli wrote:
> Hi Gilles,
> 
> i try your workaround but nothing is changed.
> I make another test. I try to comment out all the content of 
> mxc_mask_irq() but the result is the same.
> (the mxc_mask_irq is used also for acking interrupts but is not correct 
> why it doesn't write in the processor manual)
> Do you know if there is a code over the mxc_mask_irq that disable the 
> interrupts ?

mxc_mask_irq disables the interrupt at interrupt controller level.
Generally, you can not avoid to do that.

Have you tried reproducing the problem with linux configured with
CONFIG_HIGH_RES_TIMERS?


-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 02:58 PM, Roberto Bielli wrote:
> In the xenomai example the task periodic is 2ms not 200us. ( 
> rt_task_sleep( 2ms 000us 000ns ) );

sorry, I misred.

> And the 10ms is because the default system time period of the timer 
> without xenomai is ~10ms.
> So a process that execute in linux base can be re-scheduled only when 
> the timer generate an interrupt , the task makes I/O, or sleeps.

That is only if you do not use CONFIG_HIGH_RES_TIMERS, in which case you
are not in the same configuration as xenomai, and the test does not mean
anything.

> 
> 
> 
> Il 10/04/2012 14:36, Gilles Chanteperdrix ha scritto:
>> On 04/10/2012 02:33 PM, Roberto Bielli wrote:
>>> Il 10/04/2012 13:49, Gilles Chanteperdrix ha scritto:
>>>> On 04/10/2012 12:39 PM, Roberto Bielli wrote:
>>>>> Hi Gilles,
>>>>>
>>>>> i tried your code but th behavior is the same.
>>>>>
>>>>> Then i tried a linux base app and works correctly.
>>>> In the exact same conditions? With the crunching task running with
>>>> SCHED_FIFO, priority 1, and the periodic task running with SCHED_FIFO,
>>>> priority 99, and the linux real-time throttling disabled?
>>>>
>>> Yes, and i see that every LATCH ( about ~10ms ) period the task with
>>> higher priority is wakeup.
>> In the example you sent the periodic task was running with a 200us
>> period, not 10ms.
>>
> 
> 


-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 02:33 PM, Roberto Bielli wrote:
> Il 10/04/2012 13:49, Gilles Chanteperdrix ha scritto:
>> On 04/10/2012 12:39 PM, Roberto Bielli wrote:
>>> Hi Gilles,
>>>
>>> i tried your code but th behavior is the same.
>>>
>>> Then i tried a linux base app and works correctly.
>> In the exact same conditions? With the crunching task running with
>> SCHED_FIFO, priority 1, and the periodic task running with SCHED_FIFO,
>> priority 99, and the linux real-time throttling disabled?
>>
> Yes, and i see that every LATCH ( about ~10ms ) period the task with 
> higher priority is wakeup.
> So a task with lower priority is interrupted by timer interrupt and 
> reschedule the task with higher priority.
> 
You need CONFIG_HIGH_RES_TIMERS to be in the same case as xenomai.

-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 02:33 PM, Roberto Bielli wrote:
> Il 10/04/2012 13:49, Gilles Chanteperdrix ha scritto:
>> On 04/10/2012 12:39 PM, Roberto Bielli wrote:
>>> Hi Gilles,
>>>
>>> i tried your code but th behavior is the same.
>>>
>>> Then i tried a linux base app and works correctly.
>> In the exact same conditions? With the crunching task running with
>> SCHED_FIFO, priority 1, and the periodic task running with SCHED_FIFO,
>> priority 99, and the linux real-time throttling disabled?
>>
> Yes, and i see that every LATCH ( about ~10ms ) period the task with 
> higher priority is wakeup.
> So a task with lower priority is interrupted by timer interrupt and 
> reschedule the task with higher priority.
> 
The only thing I can think is that the timer interrupt in fact stays 
masked. You can try the following patch:

diff --git a/arch/arm/plat-mxc/irq.c b/arch/arm/plat-mxc/irq.c  
index 8aee763..7e4cc2e 100644   
--- a/arch/arm/plat-mxc/irq.c   
+++ b/arch/arm/plat-mxc/irq.c   
@@ -94,12 +94,14 @@ EXPORT_SYMBOL(mxc_set_irq_fiq); 
 static void mxc_mask_irq(unsigned int irq) 
 {  
__raw_writel(irq, avic_base + AVIC_INTDISNUM);  
+   __raw_readl(avic_base + AVIC_INTDISNUM);
 }  

 /* Enable interrupt number "irq" in the AVIC */
 static void mxc_unmask_irq(unsigned int irq)   
 {  
__raw_writel(irq, avic_base + AVIC_INTENNUM);   
+   __raw_readl(avic_base + AVIC_INTENNUM); 
 }  

 static struct irq_chip mxc_avic_chip = {   


If I had to debug this issue, I would look at all the timer and 
interrupt controller registers value, to see what is wrong.

You can also try the plain linux example with CONFIG_IPIPE on, but 
without CONFIG_XENOMAI.

Other than that, without access to the board, it is hard for me to 
debug further, so I am afraid you are on your own.

-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 02:33 PM, Roberto Bielli wrote:
> Il 10/04/2012 13:49, Gilles Chanteperdrix ha scritto:
>> On 04/10/2012 12:39 PM, Roberto Bielli wrote:
>>> Hi Gilles,
>>>
>>> i tried your code but th behavior is the same.
>>>
>>> Then i tried a linux base app and works correctly.
>> In the exact same conditions? With the crunching task running with
>> SCHED_FIFO, priority 1, and the periodic task running with SCHED_FIFO,
>> priority 99, and the linux real-time throttling disabled?
>>
> Yes, and i see that every LATCH ( about ~10ms ) period the task with 
> higher priority is wakeup.

In the example you sent the periodic task was running with a 200us
period, not 10ms.

-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 02:11 PM, Roberto Bielli wrote:
> Il 10/04/2012 14:06, Gilles Chanteperdrix ha scritto:
>> On 04/10/2012 02:05 PM, Roberto Bielli wrote:
>>> Hi Gilles,
>>>
>>> i added this in configure of xenomai so i pass --enable-arm-mach=imx25
>>>
>>> imx25)arch=5
>>>   tsc_type=__XN_TSC_TYPE_FREERUNNING;;
>>>
>>> Furthermore in plat-mxc/include/mach/mxc.h explain which are cpumx2 and
>>> imx25 is NOT mx2
>>> #define cpu_is_mx2()(cpu_is_mx21() || cpu_is_mx27())
>>>
>>> i don't understand a things.
>>> Does the tsc necessary to calculate correct timer period, or can i
>>> disable tsc and xenomai continue work correctly ?
>> Xenomai needs the tsc in kernel-space. Obviously, if you do not use the
>> tsc in user-space, you will not see that it is wrong. Correct physical
>> address is only needed for user-space.
>>
>>> However i cannot use tsc in my simple application. I resend the simple C
>>> application that doesn't work.
>> What do you mean you can not use the tsc in your application? What
>> happens if you use it?
>>
> If i use tsc i have no error and i read a correct value.
> 
So, it works. Good news. To know if it works as expected, you can try
the "latency" test.

Something I have not asked, could you type:
cat /proc/xenomai/timer

on the mx25 board?

-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 02:05 PM, Roberto Bielli wrote:
> Hi Gilles,
> 
> i added this in configure of xenomai so i pass --enable-arm-mach=imx25
> 
> imx25)arch=5
>  tsc_type=__XN_TSC_TYPE_FREERUNNING;;
> 
> Furthermore in plat-mxc/include/mach/mxc.h explain which are cpumx2 and 
> imx25 is NOT mx2
> #define cpu_is_mx2()(cpu_is_mx21() || cpu_is_mx27())
> 
> i don't understand a things.
> Does the tsc necessary to calculate correct timer period, or can i 
> disable tsc and xenomai continue work correctly ?

Xenomai needs the tsc in kernel-space. Obviously, if you do not use the
tsc in user-space, you will not see that it is wrong. Correct physical
address is only needed for user-space.

> 
> However i cannot use tsc in my simple application. I resend the simple C 
> application that doesn't work.

What do you mean you can not use the tsc in your application? What
happens if you use it?

-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 12:39 PM, Roberto Bielli wrote:
> Hi Gilles,
> 
> i tried your code but th behavior is the same.
> 
> Then i tried a linux base app and works correctly.

In the exact same conditions? With the crunching task running with
SCHED_FIFO, priority 1, and the periodic task running with SCHED_FIFO,
priority 99, and the linux real-time throttling disabled?

-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 12:39 PM, Roberto Bielli wrote:
> Hi Gilles,
> 
> i tried your code but th behavior is the same.
> 
> Then i tried a linux base app and works correctly.

The tsc physical address passed to user-space looks wrong.

void __ipipe_mach_get_tscinfo(struct __ipipe_tscinfo *info)
{
info->type = IPIPE_TSC_TYPE_FREERUNNING;
if (cpu_is_mx1()) {
#ifdef CONFIG_ARCH_MX1
info->u.fr.counter = (unsigned *) (TIM1_BASE_ADDR + MX1_2_TCN);
#endif
} else if (cpu_is_mx2()) {
#ifdef CONFIG_ARCH_MX2
info->u.fr.counter = (unsigned *) (GPT1_BASE_ADDR + MX1_2_TCN);
#endif
} else if (cpu_is_mx3() || cpu_is_mx25() ) {
#if defined CONFIG_ARCH_MX3 || defined CONFIG_ARCH_MX25
info->u.fr.counter = (unsigned *) (GPT1_BASE_ADDR + MX3_TCN);
#endif
}
info->u.fr.mask = 0x;
info->u.fr.tsc = &tsc->full;
}

Here cpu_is_mx2() will return true, and we will not go to cpu_is_mx25().

Are you using the tsc in user-space?

If you are passing --enable-arm-mach=mx2 to xenomai configure 
script, you are using the tsc in user-space, and it is a wonder 
how it works.

-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 11:21 AM, Roberto Bielli wrote:
> Hi Gilles,
> 
> here is my time.c

Though you have not made all the changes I suggested. Here is the time.c
I would use.

-- 
Gilles.
/*
 *  linux/arch/arm/plat-mxc/time.c
 *
 *  Copyright (C) 2000-2001 Deep Blue Solutions
 *  Copyright (C) 2002 Shane Nay (sh...@minirl.com)
 *  Copyright (C) 2006-2007 Pavel Pisa (pp...@pikron.com)
 *  Copyright (C) 2008 Juergen Beisert (ker...@pengutronix.de)
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * as published by the Free Software Foundation; either version 2
 * of the License, or (at your option) any later version.
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
 * MA 02110-1301, USA.
 */

#include 
#include 
#include 
#include 

#include 
#include 
#include 

/* defines common for all i.MX */
#define MXC_TCTL		0x00
#define MXC_TCTL_TEN		(1 << 0)
#define MXC_TPRER		0x04

/* MX1, MX21, MX27 */
#define MX1_2_TCTL_CLK_PCLK1	(1 << 1)
#define MX1_2_TCTL_IRQEN	(1 << 4)
#define MX1_2_TCTL_FRR		(1 << 8)
#define MX1_2_TCMP		0x08
#define MX1_2_TCN		0x10
#define MX1_2_TSTAT		0x14

/* MX21, MX27 */
#define MX2_TSTAT_CAPT		(1 << 1)
#define MX2_TSTAT_COMP		(1 << 0)

/* MX31, MX35, MX25 */
#define MX3_TCTL_WAITEN		(1 << 3)
#define MX3_TCTL_CLK_IPG	(1 << 6)
#define MX3_TCTL_CLK_PER	(2 << 6)
#define MX3_TCTL_FRR		(1 << 9)
#define MX3_IR			0x0c
#define MX3_TSTAT		0x08
#define MX3_TSTAT_OF1		(1 << 0)
#define MX3_TCN			0x24
#define MX3_TCMP		0x10

#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 = 0;
EXPORT_SYMBOL(__ipipe_mach_timerstolen);

unsigned int __ipipe_mach_ticks_per_jiffy = LATCH;
EXPORT_SYMBOL(__ipipe_mach_ticks_per_jiffy);

static int mxc_timer_initialized;
static unsigned mxc_min_delay;

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;
};

#ifdef CONFIG_SMP
static union tsc_reg tsc[NR_CPUS];

void __ipipe_mach_get_tscinfo(struct __ipipe_tscinfo *info)
{
	info->type = IPIPE_TSC_TYPE_NONE;
}

#else /* !CONFIG_SMP */
static union tsc_reg *tsc;

void __ipipe_mach_get_tscinfo(struct __ipipe_tscinfo *info)
{
	info->type = IPIPE_TSC_TYPE_FREERUNNING;
	if (cpu_is_mx1()) {
#ifdef CONFIG_ARCH_MX1
		info->u.fr.counter = (unsigned *) (TIM1_BASE_ADDR + MX1_2_TCN);
#endif
	} else if (cpu_is_mx2()) {
#ifdef CONFIG_ARCH_MX2
		info->u.fr.counter = (unsigned *) (GPT1_BASE_ADDR + MX1_2_TCN);
#endif
	} else if (cpu_is_mx3() || cpu_is_mx25() ) {
#if defined CONFIG_ARCH_MX3 || defined CONFIG_ARCH_MX25
		info->u.fr.counter = (unsigned *) (GPT1_BASE_ADDR + MX3_TCN);
#endif
	}
	info->u.fr.mask = 0x;
	info->u.fr.tsc = &tsc->full;
}
#endif /* !CONFIG_SMP */

static void ipipe_mach_update_tsc(void);
#endif /* CONFIG_IPIPE */

#define timer_is_v2()	(cpu_is_mx3() || cpu_is_mx25() || cpu_is_mx5())

static struct clock_event_device clockevent_mxc;
static enum clock_event_mode clockevent_mode = CLOCK_EVT_MODE_UNUSED;

static void __iomem *timer_base;

static inline void gpt_irq_disable(void)
{
	unsigned int tmp;

	if (timer_is_v2())
		__raw_writel(0, timer_base + MX3_IR);
	else {
		tmp = __raw_readl(timer_base + MXC_TCTL);
		__raw_writel(tmp & ~MX1_2_TCTL_IRQEN, timer_base + MXC_TCTL);
	}
}

static inline void gpt_irq_enable(void)
{
	if (timer_is_v2())
		__raw_writel(1<<0, timer_base + MX3_IR);
	else {
		__raw_writel(__raw_readl(timer_base + MXC_TCTL) | MX1_2_TCTL_IRQEN,
			timer_base + MXC_TCTL);
	}
}

static void gpt_irq_acknowledge(void)
{
	if (!timer_is_v2()) {
		if (cpu_is_mx1())
			__raw_writel(0, timer_base + MX1_2_TSTAT);
		else
			__raw_writel(MX2_TSTAT_CAPT | MX2_TSTAT_COMP, timer_base + MX1_2_TSTAT);
	} else
		__raw_writel(MX3_TSTAT_OF1, timer_base + MX3_TSTAT);
}

static cycle_t timer_v1_get_cycles(struct clocksource *cs)
{
	return __raw_readl(timer_base + MX1_2_TCN);
}

static cycle_t timer_v2_get_cycles(struct clocksource *cs)
{
	return __raw_readl(timer_base + MX3_TCN);
}

static struct clocksource clocksource_mxc = {
	.name		= "mxc_timer1",
	.rating		= 200,
	.read		= timer_v1_get_cycles,
	.mask		= CLOCKSOURCE_MASK(32),
	.shift		= 20,
	.flags		= CLOCK_SOURCE_IS_CONTINUOUS,
};

static int __init mxc_clocksource_init(struct clk *timer_clk)
{
	

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 11:21 AM, Roberto Bielli wrote:
> Hi Gilles,
> 
> here is my time.c

Looks fine, though I do not understand why you do not use timer_is_v2
instead of cpu_is_mx3 || cpu_is_mx25. I think the problem is elsewhere,
and I suggest you check whether linux without xenomai has or has not the
same issue.

-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 11:19 AM, Roberto Bielli wrote:
> Hi Gilles,
> 
> the steps for supporting imx25 have been:
> 1. We buy a board with imx25
> 2. Our supplier made the porting of linux 2.6.31 freescale with  imx25
> 3. we put a xenomai  2.5.6 and we have adapted for imx25. The only 
> changes is this (because imx25 registers are identical to mx3 ):
> 
> old:
> #define timer_is_v2()(cpu_is_mx3() || cpu_is_mx5())
> 
> new:
> #define timer_is_v2()(cpu_is_mx3() || cpu_is_mx25() || cpu_is_mx5())
> 

Yes, but if you use the unchanged adeos patch, it uses if (cpu_is_mx3())
in tsc and timer code, whereas it should use if (timer_is_v2()),
timer_is_v2 is not present in vanilla linux code.

-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 11:06 AM, Gilles Chanteperdrix wrote:
> On 04/10/2012 10:58 AM, Roberto Bielli wrote:
>> Hi Gilles,
>>
>> i look at the processor errata but for the imx25 there are no errata 
>> elements on timer.
> 
> It is strange that you use linux 2.6.31 on imx25: linux 2.6.31 does not
> support imx25.
> 
> The I-pipe support has not been written for imx25, so, it is entirely
> possible that you have to adapt it. See:
> http://www.xenomai.org/index.php/I-pipe:ArmPorting
> 
Latest kernels support imx25, and imx25 works like an mx3, not an mx2,
can you show me arch/arm/plat-mxc/time.c for your (undoubtedly) patched
kernel?

-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 10:58 AM, Roberto Bielli wrote:
> Hi Gilles,
> 
> i look at the processor errata but for the imx25 there are no errata 
> elements on timer.

It is strange that you use linux 2.6.31 on imx25: linux 2.6.31 does not
support imx25.

The I-pipe support has not been written for imx25, so, it is entirely
possible that you have to adapt it. See:
http://www.xenomai.org/index.php/I-pipe:ArmPorting

-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 10:58 AM, Roberto Bielli wrote:
> Hi Gilles,
> 
> i look at the processor errata but for the imx25 there are no errata 
> elements on timer.
> I see that tsc uses the same timer.
> 
> Does xenomai use the tsc for the next timer period ?

If you look at the trace, you will see that with the "timer@" event that
the timer is supposedly programmed for the right time. For instance at
-84748, the timer is programmed to tick at -83749, which is around
1000us later and is what we would expect. So, the tsc is out of the
issue. The issue is the timer.

For the third time I tell you, you should now try and reproduce the same
issue with an unpatched linux.

-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 10:43 AM, Roberto Bielli wrote:
> Hi Gilles,
> 
> I don't find the end of last __ipipe_grab_irq in the trace that i send you.
> Is it correct ?

Yes, because the timer interrupt reschedules and wakes up the periodic
task. I had a look at the timer programming events, it is true that the
timer ticks more often than it should. Generally, this is an indication
that the timer frequency is not what xenomai believe it is. xenomai idea
of the timer frequency is given by __ipipe_mach_ticks_per_jiffy. Anyway,
this should not cause the timer not to tick, only to tick it more often.

What you should do now is try and reproduce the same conditions under an
unpatched linux to see if you get the same phenomenon.

Did you have a look a the processor errata ?

-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/10/2012 10:18 AM, Roberto Bielli wrote:
> Hi Gilles,
> 
> i learned the ipipe trace that i send you but i don't unserstand why i 
> have three timer reprogramming in few useconds.
> 
> Can you explain me the behaviour ?

Can you resend the trace and give us the time where this happens?
Anyway, the timer function must work even if the timer has already been
programmed, it is normal to reprogram the timer while it has been
programmed for instance when adding or removing a timer.


-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/06/2012 06:59 PM, Roberto Bielli wrote:
> Hi Gilles,
> 
> i made all your modifies and re-read all corect register but the problem 
> is the same.

Ok. What I would do at this point is check whether linux has the same
issue. You can also check the processor errata to see if there is no
issue with the timer.

-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/06/2012 05:35 PM, Roberto Bielli wrote:
> Hi Gilles,
> 
> excuse me, but i don't understand why i have to read the register after 
> a write.
> In the imx processor manual i didn't find that behaviour.

Read again what I wrote: I do not say you "have to", I say "you may want
to", it is just a trick you may want to try, which I have already seen
solving this kind of issues. Besides, that is what the linux clockevent
driver does.

I would first try reading the status register in the
__ipipe_mach_acktimer , and if it does not fix the issue, try the
re-read trick.

-- 
Gilles.

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

Re: [Xenomai-core] [PULL] rt-puts fix, mprotect testsuite

[Gilles Chanteperdrix]

On 04/04/2012 03:12 PM, Jan Kiszka wrote:
> On 2012-04-04 15:02, Gilles Chanteperdrix wrote:
>> On 04/04/2012 02:56 PM, Jan Kiszka wrote:
>>> The following changes since commit 0ef2410a2c9cf7102dead861241bd2d9957e4433:
>>>
>>>   Mask signals in rt_print:printer_loop() (2012-04-02 00:16:41 +0200)
>>>
>>> are available in the git repository at:
>>>   git://git.xenomai.org/xenomai-jki.git for-upstream
>>>
>>> Jan Kiszka (3):
>>>   Append missing newline to rt_[f]puts output
>>>   testsuite: Add rt-print buffer flushes to native error paths
>>
>> As I said, I do not agree with calling rt_print_flush_buffers outside of
>> xenomai libs.
> 
> rt_print_flush_buffers is a Xenomai API function that we export for
> quite a while now. The rt_* functions are about explicit control when
> what is invoked, both in the native skin and in what used to be rtdk.
> Also, you can't avoid this function when you interact with libraries
> that are unwrapped.
> 
> That said, I can fix that minor issue in leaks differently if you insist.

I added rt_print_flush_buffers for xenomai 2.6.0, in order to implement
systematic wrapping of printf by the posix skin, my intent was not to
really export it. From my point of view, having to call this flush
function all over the place reveals a problem in the application. If you
use always printf or always rt_printf, you do not need to call this
function.

-- 
Gilles.

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

Re: [Xenomai-core] [PULL] rt-puts fix, mprotect testsuite

[Gilles Chanteperdrix]

On 04/04/2012 02:56 PM, Jan Kiszka wrote:
> The following changes since commit 0ef2410a2c9cf7102dead861241bd2d9957e4433:
> 
>   Mask signals in rt_print:printer_loop() (2012-04-02 00:16:41 +0200)
> 
> are available in the git repository at:
>   git://git.xenomai.org/xenomai-jki.git for-upstream
> 
> Jan Kiszka (3):
>   Append missing newline to rt_[f]puts output
>   testsuite: Add rt-print buffer flushes to native error paths

As I said, I do not agree with calling rt_print_flush_buffers outside of
xenomai libs. If you want to avoid the issue you should use rt_printf only.

-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 04/04/2012 11:29 AM, Roberto Bielli wrote:
> Hi Gilles,
> 
> i have always this big problem but the timer and the avic are programmed 
> correctly.
> There is something else but i don't know what.
> In this moment i'm doing another work but soon i want to debug that error.

It is undoubtly a timer ack/program issue. There is no other problem,
the trace is quite clear: the timer is programmed, should tick, but
does not.

I had a look at the imx code again for other reasons, what may be also
missing in __ipipe_mach_acktimer function is a read of the timer status
register. As in:

void __ipipe_mach_acktimer(void)
{
uint32_t tstat;

if (timer_is_v2())
tstat = __raw_readl(timer_base + V2_TSTAT);
else
tstat = __raw_readl(timer_base + MX1_2_TSTAT);

gpt_irq_acknowledge();
}

And put that piece of code in mxc_timer_interrupt in the #ifndef
CONFIG_IPIPE section.

You may also want to issue a register read after programming the
compare register. As in:


void __ipipe_mach_set_dec(unsigned long delay)
{
 if (delay > mxc_min_delay) {
 unsigned long tcmp;
 
 if (!timer_is_v2()) {
 tcmp = __raw_readl(timer_base + MX1_2_TCN) + delay;
 __raw_writel(tcmp, timer_base + MX1_2_TCMP);
 __raw_readl(timer_base + MX1_2_TCN);
 } else {
 tcmp = __raw_readl(timer_base + V2_TCN) + delay;
 __raw_writel(tcmp, timer_base + V2_TCMP);
 __raw_readl(timer_base + V2_TCN);
 }
 } else
 ipipe_trigger_irq(__ipipe_mach_timerint);
}

-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 03/07/2012 07:13 PM, Roberto Bielli wrote:
> Hi Gilles,
> 
> this is the trace and the test.
> 
> It seems that '__ipipe_dispatch_event' last about ~84 milliseconds with 
> disable interrupts.
> 
> 
> Thanks a lot for your time.

Hi Roberto,

any news about this issue?

Regards.

-- 
Gilles.

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

Re: [Xenomai-core] [Xenomai-git] Jan Kiszka : Add regression test for mprotect on pinned memory

[Gilles Chanteperdrix]

On 04/02/2012 04:09 PM, GIT version control wrote:
> Module: xenomai-jki
> Branch: for-upstream
> Commit: 410e90d085d21dc913f8724efafe6ae75bd3c952
> URL:
> http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=410e90d085d21dc913f8724efafe6ae75bd3c952
> 
> Author: Jan Kiszka 
> Date:   Fri Mar 30 18:06:27 2012 +0200
> 
> Add regression test for mprotect on pinned memory
> 
> This tests both the original issue of mprotect reintroducing COW pages
> to Xenomai processes as well as the recently fixed zero page corruption.
> 
> Signed-off-by: Jan Kiszka 
> +static void check_inner(const char *fn, int line, const char *msg,
> + int status, int expected)
> +{
> + if (status == expected)
> + return;
> +
> + rt_task_set_mode(T_WARNSW, 0, NULL);
> + rt_print_flush_buffers();
> (...)
> +static void check_value_inner(const char *fn, int line, const char *msg,
> +   int value, int expected)
> +{
> + if (value == expected)
> + return;
> +
> + rt_task_set_mode(T_WARNSW, 0, NULL);
> + rt_print_flush_buffers();
> (...)
> +void sigdebug_handler(int sig, siginfo_t *si, void *context)
> +{
> + unsigned int reason = si->si_value.sival_int;
> +
> + rt_print_flush_buffers();
> (...)
> +
> + rt_task_set_mode(T_WARNSW, 0, NULL);
> + rt_print_flush_buffers();

Maybe you could use posix skin's printf instead of putting calls to
rt_print_flush_buffers all over the place? I did not mean for this call
to be exported, I only added it for internal use by the posix skin.

-- 
Gilles.

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

Re: [Xenomai-core] [PATCH] Mask signals in rt_print:printer_loop()

[Gilles Chanteperdrix]

On 03/28/2012 07:39 AM, Paul Janzen wrote:
> common/rt_print: Use sigfillset to actually mask all signals for
> logging thread.  Fixes commit a6dceeb9.

Thanks, but patch fails to apply on xenomai 2.6 master branch.

-- 
Gilles.

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

Re: [Xenomai-core] xenomai-forge: round-robin scheduling in pSOS skin

[Gilles Chanteperdrix]

On 03/15/2012 08:49 PM, Ronny Meeus wrote:
> On Thu, Mar 8, 2012 at 3:30 PM, Ronny Meeus  wrote:
>> Hello
>>
>> I'm are using the xenomai-forge pSOS skin (Mercury).
>> My application is running on a P4040 (Freescale PPC with 4 cores).
>> Some code snippets are put in this mail but the complete testcode is
>> also attached.
>>
>> I have a test task that just consumes the CPU:
>>
>> int run_test = 1;
>> static void perform_work(u_long counter,u_long b,u_long c,u_long d)
>> {
>>  int i;
>>  while (run_test) {
>>for (i=0;i<10;i++);
>>(*(unsigned long*)counter)++;
>>  }
>>  while (1) tm_wkafter(1000);
>> }
>>
>> If I create 2 instances of this task with the T_SLICE option set:
>>
>>t_create("WORK",10,0,0,0,&tid);
>>t_start(tid,T_TSLICE, perform_work, args);
>>
>>
>> I see that only 1 task is consuming CPU.
>>
>> # taskset 1 ./roundrobin.exe &
>> #0"000.543| [main] SCHED_RT priorities => [1 .. 99]
>>   0"000.656| [main] SCHED_RT.99 reserved for IRQ emulation
>>   0"000.692| [main] SCHED_RT.98 reserved for scheduler-lock emulation
>> 0 -> 6602
>> 1 -> 0
>>
>> If I adapt the code so that I call in my init the threadobj_start_rr
>> function, I see that the load is equally distributed over the 2
>> threads:
>>
>> # taskset 1 ./roundrobin.exe &
>> #0"000.557| [main] SCHED_RT priorities => [1 .. 99]
>>   0"000.672| [main] SCHED_RT.99 reserved for IRQ emulation
>>   0"000.708| [main] SCHED_RT.98 reserved for scheduler-lock emulation
>> 0 -> 3290
>> 1 -> 3291
>>
>> Here are the questions:
>> - why is the threadobj_start_rr function not called from the context
>> of the init of the psos layer.
>> - why is the roundrobin implemented in this way? If the tasks would be
>> mapped on the SCHED_RR instead of the SCHED_FF the Linux scheduler
>> would take care of this.
>> On the other hand, once the threadobj_start_rr function is called from
>> my init, and I create the tasks in T_NOTSLICE mode, the time-slicing
>> is still done.
>>
>> Thanks.
>>
>> ---
>> Ronny
> 
> Any comments on this?

I am afraid you will have to wait for Philippe to have time to answer
you. I am a bit ignorant about the psos API, but most importantly
completely ignorant of the mercury. I am working on forge, but mostly
with cobalt.

-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 03/13/2012 12:44 PM, Gilles Chanteperdrix wrote:
> On 03/07/2012 07:13 PM, Roberto Bielli wrote:
>> Hi Gilles,
>>
>> this is the trace and the test.
>>
>> It seems that '__ipipe_dispatch_event' last about ~84 milliseconds with 
>> disable interrupts.
> 
> Sorry, I somehow missed this post.
> 
> I am afraid you are mis-reading the trace. The time spent in user-space
> gets accounted to __ipipe_dispatch_event, because this is the last
> instrumented function called before the return to user-space. Interrupts
> are disabled at this point, this is perfectly normal, but they are
> probably re-enabled when returning to user-space.
> 
> What is more problematic, however, is that the timer interrupt did not
> tick at -83749 like it is supposed to. If it had ticked and the
> interrupt had been disabled in user-space, you would have taken the
> interrupt at -35, when __ipipe_syscall_root gets called with interrupts on.
> 
> So, now, you have to understand why the timer interrupt did not tick. I
> suggest, when the problem happens, you look at:
> * the interrupt controller register, to see if the timer interrupt is
> still masked, if it is masked, then try first commenting out the snippet
> in arch/arm/plat-mxc/avic.c which declares mxc_mask_irq as the
> irq_mask_ack callback
> * the timer registers, to see if the timer was programmed correctly, and
> is still ticking when the issue happens.
> 

You may also want, in __ipipe_mach_set_dec, to re-read the comparator
value after writing it. Sometimes, such things are needed for the write
to register to be really taken into account.

-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 03/07/2012 07:13 PM, Roberto Bielli wrote:
> Hi Gilles,
> 
> this is the trace and the test.
> 
> It seems that '__ipipe_dispatch_event' last about ~84 milliseconds with 
> disable interrupts.

Sorry, I somehow missed this post.

I am afraid you are mis-reading the trace. The time spent in user-space
gets accounted to __ipipe_dispatch_event, because this is the last
instrumented function called before the return to user-space. Interrupts
are disabled at this point, this is perfectly normal, but they are
probably re-enabled when returning to user-space.

What is more problematic, however, is that the timer interrupt did not
tick at -83749 like it is supposed to. If it had ticked and the
interrupt had been disabled in user-space, you would have taken the
interrupt at -35, when __ipipe_syscall_root gets called with interrupts on.

So, now, you have to understand why the timer interrupt did not tick. I
suggest, when the problem happens, you look at:
* the interrupt controller register, to see if the timer interrupt is
still masked, if it is masked, then try first commenting out the snippet
in arch/arm/plat-mxc/avic.c which declares mxc_mask_irq as the
irq_mask_ack callback
* the timer registers, to see if the timer was programmed correctly, and
is still ticking when the issue happens.

-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 03/07/2012 01:59 PM, Roberto Bielli wrote:
> Hi Gilles,
> 
> we are sure that when a task execute NO INTERRUPTS arrives in interrupt 
> service routine in assembler in the kernel,
> until it sleeps. It's not a problem of secondary mode.

Show me the trace and I will believe you (approximately fourth time I ask).

-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 03/06/2012 04:35 PM, Roberto Bielli wrote:
> Hi Gilles,
> 
> about T_WARNSW i see in the /proc/xenomai/stat that my task hasn't change 
> mode (the value of MSW is 0 )
> so, it hasn't changed in secondary mode.

Or maybe it started in secondary mode and never switched mode?


-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 03/06/2012 04:14 PM, Roberto Bielli wrote:
>  Hi Gilles,
> 
> i changed the min value of the '__ipipe_mach_set_dec' but the situation
> is the same.
> I see with the scope that the task with less priority is not interrupted.

In the trace you sent, we clearly saw that it was interrupted by a timer
interrupt.

> 
> It's difficult to see with the ipipe trace the problem so i put the
> xenomai trace in the application with
> |xntrace_user_start|/|xntrace_user_stop|.
> Is the log of xenomai in the same place (/proc/ipipe/trace/max ) of ipipe ?

See the latency test for an example of usage of the I-pipe tracer in
user-space. When using latency -f the trace is available in
/proc/ipipe/trace/frozen.

What about T_WARNSW (it is the third time I ask).

Also, it would be nice if you could try a more recent version of Xenomai
and of the I-pipe patch, say 2.6.0 with the I-pipe patch for 2.6.38.

-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 03/06/2012 02:00 PM, Roberto Bielli wrote:
> Hi Gilles,
> 
> here is the new trace.

There is nothing to see on that trace. Please increase the number of
trace points, and trigger a trace when you detect a problem., the number
of trace points should be sufficient to get the timer programmation
which happens before the problem.

Also, did you try T_WANRSW ?

Please disable the configuration of you mail server which asks me to
send a receipt to each every mail you send me.

-- 
Gilles.

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

Re: [Xenomai-core] preemptive doesn't work

[Gilles Chanteperdrix]

On 03/06/2012 08:55 AM, Roberto Bielli wrote:
> Hi,
> 
> it seems that i have a big problem with preemption.  (kernel 2.6.31, arm 
> freescale imx25, xenomai 2.5.6 )
> I send a simple application that doesn't work.
> 
> The task with name 'task2ms' has higher priority than 'taskPrintf', but 
> 'taskPrintf' stop the task 'task2ms' until sleeps.
> 
> I think i have a problem with ipipe porting.
> 
> Any idea ?

Please try getting a trace with the I-pipe tracer.

-- 
Gilles.

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

[Xenomai-core] Xenomai server down

[Gilles Chanteperdrix]

Hi,

xenomai.org server will be down for maintenance during the week-end.

Regards.

-- 
Gilles.

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

Re: [Xenomai-core] high duration of __ipipe_handle_irq

[Gilles Chanteperdrix]

On 03/01/2012 07:03 PM, Roberto Bielli wrote:
> Hi,
> 
> i have this problem with xenomai ( 2.5.6 - arm freescale imx25 ):
> 
> I have a xenomai application that uses more rt_tasks, and i have a 
> strange behaviour.
> When i run my application the period of *__ipipe_handle_irq* is very 
> long ( ~3ms in some cases ) in the moment
> that come the *__ipipe_mach_timerint *interrupt and so the other 
> interrupts are very late.
> 
> Do you know something about this ?

I am sorry, but I do not understand your mail. __ipiep_handle_irq is not
periodic and this sentence:

When i run my application the period of *__ipipe_handle_irq* is very
long ( ~3ms in some cases ) in the moment
that come the *__ipipe_mach_timerint *interrupt and so the other

is not understandable.

Please try to describe your problem more clearly, or better, use the
I-pipe tracer and record a trace of the problem, and post the relevant
part of the trace here.

-- 
Gilles.

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

Re: [Xenomai-core] Built-in libxenomai dependency

[Gilles Chanteperdrix]

On 02/07/2012 05:36 PM, Jan Kiszka wrote:
> On 2012-02-07 17:28, Gilles Chanteperdrix wrote:
>> This causes a -L/usr/lib to be added on the link-edit command line,
>> which causes the link to fail by finding /usr/lib/libpthread.so instead
>> of the cross-compiler one, and fail.
> 
> How does libxenomai.la look like? Is it different from a native build?
> 
> Hmm, there must be some valid way to express library dependencies inside
> you package.

I would say it looks like a famous libtool bug all buildroot, ptxdist
and the like tools work around. So, I would tend to give up on this
issue, given that it fixes an issue not all that critical.

-- 
Gilles.

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

Re: [Xenomai-core] [PATCH] Only export required CFLAGS via xeno-config

[Gilles Chanteperdrix]

On 02/07/2012 05:20 PM, Jan Kiszka wrote:
> On 2012-02-07 17:18, Gilles Chanteperdrix wrote:
>> On 02/03/2012 03:50 PM, Jan Kiszka wrote:
>>> -Werror-implicit-function-declaration is not compatible with C++, and
>>> also decisions about -Wall and -pipe should be left to the application.
>>>
>>> Signed-off-by: Jan Kiszka 
>>
>> Had to revert this patch, it causes a build failure when cross-compiling
>> (for ARM, I do not know if it matters).
> 
> -pipe? Or a weird compiler bug? -Wsomething can't make a difference.
> 
> Jan
> 
sighandler_t not defined, so I suspect -D_GNU_SOURCE gets lost. Anyway,
I will retry this one later, am working on other issues now.

-- 
Gilles.

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

Re: [Xenomai-core] Built-in libxenomai dependency

[Gilles Chanteperdrix]

On 02/07/2012 05:22 PM, Jan Kiszka wrote:
> On 2012-02-07 17:19, Gilles Chanteperdrix wrote:
>> On 02/01/2012 09:21 PM, Gilles Chanteperdrix wrote:
>>> On 02/01/2012 04:50 PM, Jan Kiszka wrote:
>>>> On 2012-02-01 16:38, Gilles Chanteperdrix wrote:
>>>>> On 02/01/2012 04:25 PM, Jan Kiszka wrote:
>>>>>> On 2012-02-01 16:17, Gilles Chanteperdrix wrote:
>>>>>>> On 02/01/2012 03:37 PM, Jan Kiszka wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> don't remember anymore: Is there any subtle reason that prevent a
>>>>>>>> change like
>>>>>>>>
>>>>>>>> diff --git a/src/skins/native/Makefile.am 
>>>>>>>> b/src/skins/native/Makefile.am
>>>>>>>> index 39eaaed..4cc8859 100644
>>>>>>>> --- a/src/skins/native/Makefile.am
>>>>>>>> +++ b/src/skins/native/Makefile.am
>>>>>>>> @@ -22,6 +22,9 @@ libnative_la_SOURCES = \
>>>>>>>>wrappers.c \
>>>>>>>>wrappers.h
>>>>>>>>  
>>>>>>>> +libnative_la_LIBADD = \
>>>>>>>> +  ../common/libxenomai.la
>>>>>>>> +
>>>>>>>>  libnative_la_CPPFLAGS = \
>>>>>>>>@XENO_USER_CFLAGS@ \
>>>>>>>>-I$(top_srcdir)/include
>>>>>>>> diff --git a/src/skins/rtdm/Makefile.am b/src/skins/rtdm/Makefile.am
>>>>>>>> index 8ad74be..2dc0a90 100644
>>>>>>>> --- a/src/skins/rtdm/Makefile.am
>>>>>>>> +++ b/src/skins/rtdm/Makefile.am
>>>>>>>> @@ -8,6 +8,9 @@ librtdm_la_SOURCES = \
>>>>>>>>core.c \
>>>>>>>>init.c
>>>>>>>>  
>>>>>>>> +librtdm_la_LIBADD = \
>>>>>>>> +  ../common/libxenomai.la
>>>>>>>> +
>>>>>>>>  librtdm_la_CPPFLAGS = \
>>>>>>>>@XENO_USER_CFLAGS@ \
>>>>>>>>-I$(top_srcdir)/include
>>>>>>>> diff --git a/src/testsuite/latency/Makefile.am 
>>>>>>>> b/src/testsuite/latency/Makefile.am
>>>>>>>> index c772c26..6534df5 100644
>>>>>>>> --- a/src/testsuite/latency/Makefile.am
>>>>>>>> +++ b/src/testsuite/latency/Makefile.am
>>>>>>>> @@ -14,5 +14,4 @@ latency_LDFLAGS = @XENO_USER_LDFLAGS@
>>>>>>>>  latency_LDADD = \
>>>>>>>>../../skins/native/libnative.la \
>>>>>>>>../../skins/rtdm/librtdm.la \
>>>>>>>> -  ../../skins/common/libxenomai.la \
>>>>>>>>-lpthread -lm
>>>>>>>>
>>>>>>>> i.e. that we let the skin libraries depend on libxenomai and then 
>>>>>>>> remove
>>>>>>>> the explicit dependency from our binaries and the xeno-config output?
>>>>>>>> Is there some ordering issue again (we have -l before -lxenomai
>>>>>>>> in the ldflags).
>>>>>>>>
>>>>>>>> If possible, this would allow for things like dlopen("libnative.so").
>>>>>>>
>>>>>>> It allows xeno-config result to work both with dynamic and static
>>>>>>> libraries. Static libraries have no dependency system, so, when linking
>>>>>>> a program whith libnative.a for instance, without libtool, you still
>>>>>>> have to link it with libxenomai.a.
>>>>>>
>>>>>> OK, part two could stay, but the dependencies should still be added to
>>>>>> the skin libs - if possible.
>>>>>>
>>>>>>>
>>>>>>> How come you can not dlopen libnative.so, dlopening libxenomai.so before
>>>>>>> does not work?
>>>>>>
>>>>>> Dependencies of libnative on libxenomai are not resolved when you open
>>>>>> the former even if the latter is already loaded. Maybe you can do this
>>>>>> by pulling in all required symbols one by one manually, haven't tried
>>>>>> yet. But that would at least be unhandy.
>>>>>
>>>>> What about RTLD_GLOBAL ?
>>>>>
>>>>
>>>> Was possibly the reason, need to check back.
>>>>
>>>> Still, what prevents stating the existing dependency of lib on
>>>> libxenomai? The dance above would than be obsolete.
>>>
>>> The change is merged. I took the chance to check that static build still
>>> built.
>>>
>>
>> Unfortunately this change also causes a build failure when
>> cross-compiling for ARM, so, change reverted, too.
>>
> 
> Indeed unfortunate. Any pointers to logs?

This causes a -L/usr/lib to be added on the link-edit command line,
which causes the link to fail by finding /usr/lib/libpthread.so instead
of the cross-compiler one, and fail.

-- 
Gilles.

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

Re: [Xenomai-core] Built-in libxenomai dependency

[Gilles Chanteperdrix]

On 02/01/2012 09:21 PM, Gilles Chanteperdrix wrote:
> On 02/01/2012 04:50 PM, Jan Kiszka wrote:
>> On 2012-02-01 16:38, Gilles Chanteperdrix wrote:
>>> On 02/01/2012 04:25 PM, Jan Kiszka wrote:
>>>> On 2012-02-01 16:17, Gilles Chanteperdrix wrote:
>>>>> On 02/01/2012 03:37 PM, Jan Kiszka wrote:
>>>>>> Hi,
>>>>>>
>>>>>> don't remember anymore: Is there any subtle reason that prevent a
>>>>>> change like
>>>>>>
>>>>>> diff --git a/src/skins/native/Makefile.am b/src/skins/native/Makefile.am
>>>>>> index 39eaaed..4cc8859 100644
>>>>>> --- a/src/skins/native/Makefile.am
>>>>>> +++ b/src/skins/native/Makefile.am
>>>>>> @@ -22,6 +22,9 @@ libnative_la_SOURCES = \
>>>>>>  wrappers.c \
>>>>>>  wrappers.h
>>>>>>  
>>>>>> +libnative_la_LIBADD = \
>>>>>> +../common/libxenomai.la
>>>>>> +
>>>>>>  libnative_la_CPPFLAGS = \
>>>>>>  @XENO_USER_CFLAGS@ \
>>>>>>  -I$(top_srcdir)/include
>>>>>> diff --git a/src/skins/rtdm/Makefile.am b/src/skins/rtdm/Makefile.am
>>>>>> index 8ad74be..2dc0a90 100644
>>>>>> --- a/src/skins/rtdm/Makefile.am
>>>>>> +++ b/src/skins/rtdm/Makefile.am
>>>>>> @@ -8,6 +8,9 @@ librtdm_la_SOURCES = \
>>>>>>  core.c \
>>>>>>  init.c
>>>>>>  
>>>>>> +librtdm_la_LIBADD = \
>>>>>> +../common/libxenomai.la
>>>>>> +
>>>>>>  librtdm_la_CPPFLAGS = \
>>>>>>  @XENO_USER_CFLAGS@ \
>>>>>>  -I$(top_srcdir)/include
>>>>>> diff --git a/src/testsuite/latency/Makefile.am 
>>>>>> b/src/testsuite/latency/Makefile.am
>>>>>> index c772c26..6534df5 100644
>>>>>> --- a/src/testsuite/latency/Makefile.am
>>>>>> +++ b/src/testsuite/latency/Makefile.am
>>>>>> @@ -14,5 +14,4 @@ latency_LDFLAGS = @XENO_USER_LDFLAGS@
>>>>>>  latency_LDADD = \
>>>>>>  ../../skins/native/libnative.la \
>>>>>>  ../../skins/rtdm/librtdm.la \
>>>>>> -../../skins/common/libxenomai.la \
>>>>>>  -lpthread -lm
>>>>>>
>>>>>> i.e. that we let the skin libraries depend on libxenomai and then remove
>>>>>> the explicit dependency from our binaries and the xeno-config output?
>>>>>> Is there some ordering issue again (we have -l before -lxenomai
>>>>>> in the ldflags).
>>>>>>
>>>>>> If possible, this would allow for things like dlopen("libnative.so").
>>>>>
>>>>> It allows xeno-config result to work both with dynamic and static
>>>>> libraries. Static libraries have no dependency system, so, when linking
>>>>> a program whith libnative.a for instance, without libtool, you still
>>>>> have to link it with libxenomai.a.
>>>>
>>>> OK, part two could stay, but the dependencies should still be added to
>>>> the skin libs - if possible.
>>>>
>>>>>
>>>>> How come you can not dlopen libnative.so, dlopening libxenomai.so before
>>>>> does not work?
>>>>
>>>> Dependencies of libnative on libxenomai are not resolved when you open
>>>> the former even if the latter is already loaded. Maybe you can do this
>>>> by pulling in all required symbols one by one manually, haven't tried
>>>> yet. But that would at least be unhandy.
>>>
>>> What about RTLD_GLOBAL ?
>>>
>>
>> Was possibly the reason, need to check back.
>>
>> Still, what prevents stating the existing dependency of lib on
>> libxenomai? The dance above would than be obsolete.
> 
> The change is merged. I took the chance to check that static build still
> built.
> 

Unfortunately this change also causes a build failure when
cross-compiling for ARM, so, change reverted, too.

-- 
Gilles.

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

Re: [Xenomai-core] [PATCH] Only export required CFLAGS via xeno-config

[Gilles Chanteperdrix]

On 02/03/2012 03:50 PM, Jan Kiszka wrote:
> -Werror-implicit-function-declaration is not compatible with C++, and
> also decisions about -Wall and -pipe should be left to the application.
> 
> Signed-off-by: Jan Kiszka 

Had to revert this patch, it causes a build failure when cross-compiling
(for ARM, I do not know if it matters).

-- 
Gilles.

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

Re: [Xenomai-core] [RFC] Port to AT91SAM9G45

[Gilles Chanteperdrix]

On 02/07/2012 02:01 PM, Gregory CLEMENT wrote:
> Hello,
> 
> I've done the port for AT91SAM9G45 on a AT91SAM9M10G45-EK board. The
> following patch have to be applied on top of the
> adeos-ipipe-2.6.38.8-arm-1.18-04.patch patch.
> 
> I also ran latency test under heavy stress using:
> - hackbench to stress the scheduler
> - netcat to stress the Ethernet interface and generate a lot of interrupts
> - ls and dd( reading a /dev/mtdblock and writing on a tmpfs) for global stress
> 
> I join the results I had after running each latency test during 10 hours.
> 
> If the results I get seem the correct could you apply this patch in
> Xenomai?
> 
> Should I also submit this patch to adeos project?

We will merge this patch in the adeos patch, yes. Thanks. Note that
xenomai-2.6.0 provides a "dohell" command in order to generate some
load, and a "xeno-test" script which runs latency under dohell load.

Are the results obtained with or without the FCSE option enabled?

-- 
Gilles.

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

Re: [Xenomai-core] [PATCH] Only export required CFLAGS via xeno-config

[Gilles Chanteperdrix]

On 02/03/2012 04:22 PM, Gilles Chanteperdrix wrote:
> On 02/03/2012 03:50 PM, Jan Kiszka wrote:
>> -Werror-implicit-function-declaration is not compatible with C++, and
>> also decisions about -Wall and -pipe should be left to the application.
>>
>> Signed-off-by: Jan Kiszka 
>> ---
>>  configure.in |   12 ++--
>>  1 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/configure.in b/configure.in
>> index b2563ee..2185925 100644
>> --- a/configure.in
>> +++ b/configure.in
>> @@ -448,13 +448,13 @@ else
>>  fi
>>  AC_MSG_RESULT([done])
>>  
>> -dnl Common CFLAGS and LDFLAGS
>> -XENO_USER_CFLAGS="-D_GNU_SOURCE -D_REENTRANT -Wall 
>> -Werror-implicit-function-declaration -pipe"
>> -XENO_USER_LDFLAGS=
>> +dnl Exported CFLAGS and LDFLAGS, shared with internal flags
>> +XENO_USER_APP_CFLAGS="-D_GNU_SOURCE -D_REENTRANT"
>> +XENO_USER_APP_LDFLAGS=
>>  
>> -dnl Exported CFLAGS and LDFLAGS, may be enhanced per-arch below
>> -XENO_USER_APP_CFLAGS=$XENO_USER_CFLAGS
>> -XENO_USER_APP_LDFLAGS=$XENO_USER_LDFLAGS
>> +dnl Internal CFLAGS and LDFLAGS, may be enhanced per-arch below
>> +XENO_USER_CFLAGS="$XENO_USER_CFLAGS -Wall 
>> -Werror-implicit-function-declaration -pipe"
>> +XENO_USER_LDFLAGS="$XENO_USER_APP_LDFLAGS"
> 
> We do not build C++ code, so I see no problem with using flags
> incompatible with C++, and customize the flags according to our
> preferences. Now, the flags returned by xeno-config are another issue,
> if this is what you want to change, please do not change the flags used
> to compile xenomai globally.
> 
Which is exactly what your patch is doing, sorry for the noise, the
patch looks fine.

-- 
Gilles.

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

Re: [Xenomai-core] [PATCH] Only export required CFLAGS via xeno-config

[Gilles Chanteperdrix]

On 02/03/2012 03:50 PM, Jan Kiszka wrote:
> -Werror-implicit-function-declaration is not compatible with C++, and
> also decisions about -Wall and -pipe should be left to the application.
> 
> Signed-off-by: Jan Kiszka 
> ---
>  configure.in |   12 ++--
>  1 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/configure.in b/configure.in
> index b2563ee..2185925 100644
> --- a/configure.in
> +++ b/configure.in
> @@ -448,13 +448,13 @@ else
>  fi
>  AC_MSG_RESULT([done])
>  
> -dnl Common CFLAGS and LDFLAGS
> -XENO_USER_CFLAGS="-D_GNU_SOURCE -D_REENTRANT -Wall 
> -Werror-implicit-function-declaration -pipe"
> -XENO_USER_LDFLAGS=
> +dnl Exported CFLAGS and LDFLAGS, shared with internal flags
> +XENO_USER_APP_CFLAGS="-D_GNU_SOURCE -D_REENTRANT"
> +XENO_USER_APP_LDFLAGS=
>  
> -dnl Exported CFLAGS and LDFLAGS, may be enhanced per-arch below
> -XENO_USER_APP_CFLAGS=$XENO_USER_CFLAGS
> -XENO_USER_APP_LDFLAGS=$XENO_USER_LDFLAGS
> +dnl Internal CFLAGS and LDFLAGS, may be enhanced per-arch below
> +XENO_USER_CFLAGS="$XENO_USER_CFLAGS -Wall 
> -Werror-implicit-function-declaration -pipe"
> +XENO_USER_LDFLAGS="$XENO_USER_APP_LDFLAGS"

We do not build C++ code, so I see no problem with using flags
incompatible with C++, and customize the flags according to our
preferences. Now, the flags returned by xeno-config are another issue,
if this is what you want to change, please do not change the flags used
to compile xenomai globally.

-- 
Gilles.

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

Re: [Xenomai-core] Built-in libxenomai dependency

[Gilles Chanteperdrix]

On 02/01/2012 04:50 PM, Jan Kiszka wrote:
> On 2012-02-01 16:38, Gilles Chanteperdrix wrote:
>> On 02/01/2012 04:25 PM, Jan Kiszka wrote:
>>> On 2012-02-01 16:17, Gilles Chanteperdrix wrote:
>>>> On 02/01/2012 03:37 PM, Jan Kiszka wrote:
>>>>> Hi,
>>>>>
>>>>> don't remember anymore: Is there any subtle reason that prevent a
>>>>> change like
>>>>>
>>>>> diff --git a/src/skins/native/Makefile.am b/src/skins/native/Makefile.am
>>>>> index 39eaaed..4cc8859 100644
>>>>> --- a/src/skins/native/Makefile.am
>>>>> +++ b/src/skins/native/Makefile.am
>>>>> @@ -22,6 +22,9 @@ libnative_la_SOURCES = \
>>>>>   wrappers.c \
>>>>>   wrappers.h
>>>>>  
>>>>> +libnative_la_LIBADD = \
>>>>> + ../common/libxenomai.la
>>>>> +
>>>>>  libnative_la_CPPFLAGS = \
>>>>>   @XENO_USER_CFLAGS@ \
>>>>>   -I$(top_srcdir)/include
>>>>> diff --git a/src/skins/rtdm/Makefile.am b/src/skins/rtdm/Makefile.am
>>>>> index 8ad74be..2dc0a90 100644
>>>>> --- a/src/skins/rtdm/Makefile.am
>>>>> +++ b/src/skins/rtdm/Makefile.am
>>>>> @@ -8,6 +8,9 @@ librtdm_la_SOURCES = \
>>>>>   core.c \
>>>>>   init.c
>>>>>  
>>>>> +librtdm_la_LIBADD = \
>>>>> + ../common/libxenomai.la
>>>>> +
>>>>>  librtdm_la_CPPFLAGS = \
>>>>>   @XENO_USER_CFLAGS@ \
>>>>>   -I$(top_srcdir)/include
>>>>> diff --git a/src/testsuite/latency/Makefile.am 
>>>>> b/src/testsuite/latency/Makefile.am
>>>>> index c772c26..6534df5 100644
>>>>> --- a/src/testsuite/latency/Makefile.am
>>>>> +++ b/src/testsuite/latency/Makefile.am
>>>>> @@ -14,5 +14,4 @@ latency_LDFLAGS = @XENO_USER_LDFLAGS@
>>>>>  latency_LDADD = \
>>>>>   ../../skins/native/libnative.la \
>>>>>   ../../skins/rtdm/librtdm.la \
>>>>> - ../../skins/common/libxenomai.la \
>>>>>   -lpthread -lm
>>>>>
>>>>> i.e. that we let the skin libraries depend on libxenomai and then remove
>>>>> the explicit dependency from our binaries and the xeno-config output?
>>>>> Is there some ordering issue again (we have -l before -lxenomai
>>>>> in the ldflags).
>>>>>
>>>>> If possible, this would allow for things like dlopen("libnative.so").
>>>>
>>>> It allows xeno-config result to work both with dynamic and static
>>>> libraries. Static libraries have no dependency system, so, when linking
>>>> a program whith libnative.a for instance, without libtool, you still
>>>> have to link it with libxenomai.a.
>>>
>>> OK, part two could stay, but the dependencies should still be added to
>>> the skin libs - if possible.
>>>
>>>>
>>>> How come you can not dlopen libnative.so, dlopening libxenomai.so before
>>>> does not work?
>>>
>>> Dependencies of libnative on libxenomai are not resolved when you open
>>> the former even if the latter is already loaded. Maybe you can do this
>>> by pulling in all required symbols one by one manually, haven't tried
>>> yet. But that would at least be unhandy.
>>
>> What about RTLD_GLOBAL ?
>>
> 
> Was possibly the reason, need to check back.
> 
> Still, what prevents stating the existing dependency of lib on
> libxenomai? The dance above would than be obsolete.

The change is merged. I took the chance to check that static build still
built.

-- 
Gilles.

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

Re: [Xenomai-core] Built-in libxenomai dependency

[Gilles Chanteperdrix]

On 02/01/2012 04:25 PM, Jan Kiszka wrote:
> On 2012-02-01 16:17, Gilles Chanteperdrix wrote:
>> On 02/01/2012 03:37 PM, Jan Kiszka wrote:
>>> Hi,
>>>
>>> don't remember anymore: Is there any subtle reason that prevent a
>>> change like
>>>
>>> diff --git a/src/skins/native/Makefile.am b/src/skins/native/Makefile.am
>>> index 39eaaed..4cc8859 100644
>>> --- a/src/skins/native/Makefile.am
>>> +++ b/src/skins/native/Makefile.am
>>> @@ -22,6 +22,9 @@ libnative_la_SOURCES = \
>>> wrappers.c \
>>> wrappers.h
>>>  
>>> +libnative_la_LIBADD = \
>>> +   ../common/libxenomai.la
>>> +
>>>  libnative_la_CPPFLAGS = \
>>> @XENO_USER_CFLAGS@ \
>>> -I$(top_srcdir)/include
>>> diff --git a/src/skins/rtdm/Makefile.am b/src/skins/rtdm/Makefile.am
>>> index 8ad74be..2dc0a90 100644
>>> --- a/src/skins/rtdm/Makefile.am
>>> +++ b/src/skins/rtdm/Makefile.am
>>> @@ -8,6 +8,9 @@ librtdm_la_SOURCES = \
>>> core.c \
>>> init.c
>>>  
>>> +librtdm_la_LIBADD = \
>>> +   ../common/libxenomai.la
>>> +
>>>  librtdm_la_CPPFLAGS = \
>>> @XENO_USER_CFLAGS@ \
>>> -I$(top_srcdir)/include
>>> diff --git a/src/testsuite/latency/Makefile.am 
>>> b/src/testsuite/latency/Makefile.am
>>> index c772c26..6534df5 100644
>>> --- a/src/testsuite/latency/Makefile.am
>>> +++ b/src/testsuite/latency/Makefile.am
>>> @@ -14,5 +14,4 @@ latency_LDFLAGS = @XENO_USER_LDFLAGS@
>>>  latency_LDADD = \
>>> ../../skins/native/libnative.la \
>>> ../../skins/rtdm/librtdm.la \
>>> -   ../../skins/common/libxenomai.la \
>>> -lpthread -lm
>>>
>>> i.e. that we let the skin libraries depend on libxenomai and then remove
>>> the explicit dependency from our binaries and the xeno-config output?
>>> Is there some ordering issue again (we have -l before -lxenomai
>>> in the ldflags).
>>>
>>> If possible, this would allow for things like dlopen("libnative.so").
>>
>> It allows xeno-config result to work both with dynamic and static
>> libraries. Static libraries have no dependency system, so, when linking
>> a program whith libnative.a for instance, without libtool, you still
>> have to link it with libxenomai.a.
> 
> OK, part two could stay, but the dependencies should still be added to
> the skin libs - if possible.
> 
>>
>> How come you can not dlopen libnative.so, dlopening libxenomai.so before
>> does not work?
> 
> Dependencies of libnative on libxenomai are not resolved when you open
> the former even if the latter is already loaded. Maybe you can do this
> by pulling in all required symbols one by one manually, haven't tried
> yet. But that would at least be unhandy.

What about RTLD_GLOBAL ?

-- 
Gilles.

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

Re: [Xenomai-core] Built-in libxenomai dependency

[Gilles Chanteperdrix]

On 02/01/2012 03:37 PM, Jan Kiszka wrote:
> Hi,
> 
> don't remember anymore: Is there any subtle reason that prevent a
> change like
> 
> diff --git a/src/skins/native/Makefile.am b/src/skins/native/Makefile.am
> index 39eaaed..4cc8859 100644
> --- a/src/skins/native/Makefile.am
> +++ b/src/skins/native/Makefile.am
> @@ -22,6 +22,9 @@ libnative_la_SOURCES = \
>   wrappers.c \
>   wrappers.h
>  
> +libnative_la_LIBADD = \
> + ../common/libxenomai.la
> +
>  libnative_la_CPPFLAGS = \
>   @XENO_USER_CFLAGS@ \
>   -I$(top_srcdir)/include
> diff --git a/src/skins/rtdm/Makefile.am b/src/skins/rtdm/Makefile.am
> index 8ad74be..2dc0a90 100644
> --- a/src/skins/rtdm/Makefile.am
> +++ b/src/skins/rtdm/Makefile.am
> @@ -8,6 +8,9 @@ librtdm_la_SOURCES = \
>   core.c \
>   init.c
>  
> +librtdm_la_LIBADD = \
> + ../common/libxenomai.la
> +
>  librtdm_la_CPPFLAGS = \
>   @XENO_USER_CFLAGS@ \
>   -I$(top_srcdir)/include
> diff --git a/src/testsuite/latency/Makefile.am 
> b/src/testsuite/latency/Makefile.am
> index c772c26..6534df5 100644
> --- a/src/testsuite/latency/Makefile.am
> +++ b/src/testsuite/latency/Makefile.am
> @@ -14,5 +14,4 @@ latency_LDFLAGS = @XENO_USER_LDFLAGS@
>  latency_LDADD = \
>   ../../skins/native/libnative.la \
>   ../../skins/rtdm/librtdm.la \
> - ../../skins/common/libxenomai.la \
>   -lpthread -lm
> 
> i.e. that we let the skin libraries depend on libxenomai and then remove
> the explicit dependency from our binaries and the xeno-config output?
> Is there some ordering issue again (we have -l before -lxenomai
> in the ldflags).
> 
> If possible, this would allow for things like dlopen("libnative.so").

It allows xeno-config result to work both with dynamic and static
libraries. Static libraries have no dependency system, so, when linking
a program whith libnative.a for instance, without libtool, you still
have to link it with libxenomai.a.

How come you can not dlopen libnative.so, dlopening libxenomai.so before
does not work?

-- 
Gilles.

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

Re: [Xenomai-core] [PATCH] Add sigdebug unit test

[Gilles Chanteperdrix]

On 01/26/2012 05:11 PM, Jan Kiszka wrote:
> On 2012-01-26 16:52, Gilles Chanteperdrix wrote:
>> On 01/26/2012 04:06 PM, Jan Kiszka wrote:
>>> On 2012-01-26 15:55, Gilles Chanteperdrix wrote:
>>>> On 01/26/2012 11:36 AM, Jan Kiszka wrote:
>>>>> On 2012-01-25 19:05, Jan Kiszka wrote:
>>>>>> On 2012-01-25 18:44, Gilles Chanteperdrix wrote:
>>>>>>> On 01/25/2012 06:10 PM, Jan Kiszka wrote:
>>>>>>>> On 2012-01-25 18:02, Gilles Chanteperdrix wrote:
>>>>>>>>> On 01/25/2012 05:52 PM, Jan Kiszka wrote:
>>>>>>>>>> On 2012-01-25 17:47, Jan Kiszka wrote:
>>>>>>>>>>> On 2012-01-25 17:35, Gilles Chanteperdrix wrote:
>>>>>>>>>>>> On 01/25/2012 05:21 PM, Jan Kiszka wrote:
>>>>>>>>>>>>> We had two regressions in this code recently. So test all 6 
>>>>>>>>>>>>> possible
>>>>>>>>>>>>> SIGDEBUG reasons, or 5 if the watchdog is not available.
>>>>>>>>>>>>
>>>>>>>>>>>> Ok for this test, with a few remarks:
>>>>>>>>>>>> - this is a regression test, so should go to
>>>>>>>>>>>> src/testsuite/regression(/native), and should be added to the
>>>>>>>>>>>> xeno-regression-test
>>>>>>>>>>>
>>>>>>>>>>> What are unit test for (as they are defined here)? Looks a bit 
>>>>>>>>>>> inconsistent.
>>>>>>>>>
>>>>>>>>> I put under "regression" all the tests I have which corresponded to
>>>>>>>>> things that failed one time or another in xenomai past. Maybe we could
>>>>>>>>> move unit tests under regression.
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> - we already have a regression test for the watchdog called 
>>>>>>>>>>>> mayday.c,
>>>>>>>>>>>> which tests the second watchdog action, please merge mayday.c with
>>>>>>>>>>>> sigdebug.c (mayday.c also allows checking the disassembly of the 
>>>>>>>>>>>> code in
>>>>>>>>>>>> the mayday page, a nice feature)
>>>>>>>>>>>
>>>>>>>>>>> It seems to have failed in that important last discipline. Need to 
>>>>>>>>>>> check
>>>>>>>>>>> why.
>>>>>>>>>>
>>>>>>>>>> Because it didn't check the page content for correctness. But that's 
>>>>>>>>>> now
>>>>>>>>>> done via the new watchdog test. I can keep the debug output, but the
>>>>>>>>>> watchdog test of mayday looks obsolete to me. Am I missing something?
>>>>>>>>>
>>>>>>>>> The watchdog does two things: it first sends a SIGDEBUG, then if the
>>>>>>>>> application is still spinning, it sends a SIGSEGV. As far as I
>>>>>>>>> understood, you test tests the first case, and mayday tests the second
>>>>>>>>> case, so, I agree that mayday should be removed, but whatever it tests
>>>>>>>>> should be integrated in the sigdebug test.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Err... SIGSEGV is not a feature, it was the bug I fixed today. :) So 
>>>>>>>> the
>>>>>>>> test case actually specified a bug as correct behavior.
>>>>>>>>
>>>>>>>> The fallback case is in fact killing the RT task as before. But I'm
>>>>>>>> unsure right now: will this leave the system always in a clean state
>>>>>>>> behind?
>>>>>>>
>>>>>>> The test case being a test case and doing nothing particular, I do not
>>>>>>> see what could go wrong. And if something goes wrong, then it needs 
>>>>>>> fixing.
>>>>>>
>>>>>> Well, if you kill a RT task while it's running in the kernel, you risk
>>>>>> inconsistent system states (held mutexex etc.). In this case the task is
>>>>>> supposed to spin in user space. If that is always safe, let's implement
>>>>>> the test.
>>>>>
>>>>> Had a closer look: These days the two-stage killing is only useful to
>>>>> catch endless loops in the kernel. User space tasks can't get around
>>>>> being migrated on watchdog events, even when SIGDEBUG is ignored.
>>>>>
>>>>> To trigger the enforced task termination without leaving any broken
>>>>> states behind, there is one option: rt_task_spin. Surprisingly for me,
>>>>> it actually spins in the kernel, thus triggers the second level if
>>>>> waiting long enough. I wonder, though, if that behavior shouldn't be
>>>>> improved, ie. the spinning loop be closed in user space - which would
>>>>> take away that option again.
>>>>>
>>>>> Thoughts?
>>>>
>>>> You can also call in an infinite loop, a xenomais syscall which causes a
>>>> switch to primary mode, but fails.
>>>
>>> Nope, we would be migrated to secondary on xnthread_amok_p when
>>> returning to user mode. We need a true kernel loop.
>>
>> But the loop will continue, and the next call to the syscall will cause
>> the thread to re-switch to primary mode.
> 
> But the "watchdog signal pending" flag will be cleared on each
> migration, thus the watchdog will never enter the second stage.

Ok, let us forget about this test of the second stage. Please add the
code which dumps the beginning of the mayday page to the test you
propose, we will merge this and remove mayday.c.

-- 
Gilles.

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

Re: [Xenomai-core] [PATCH] Add sigdebug unit test

[Gilles Chanteperdrix]

On 01/26/2012 04:06 PM, Jan Kiszka wrote:
> On 2012-01-26 15:55, Gilles Chanteperdrix wrote:
>> On 01/26/2012 11:36 AM, Jan Kiszka wrote:
>>> On 2012-01-25 19:05, Jan Kiszka wrote:
>>>> On 2012-01-25 18:44, Gilles Chanteperdrix wrote:
>>>>> On 01/25/2012 06:10 PM, Jan Kiszka wrote:
>>>>>> On 2012-01-25 18:02, Gilles Chanteperdrix wrote:
>>>>>>> On 01/25/2012 05:52 PM, Jan Kiszka wrote:
>>>>>>>> On 2012-01-25 17:47, Jan Kiszka wrote:
>>>>>>>>> On 2012-01-25 17:35, Gilles Chanteperdrix wrote:
>>>>>>>>>> On 01/25/2012 05:21 PM, Jan Kiszka wrote:
>>>>>>>>>>> We had two regressions in this code recently. So test all 6 possible
>>>>>>>>>>> SIGDEBUG reasons, or 5 if the watchdog is not available.
>>>>>>>>>>
>>>>>>>>>> Ok for this test, with a few remarks:
>>>>>>>>>> - this is a regression test, so should go to
>>>>>>>>>> src/testsuite/regression(/native), and should be added to the
>>>>>>>>>> xeno-regression-test
>>>>>>>>>
>>>>>>>>> What are unit test for (as they are defined here)? Looks a bit 
>>>>>>>>> inconsistent.
>>>>>>>
>>>>>>> I put under "regression" all the tests I have which corresponded to
>>>>>>> things that failed one time or another in xenomai past. Maybe we could
>>>>>>> move unit tests under regression.
>>>>>>>
>>>>>>>>>
>>>>>>>>>> - we already have a regression test for the watchdog called mayday.c,
>>>>>>>>>> which tests the second watchdog action, please merge mayday.c with
>>>>>>>>>> sigdebug.c (mayday.c also allows checking the disassembly of the 
>>>>>>>>>> code in
>>>>>>>>>> the mayday page, a nice feature)
>>>>>>>>>
>>>>>>>>> It seems to have failed in that important last discipline. Need to 
>>>>>>>>> check
>>>>>>>>> why.
>>>>>>>>
>>>>>>>> Because it didn't check the page content for correctness. But that's 
>>>>>>>> now
>>>>>>>> done via the new watchdog test. I can keep the debug output, but the
>>>>>>>> watchdog test of mayday looks obsolete to me. Am I missing something?
>>>>>>>
>>>>>>> The watchdog does two things: it first sends a SIGDEBUG, then if the
>>>>>>> application is still spinning, it sends a SIGSEGV. As far as I
>>>>>>> understood, you test tests the first case, and mayday tests the second
>>>>>>> case, so, I agree that mayday should be removed, but whatever it tests
>>>>>>> should be integrated in the sigdebug test.
>>>>>>>
>>>>>>
>>>>>> Err... SIGSEGV is not a feature, it was the bug I fixed today. :) So the
>>>>>> test case actually specified a bug as correct behavior.
>>>>>>
>>>>>> The fallback case is in fact killing the RT task as before. But I'm
>>>>>> unsure right now: will this leave the system always in a clean state
>>>>>> behind?
>>>>>
>>>>> The test case being a test case and doing nothing particular, I do not
>>>>> see what could go wrong. And if something goes wrong, then it needs 
>>>>> fixing.
>>>>
>>>> Well, if you kill a RT task while it's running in the kernel, you risk
>>>> inconsistent system states (held mutexex etc.). In this case the task is
>>>> supposed to spin in user space. If that is always safe, let's implement
>>>> the test.
>>>
>>> Had a closer look: These days the two-stage killing is only useful to
>>> catch endless loops in the kernel. User space tasks can't get around
>>> being migrated on watchdog events, even when SIGDEBUG is ignored.
>>>
>>> To trigger the enforced task termination without leaving any broken
>>> states behind, there is one option: rt_task_spin. Surprisingly for me,
>>> it actually spins in the kernel, thus triggers the second level if
>>> waiting long enough. I wonder, though, if that behavior shouldn't be
>>> improved, ie. the spinning loop be closed in user space - which would
>>> take away that option again.
>>>
>>> Thoughts?
>>
>> You can also call in an infinite loop, a xenomais syscall which causes a
>> switch to primary mode, but fails.
> 
> Nope, we would be migrated to secondary on xnthread_amok_p when
> returning to user mode. We need a true kernel loop.

But the loop will continue, and the next call to the syscall will cause
the thread to re-switch to primary mode.

-- 
Gilles.

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

Re: [Xenomai-core] [PATCH] Add sigdebug unit test

[Gilles Chanteperdrix]

On 01/26/2012 11:36 AM, Jan Kiszka wrote:
> On 2012-01-25 19:05, Jan Kiszka wrote:
>> On 2012-01-25 18:44, Gilles Chanteperdrix wrote:
>>> On 01/25/2012 06:10 PM, Jan Kiszka wrote:
>>>> On 2012-01-25 18:02, Gilles Chanteperdrix wrote:
>>>>> On 01/25/2012 05:52 PM, Jan Kiszka wrote:
>>>>>> On 2012-01-25 17:47, Jan Kiszka wrote:
>>>>>>> On 2012-01-25 17:35, Gilles Chanteperdrix wrote:
>>>>>>>> On 01/25/2012 05:21 PM, Jan Kiszka wrote:
>>>>>>>>> We had two regressions in this code recently. So test all 6 possible
>>>>>>>>> SIGDEBUG reasons, or 5 if the watchdog is not available.
>>>>>>>>
>>>>>>>> Ok for this test, with a few remarks:
>>>>>>>> - this is a regression test, so should go to
>>>>>>>> src/testsuite/regression(/native), and should be added to the
>>>>>>>> xeno-regression-test
>>>>>>>
>>>>>>> What are unit test for (as they are defined here)? Looks a bit 
>>>>>>> inconsistent.
>>>>>
>>>>> I put under "regression" all the tests I have which corresponded to
>>>>> things that failed one time or another in xenomai past. Maybe we could
>>>>> move unit tests under regression.
>>>>>
>>>>>>>
>>>>>>>> - we already have a regression test for the watchdog called mayday.c,
>>>>>>>> which tests the second watchdog action, please merge mayday.c with
>>>>>>>> sigdebug.c (mayday.c also allows checking the disassembly of the code 
>>>>>>>> in
>>>>>>>> the mayday page, a nice feature)
>>>>>>>
>>>>>>> It seems to have failed in that important last discipline. Need to check
>>>>>>> why.
>>>>>>
>>>>>> Because it didn't check the page content for correctness. But that's now
>>>>>> done via the new watchdog test. I can keep the debug output, but the
>>>>>> watchdog test of mayday looks obsolete to me. Am I missing something?
>>>>>
>>>>> The watchdog does two things: it first sends a SIGDEBUG, then if the
>>>>> application is still spinning, it sends a SIGSEGV. As far as I
>>>>> understood, you test tests the first case, and mayday tests the second
>>>>> case, so, I agree that mayday should be removed, but whatever it tests
>>>>> should be integrated in the sigdebug test.
>>>>>
>>>>
>>>> Err... SIGSEGV is not a feature, it was the bug I fixed today. :) So the
>>>> test case actually specified a bug as correct behavior.
>>>>
>>>> The fallback case is in fact killing the RT task as before. But I'm
>>>> unsure right now: will this leave the system always in a clean state
>>>> behind?
>>>
>>> The test case being a test case and doing nothing particular, I do not
>>> see what could go wrong. And if something goes wrong, then it needs fixing.
>>
>> Well, if you kill a RT task while it's running in the kernel, you risk
>> inconsistent system states (held mutexex etc.). In this case the task is
>> supposed to spin in user space. If that is always safe, let's implement
>> the test.
> 
> Had a closer look: These days the two-stage killing is only useful to
> catch endless loops in the kernel. User space tasks can't get around
> being migrated on watchdog events, even when SIGDEBUG is ignored.
> 
> To trigger the enforced task termination without leaving any broken
> states behind, there is one option: rt_task_spin. Surprisingly for me,
> it actually spins in the kernel, thus triggers the second level if
> waiting long enough. I wonder, though, if that behavior shouldn't be
> improved, ie. the spinning loop be closed in user space - which would
> take away that option again.
> 
> Thoughts?

You can also call in an infinite loop, a xenomais syscall which causes a
switch to primary mode, but fails.


-- 
Gilles.

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

Re: [Xenomai-core] [PATCH] Add sigdebug unit test

[Gilles Chanteperdrix]

On 01/25/2012 06:10 PM, Jan Kiszka wrote:
> On 2012-01-25 18:02, Gilles Chanteperdrix wrote:
>> On 01/25/2012 05:52 PM, Jan Kiszka wrote:
>>> On 2012-01-25 17:47, Jan Kiszka wrote:
>>>> On 2012-01-25 17:35, Gilles Chanteperdrix wrote:
>>>>> On 01/25/2012 05:21 PM, Jan Kiszka wrote:
>>>>>> We had two regressions in this code recently. So test all 6 possible
>>>>>> SIGDEBUG reasons, or 5 if the watchdog is not available.
>>>>>
>>>>> Ok for this test, with a few remarks:
>>>>> - this is a regression test, so should go to
>>>>> src/testsuite/regression(/native), and should be added to the
>>>>> xeno-regression-test
>>>>
>>>> What are unit test for (as they are defined here)? Looks a bit 
>>>> inconsistent.
>>
>> I put under "regression" all the tests I have which corresponded to
>> things that failed one time or another in xenomai past. Maybe we could
>> move unit tests under regression.
>>
>>>>
>>>>> - we already have a regression test for the watchdog called mayday.c,
>>>>> which tests the second watchdog action, please merge mayday.c with
>>>>> sigdebug.c (mayday.c also allows checking the disassembly of the code in
>>>>> the mayday page, a nice feature)
>>>>
>>>> It seems to have failed in that important last discipline. Need to check
>>>> why.
>>>
>>> Because it didn't check the page content for correctness. But that's now
>>> done via the new watchdog test. I can keep the debug output, but the
>>> watchdog test of mayday looks obsolete to me. Am I missing something?
>>
>> The watchdog does two things: it first sends a SIGDEBUG, then if the
>> application is still spinning, it sends a SIGSEGV. As far as I
>> understood, you test tests the first case, and mayday tests the second
>> case, so, I agree that mayday should be removed, but whatever it tests
>> should be integrated in the sigdebug test.
>>
> 
> Err... SIGSEGV is not a feature, it was the bug I fixed today. :) So the
> test case actually specified a bug as correct behavior.

The bug was reproducible on ARM, for an other reason, hence the mistake.
Patch merged.

-- 
Gilles.

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

Re: [Xenomai-core] [PATCH] Add sigdebug unit test

[Gilles Chanteperdrix]

On 01/25/2012 06:10 PM, Jan Kiszka wrote:
> On 2012-01-25 18:02, Gilles Chanteperdrix wrote:
>> On 01/25/2012 05:52 PM, Jan Kiszka wrote:
>>> On 2012-01-25 17:47, Jan Kiszka wrote:
>>>> On 2012-01-25 17:35, Gilles Chanteperdrix wrote:
>>>>> On 01/25/2012 05:21 PM, Jan Kiszka wrote:
>>>>>> We had two regressions in this code recently. So test all 6 possible
>>>>>> SIGDEBUG reasons, or 5 if the watchdog is not available.
>>>>>
>>>>> Ok for this test, with a few remarks:
>>>>> - this is a regression test, so should go to
>>>>> src/testsuite/regression(/native), and should be added to the
>>>>> xeno-regression-test
>>>>
>>>> What are unit test for (as they are defined here)? Looks a bit 
>>>> inconsistent.
>>
>> I put under "regression" all the tests I have which corresponded to
>> things that failed one time or another in xenomai past. Maybe we could
>> move unit tests under regression.
>>
>>>>
>>>>> - we already have a regression test for the watchdog called mayday.c,
>>>>> which tests the second watchdog action, please merge mayday.c with
>>>>> sigdebug.c (mayday.c also allows checking the disassembly of the code in
>>>>> the mayday page, a nice feature)
>>>>
>>>> It seems to have failed in that important last discipline. Need to check
>>>> why.
>>>
>>> Because it didn't check the page content for correctness. But that's now
>>> done via the new watchdog test. I can keep the debug output, but the
>>> watchdog test of mayday looks obsolete to me. Am I missing something?
>>
>> The watchdog does two things: it first sends a SIGDEBUG, then if the
>> application is still spinning, it sends a SIGSEGV. As far as I
>> understood, you test tests the first case, and mayday tests the second
>> case, so, I agree that mayday should be removed, but whatever it tests
>> should be integrated in the sigdebug test.
>>
> 
> Err... SIGSEGV is not a feature, it was the bug I fixed today. :) So the
> test case actually specified a bug as correct behavior.
> 
> The fallback case is in fact killing the RT task as before. But I'm
> unsure right now: will this leave the system always in a clean state
> behind?

The test case being a test case and doing nothing particular, I do not
see what could go wrong. And if something goes wrong, then it needs fixing.

-- 
Gilles.

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

Re: [Xenomai-core] [PATCH] Add sigdebug unit test

[Gilles Chanteperdrix]

On 01/25/2012 05:52 PM, Jan Kiszka wrote:
> On 2012-01-25 17:47, Jan Kiszka wrote:
>> On 2012-01-25 17:35, Gilles Chanteperdrix wrote:
>>> On 01/25/2012 05:21 PM, Jan Kiszka wrote:
>>>> We had two regressions in this code recently. So test all 6 possible
>>>> SIGDEBUG reasons, or 5 if the watchdog is not available.
>>>
>>> Ok for this test, with a few remarks:
>>> - this is a regression test, so should go to
>>> src/testsuite/regression(/native), and should be added to the
>>> xeno-regression-test
>>
>> What are unit test for (as they are defined here)? Looks a bit inconsistent.

I put under "regression" all the tests I have which corresponded to
things that failed one time or another in xenomai past. Maybe we could
move unit tests under regression.

>>
>>> - we already have a regression test for the watchdog called mayday.c,
>>> which tests the second watchdog action, please merge mayday.c with
>>> sigdebug.c (mayday.c also allows checking the disassembly of the code in
>>> the mayday page, a nice feature)
>>
>> It seems to have failed in that important last discipline. Need to check
>> why.
> 
> Because it didn't check the page content for correctness. But that's now
> done via the new watchdog test. I can keep the debug output, but the
> watchdog test of mayday looks obsolete to me. Am I missing something?

The watchdog does two things: it first sends a SIGDEBUG, then if the
application is still spinning, it sends a SIGSEGV. As far as I
understood, you test tests the first case, and mayday tests the second
case, so, I agree that mayday should be removed, but whatever it tests
should be integrated in the sigdebug test.

-- 
Gilles.

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

Re: [Xenomai-core] [PATCH] Add sigdebug unit test

[Gilles Chanteperdrix]

On 01/25/2012 05:21 PM, Jan Kiszka wrote:
> We had two regressions in this code recently. So test all 6 possible
> SIGDEBUG reasons, or 5 if the watchdog is not available.

Ok for this test, with a few remarks:
- this is a regression test, so should go to
src/testsuite/regression(/native), and should be added to the
xeno-regression-test
- we already have a regression test for the watchdog called mayday.c,
which tests the second watchdog action, please merge mayday.c with
sigdebug.c (mayday.c also allows checking the disassembly of the code in
the mayday page, a nice feature)
- please make the watchdog test mandatory by default (adding a command
line option to skip it for instance), the test should fail if the
watchdog is not enabled, because otherwise, it will be easy to forget
testing this feature. The wathdog is enabled by default with xenomai 2.6
anyway.

-- 
Gilles.

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

Re: [Xenomai-core] [PATCH] nucleus: Fix relaxed owner check

[Gilles Chanteperdrix]

On 01/19/2012 05:56 PM, Jan Kiszka wrote:
> Fix a logic inversion introduced by b75cec1938. This both allows the
> relaxed-owner check to work again and prevents that we enter an endless
> signal storm if XNSWREP happens to be set already at this point (as seen
> in the field).

Applied, thanks.


-- 
Gilles.

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

Re: [Xenomai-core] __xnpod_schedule not getting called

[Gilles Chanteperdrix]

On 01/18/2012 01:33 PM, Neri Marschik wrote:
> Hi there Xenomai community,
> 
> I am implementing a new scheduler for some project and came up with a
> question. Maybe it's a beginners question based on a misunderstanding.
> 
> If I don't have a periodic task my "pick" function is not getting
> called.
> 
> I put some prints into the code to see what happens:
> 
> VirtualBox kernel: [ 1052.038250] __xnpod_schedule
> VirtualBox kernel: [ 1052.038252] xnsched_pick_next
> VirtualBox kernel: [ 1052.038253] __xnsched_anytime_exception_pick()
> VirtualBox kernel: [ 1052.038255] __xnsched_anytime_main_pick()
> VirtualBox kernel: [ 1052.038257] __xnsched_idle_pick()
> VirtualBox kernel: [ 1052.038690] __xnpod_schedule
> 
> This is normal behavior which repeats forever as long as there is some
> periodic task running. 
> If I stop this periodic task my non-periodic tasks which should be run
> only once are never run because the pick() function is not called
> again. 
> 
> I noticed that __xnpod_schedule doesn't get called because of this:
> 
>   if (testbits(sched->status,
>XNKCOUT|XNINIRQ|XNSWLOCK|XNRESCHED) != XNRESCHED)
>   return;
> 
> in: pod.h static inline void xnpod_schedule(void)
> 
> I'd appreciate if anyone has an idea about that.
> 
> Btw. running version 2.5.5.2

Do you reproduce the same behaviour with xenomai 2.5.6?

-- 
Gilles.

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

Re: [Xenomai-core] realtime pipes

[Gilles Chanteperdrix]

On 01/15/2012 01:36 PM, Jan-Erik Lange wrote:
> 
> Hello,
> 
> it is possible to access a real-time pipe /dev/rtpx within the kernel
> space of Linux? Since there is no open function?

Real-time pipes are deprecated.

> 
> Is it therefore possible to communicate between the Xenomai Kernel
> space and the Linux Kernel space?

As mentioned several time, using anything else in kernel-space than the
RTDM API is deprecated. If you are interested in the services the RTDM
api offers, see:

http://www.xenomai.org/documentation/xenomai-2.6/html/api/group__driverapi.html

For instance, you can see a section named "non-real-time signalling
services", which probably answers your question.

-- 
Gilles.

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

Re: [Xenomai-core] Question on preempting a linux task

[Gilles Chanteperdrix]

On 01/12/2012 04:58 PM, Jan-Erik Lange wrote:
> 
> Hello,
> 
> Does the Xenomai scheduler has to interact with the Linux sheduler in
> order to preempt the tasks which are managed by it? Or is the Xenomai
> scheduler repealing the whole linux scheduler when it wants to run a
> task and and linux is running a task?
> 
> Best regards Jan

No, xenomai may preempt linux in the middle of almost anything, that is
the whole point of being based on the adeos patch. However, when a task
needs to change scheduler, the two schedulers have to cooperate. If you
are interested in the details, see xnshadow_relax and xnshadow_harden in
ksrc/nucleus/shadow.c in xenomai sources.

-- 
Gilles.

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

Re: [Xenomai-core] FW: Question about context switching

[Gilles Chanteperdrix]

On 01/12/2012 02:36 PM, Jan-Erik Lange wrote:
> 
> 
> 
> 
> 
> 
>> Date: Wed, 11 Jan 2012 20:03:25 +0100 From:
>> gilles.chanteperd...@xenomai.org To: jan0...@hotmail.de CC:
>> xenomai-core@gna.org Subject: Re: [Xenomai-core] Question about
>> context switching
>> 
>> On 01/11/2012 07:12 PM, Jan-Erik Lange wrote:
>>> 
>>> Hello,
>>> 
>>> I have a question about the context switching:
>>> 
>>> Unless that there a rtdm_copy_to_user() available in the rtdm
>>> API. Would cause the function copy_to_user() in an xenomai kernel
>>> based rt task a switch into the secondary domain? Because
>>> copy_to_user() not actually a syscall right?
>> 
>> Absolutely no function in kernel-space causes an automatic switch
>> to secondary mode. As Philippe answered to the very first mail you
>> posted to this list, the only events which cause a switch to
>> secondary mode are:
>> 
>> - invoking a regular linux syscall - receiving a linux signal (e.g.
>> kill(2) and GDB) - causing a CPU trap (e.g. invalid memory access),
>> hitting a breakpoint (e.g. GDB)
>> 
>> All these events only happen for threads in user-space.
> 
> Sorry I'm new in Xenomai.
> 
> But is it generaly possible that the xenomai kernel-space task can
> interact with a common Linux task over this way? I mean is it
> possible to get data with the standard copy_to_user()-function from
> the Xenomai kernel-space into the Linux user space? Aren't the adress
> spaces strictly seperated and you have to need the rt-pipe service to
> interact between the xenomai kernel space and the linux userspace?

drivers should use rtdm_copy_to_user. As most linux kernel services,
copy_to_user/copy_from_user may not be safe to be used in primary mode
(depending on the architecture). A xenomai kernel-space task has no
user-space mapping, so it has no reason to use these services.

Whether the address space are strictly separated depend on the
architecture and implementation of linux on that archietcture. On some
architectures (think uclinux for instance), the user-space/kernel-space
division is simply the division between the addresses below 0xC000
and the adresses above.

-- 
Gilles.

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

Re: [Xenomai-core] Question about context switching

[Gilles Chanteperdrix]

On 01/11/2012 07:12 PM, Jan-Erik Lange wrote:
> 
> Hello,
> 
> I have a question about the context switching:
> 
> Unless that there a rtdm_copy_to_user() available in the rtdm API.
> Would cause the function copy_to_user() in an xenomai kernel based rt
> task a switch into the secondary domain? Because copy_to_user() not
> actually a syscall right?

Absolutely no function in kernel-space causes an automatic switch to
secondary mode. As Philippe answered to the very first mail you posted
to this list, the only events which cause a switch to secondary mode are:

- invoking a regular linux syscall
- receiving a linux signal (e.g. kill(2) and GDB)
- causing a CPU trap (e.g. invalid memory access), hitting a breakpoint
(e.g. GDB)

All these events only happen for threads in user-space.

-- 
Gilles.

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

Re: [Xenomai-core] Questio about the Xenomai Scheduler

[Gilles Chanteperdrix]

On 01/08/2012 01:06 PM, Jan-Erik Lange wrote:
> 
> Is it perhaps this way?:
> 
> When the RT-Task migrated into the secondary domain, it is scheduled
> by the Linux-Scheduler:
> 
> -> It inherits the RT-priority from her life in the primary domain
> and is timely priviliged compared to other tasks scheduled by the
> linux scheduler, which have a lower priority.

No, a linux task with a higher priority than the RT task running in
secondary mode may preempt the RT task running in secondary mode.

> -> But it can always be
> preempted by an RT-Task, that runs in the primary domain and that is
> scheduled by the Xenomai Scheduler, because this scheduler can
> preempt all standard linux kernel activities. 

Yes if root priority inheritance is disabled, not if it is enabled (the
default).

> -> Still it is
> protected from preempting by an Linux interrupt handler, because the
> I-Pipe is block the interrupts.

No, this used to be true a long time ago, but is no longer the case.

You have to consider that an RT task running in secondary mode is an
ordinary linux task. Only tasks remaining in primary mode are deterministic.

-- 
Gilles.

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

Re: [Xenomai-core] Ipipe breaks my MPC8541 board boot

[Gilles Chanteperdrix]

On 01/03/2012 06:49 PM, Jean-Michel Hautbois wrote:
> cpm2_cascade is dedicated to my board, but has nothing impressive :
> static void cpm2_cascade(unsigned int irq, struct irq_desc *desc)
> {
> int cascade_irq;
> 
> while ((cascade_irq = cpm2_get_irq()) >= 0)
> generic_handle_irq(cascade_irq);

Replace generic_handle_irq with ipipe_handle_chained_irq.

-- 
Gilles.

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

Re: [Xenomai-core] user and kernel space

[Gilles Chanteperdrix]

On 01/01/2012 01:56 PM, Jan-Erik Lange wrote:
> 
> 
> 
> 
>> Date: Sat, 31 Dec 2011 16:32:20 +0100 From:
>> gilles.chanteperd...@xenomai.org To: jan0...@hotmail.de CC:
>> xenomai-core@gna.org Subject: Re: [Xenomai-core] user and kernel
>> space
>> 
>> On 12/31/2011 12:18 PM, Jan-Erik Lange wrote:
>>> 
>>> Hello,
>>> 
>>> I have a question concerning user space and kernel space. I'm
>>> dealing with the native API and I read, that this API provides
>>> the same funtkions for both kernel and user space.
>>> 
>>> When looking at the sourcecode of buffer.h for example, there I
>>> find a section called public interface. When looking at the
>>> function rt_buffer_create(); for example, how does the
>>> Implementation von this function in userspace differs to the
>>> implementation for this function kernel space? Or is it the same
>>> implementation for user and kernel space.
>> 
>> For most services such as buffer services, user functions emit
>> system calls which implementation in kernel-space use the
>> corresponding kernel service.
>> 
>> There are some exceptions such as mutexes implementation where we
>> try hard to avoid system calls and so provide both a user-space 
>> implementation and a kernel-space implementation.
> 
> 
> Ok, but the names of the API function are the same for user and
> kernel space. How is it realized to take the implementation A for
> kernel space and the implementation B for userspace? Is this realzied
> in the linking process?

Yes, kernel and user-space are separated execution space, there is no
possible confusion.

-- 
Gilles.

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

Re: [Xenomai-core] [PATCH] Threads without names confuse rtps

[Gilles Chanteperdrix]

On 12/31/2011 09:01 AM, Christophe Blaess wrote:
> If a Xenomai thread is created with a NULL name parameter, this way:

Applied, thanks.

-- 
Gilles.

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

Re: [Xenomai-core] user and kernel space

[Gilles Chanteperdrix]

On 12/31/2011 12:18 PM, Jan-Erik Lange wrote:
> 
> Hello,
> 
> I have a question concerning user space and kernel space. I'm dealing
> with the native API and I read, that this API provides the same
> funtkions for both kernel and user space.
> 
> When looking at the sourcecode of buffer.h for example, there I find
> a section called public interface. When looking at the function
> rt_buffer_create(); for example, how does the Implementation von this
> function in userspace differs to the implementation for this function
> kernel space? Or is it the same implementation for user and kernel
> space.

For most services such as buffer services, user functions emit system
calls which implementation in kernel-space use the corresponding kernel
service.

There are some exceptions such as mutexes implementation where we try
hard to avoid system calls and so provide both a user-space
implementation and a kernel-space implementation.

Another exception is the __xn_rdtsc() function, which relies on most
platforms on the same mechanism in user and kernel-space to access the
machine high resolution counter, and so has an identical implementation.


-- 
Gilles.

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

Re: [Xenomai-core] [PATCH] rtdm: add rtdm_printk_ratelimited

[Gilles Chanteperdrix]

On 11/17/2011 12:56 PM, Wolfgang Grandegger wrote:
> This patch implements a real-time safe rate-limited message printing
> on kernel console similar to Linux's printk_ratelimited.

Applied, thanks.

-- 
Gilles.

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

Re: [Xenomai-core] Xenomai 2.6.0 in Debian

[Gilles Chanteperdrix]

On 11/06/2011 11:11 PM, Roland Stigge wrote:
> Hi,
> 
> thanks for Xenomai 2.6.0!
> 
> I'm attaching a patch that's helpful for the integration of Xenomai in
> Debian (and FHS compliant systems in general), moving the architecture
> dependent test programs from /usr/share to /usr/lib.
> 

Applied, thanks.

-- 
Gilles.

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

[Xenomai-core] Xenomai v2.6.0

[Gilles Chanteperdrix]

Hi,

please find Xenomai 2.6.0 at the usual place:
http://download.gna.org/xenomai/stable/xenomai-2.6.0.tar.bz2

This new branch started as a reboot of the v2.5 branch, for changes
which needed breaking the ABI, said changes being:
* a correct handling of signals when waiting for condition variables;

* a change in the way thread mode is accessed in user-space, to fix
possible leaks depending on the libc;

* the automatic switch back to secondary mode after a primary mode
system call, for threads running with SCHED_OTHER scheduling policy,
except when they hold a mutex.


However, at this chance, we also included some new features to this release:
* support for a new architecture: sh4;

* CLOCK_HOST_REALTIME, a clock synchronized with Linux CLOCK_REALTIME
clock, safe to be read when in primary mode;

* new analogy drivers for NI 660x and NI 670x boards;

* a simplified user-space configuration for the ARM architecture, where
the default user-space libraries generated are no longer generated for
only one SOC, without any loss of performance;

* a simplified xeno-test script, which should now work more reliably,
and is based on a "xeno-test-run" interpreter, which will allow to write
different test scenarios;

* the beginnings of a regression test suite;

* a move of the rtdk library to the common "libxenomai" library,
allowing to have printf being rt-safe when using the posix skin;

* pkg-config support, each skin library is available as
"libxenomai_skin" pkg-config package;

* and the usual amount of upgrades and adeos patches to follow the linux
kernel changes.

Enjoy.

-- 
Gilles.

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

Re: [Xenomai-core] iMX25 problem with gpio and xenomai

[Gilles Chanteperdrix]

On 11/02/2011 02:39 PM, Roberto Bielli wrote:
> Hi,
> 
> i'm doing the porting of xenomai version 2.5.6 on imx25 board and i'm 
> looking to start from imx27.
> I have some problem with gpio. It seems there are spurious interrupts.
> I would know what xenomai want to know about interrupts (i see 
> ipipe_handle_irq_cond in gpio handler, is it needed ?) and registry save 
> (spin_lock_irqsave  in mxc_gpio_set etc...)

Please start from
http://download.gna.org/adeos/patches/v2.6/arm/adeos-ipipe-2.6.38.8-arm-1.18-03.patch

And tell us if you have problems with this patch.

-- 
Gilles.

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

Re: [Xenomai-core] CPU utilization question

[Gilles Chanteperdrix]

On 10/25/2011 04:18 PM, makarand pradhan wrote:
> [MP]: Yes. I've noticed that the sum of all tasks is always 100. My
> question was specifically about a xenomai task that transitions in
> secondary.
> 
> e.g. Assume a xenomai task that uses a total of 20% CPU. Of this
> assume that 10% is spent executing system calls in secondary domain
> and 10% is spent in the primary domain. I believe that from an
> accounting perspective, 10% would get accounted against ROOT and the
> xenomai task will show a CPU util of 10%. Is this accurate?

Yes.

-- 
Gilles.

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

Re: [Xenomai-core] CPU utilization question

[Gilles Chanteperdrix]

On 10/25/2011 12:19 AM, makarand pradhan wrote:
> (...) I'm
> assuming that the ROOT thread captures the %CPU spent in
> Linux/secnodary and each xenomai thread listed, captures the %CPU in
> primary domain. If a thread transitions to the secondary, then I'm
> assuming that the %util in secondary domain will get accounted
> against ROOT and the actual % usage in primary will get accounted
> against the thread.

You are assuming wrong, the CPU utilization measures the activity of the
linux kernel as a whole, including its idle task. So, the sum of all the
primary mode tasks and of the ROOT task is always 100%.

> Question:
> 
> If the linux process is sleeping, why do I see a CPU util against the
> process? Why is the CPU % util vary based on the activity I do in the
> primary domain?

rt_printf is a primary mode service which causes activity in secondary
mode: the actual printf is done by a plain linux task.


-- 
Gilles.

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

Re: [Xenomai-core] some problems with interrupts

[Gilles Chanteperdrix]

On 10/24/2011 12:14 PM, Roberto Bielli wrote:
> Hi,
> 
> i installed the patch 'adeos-ipipe-2.6.31-arm-1.16-02.patch' on a kernel 
> 2.6.31 for imx257 processor.
> I have a xenomai complex application that read touchscreen events with 
> tslib when pressed.
> In the kernel log i try these lines: ( the read job is made in a 
> not-realtime thread )
> 
> [ cut here ]
> WARNING: at drivers/input/touchscreen/mxc_tsc.c:599 
> mxc_tsc_interrupt+0x19c/0x30c [mxc_tsc]()
> (...)
> 
> Do you know the meaning in xenomai of this error (so i can modify 
> something to resolve the problem )?

This looks more like a warning than an error. At first glance, it has
nothing to do with xenomai. Besides, you seem not to be using a mainline
version of the kernel, because in the versions I have, there is no
drivers/input/touchscreen/mxc_tsc.c, so, it is hard for me to debug this
issue.

What has file drivers/input/touchscreen/mxc_tsc.c on line 599?

You may want to try a more recent version, as linux 2.6.31 starts being
seriously outdated.

-- 
Gilles.

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

[Xenomai-core] Xenomai 2.6.0-rc5

[Gilles Chanteperdrix]

Hi,

Xenomai 2.6.0-rc5 is available at the usual place:
http://download.gna.org/xenomai/testing/xenomai-2.6.0-rc5.tar.bz2

The major change since 2.6.0-rc4 is in analogy drivers sources. A new
patch for the ARM architecture was also added, for kernel 2.6.38,
including patches for imx51 and imx53 using the freescale linux-2.6-imx
git. And finally there are a few minor fixes and cosmetic changes here
and there.

Here is the shortlog:
Alexis Berlemont (1):
  analogy: quick fix to keep the async buffer below 4GB

Daniele Nicolodi (3):
  build: restore building of xeno-config man page
  testsuite: add missing include
  analogy: [ni_pcimio] replace noisy info messages by debug ones

Gilles Chanteperdrix (15):
  wrappers: fix compilation of HOSTRT without TICKDEV
  arm: fix context switch for linux 2.6.38
  testsuite: fix xeno-regression-test help string
  native: free buffer outside critical section in rt_buffer_delete
  arm: fix leftover from 392989f410f10ffc228b974ffe26787dff0734f2
  arm: change help message for --enable-arm-tsc option
  nucleus: change default configuration
  testsuite: fix regression tests location
  Merge remote branch 'alex/analogy'
  arm: upgrade patches
  psos: long/short names issue, take #2
  doc: fix README.INSTALL
  testsuite: various fixes
  build: bootstrap
  doc: regenerate

Regards.

-- 
Gilles.

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

Re: [Xenomai-core] [PULL] KVM awareness / tiny cleanup

[Gilles Chanteperdrix]

On 10/14/2011 01:20 PM, Jan Kiszka wrote:
> The following changes since commit 31bdadef9018de586bc3fe8de0f37b62b2507785:
> 
>   testsuite: fix regression tests location (2011-10-14 01:46:08 +0200)
> 
> are available in the git repository at:
>   git://git.xenomai.org/xenomai-jki.git for-upstream
> 
> Jan Kiszka (2):
>   nucleus: Privatize __xnpod_reset_thread

Are we sure that we do not have any out-of-tree users for this feature?

-- 
Gilles.

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

Re: [Xenomai-core] [PATCH xenomai-head] testsuite: fix compiler error 'SIGALRM, undeclared'

[Gilles Chanteperdrix]

On 10/12/2011 01:04 PM, Daniele Nicolodi wrote:
> On 12/10/11 12:59, Gilles Chanteperdrix wrote:
>> On 10/12/2011 11:44 AM, Wolfgang Grandegger wrote:
>>> Signed-off-by: Wolfgang Grandegger 
>>> ---
>>>  src/testsuite/regression/posix/leaks.c |1 +
>>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/src/testsuite/regression/posix/leaks.c 
>>> b/src/testsuite/regression/posix/leaks.c
>>> index 7326572..f9dd34d 100644
>>> --- a/src/testsuite/regression/posix/leaks.c
>>> +++ b/src/testsuite/regression/posix/leaks.c
>>> @@ -6,6 +6,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  
>>>  #include 
>>
>> Applied, thanks.
>>
> 
> Wans't that the same error fixed by commit
> aa44db3d5ee270c3b92a1017f7c136ffa1e2cc4d?

Indeed.

-- 
Gilles.

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

Re: [Xenomai-core] [PATCH xenomai-head] testsuite: fix compiler error 'SIGALRM, undeclared'

[Gilles Chanteperdrix]

On 10/12/2011 11:44 AM, Wolfgang Grandegger wrote:
> Signed-off-by: Wolfgang Grandegger 
> ---
>  src/testsuite/regression/posix/leaks.c |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/src/testsuite/regression/posix/leaks.c 
> b/src/testsuite/regression/posix/leaks.c
> index 7326572..f9dd34d 100644
> --- a/src/testsuite/regression/posix/leaks.c
> +++ b/src/testsuite/regression/posix/leaks.c
> @@ -6,6 +6,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 

Applied, thanks.

-- 
Gilles.

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

Re: [Xenomai-core] patch: testsuite: add missing include

[Gilles Chanteperdrix]

On 10/04/2011 03:37 PM, Daniele Nicolodi wrote:
> Hello,
> 
> the posix/leks regression test in the test suite failed to build on
> debian testing due to a missing include. The attached patch fixes the
> problem.

Applied as well, thanks.

-- 
Gilles.

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

Re: [Xenomai-core] patch: build: restore building of xeno-config man page

[Gilles Chanteperdrix]

On 10/04/2011 03:36 PM, Daniele Nicolodi wrote:
> Hello,
> 
> here is a simple patch to the build system to restore the building of
> xeno-config man page. It got lost some time ago. I noticed that it was
> missing because debian packages failed to build.

Applied, thanks.

-- 
Gilles.

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

Re: [Xenomai-core] Analogy: idx_write_subd field in a4l_desc_t

[Gilles Chanteperdrix]

On 10/04/2011 09:58 AM, Daniele Nicolodi wrote:
> On 01/10/11 20:07, Gilles Chanteperdrix wrote:
>>> For API / ABI compatibility reasons, I waited a major release before
>>> removing the fields idx_{read, write}_subd. I should have thought
>>> twice before removing their initializations. I will fix that soon,
>>> sorry.
>>
>> 2.6 is a new major release, and not out yet, so, if you want to remove
>> something, it is still time.
> 
> If we are open to some partially backward incompatible changes I propose
> to also change the meaning of the a4l_desc_t board_name field, to really
> be the board name, instead of the driver name. I find this information
> more useful when enumerating devices in my setup.
> 
> I would also like to propose a patch to demote some messages, logged at
> each interrupt, in the ni_pcimio driver from the info to the debug
> level. I run continuous acquisitions and those kernel messages pollute
> my syslog with not much added value and fill my disc with redundant
> information.

If you want things merged, send the patches, they will reach
xenomai-head repository through Alex.

-- 
Gilles.

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

Re: [Xenomai-core] Analogy: idx_write_subd field in a4l_desc_t

[Gilles Chanteperdrix]

On 10/01/2011 12:03 AM, Alexis Berlemont wrote:
> Hi,
> 
> On Tue, Sep 27, 2011 at 4:06 PM, Daniele Nicolodi  wrote:
>> Hello,
>>
>> I'm using xenomai-head on a 2.6.38.8 kernel on x86 with a NI-6251 DAQ
>> board. In this configuration the idx_write_subd field of the a4l_desc_t
>> structure filled by a4l_open() is not set to the proper value but is set
>> to NULL.
>>
>> In previous xanomai/analogy releases this was working properly. Has some
>> initialization code been removed in the latest analogy drivers refactoring?
> 
> Yes. Formerly, on both sides (kernel and user), we used some
> description fields (idx_read_subd and idx_write_subd) so as to quickly
> identify default asynchronous input and output subdevices and to link
> them with buffers (into which, input / output data are copied).
> 
> Most of the time, there were only one asynchronous read / write
> subdevice per card; so, the original Comedi way was ok.
> 
> Unfortunately, some boards now display many asynchronous subdevices of
> the same type. To tackle this issue, I could have implemented the
> workaround proposed by Comedi (give the possibility to attach the
> driver a second time and select the proper subdevice). I tried
> something else: when the driver is opened an asynchronous buffer is
> instanciated; at init time, this buffer does not belong to any
> subdevice but when an asynchronous command is sent, the buffer is
> temporarily reserved by the targeted subdevice.
> 
> Thus instead of re-attaching drivers with devices, the developer gets
> direct access on any subdevice; if he needs to perform two
> simultaneous asyncrhonous acquisitions on the same card, he just has
> to open the analogy device twice (a4l_open).
> 
> For API / ABI compatibility reasons, I waited a major release before
> removing the fields idx_{read, write}_subd. I should have thought
> twice before removing their initializations. I will fix that soon,
> sorry.

2.6 is a new major release, and not out yet, so, if you want to remove
something, it is still time.

-- 
Gilles.

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

[Xenomai-core] Xenomai 2.6.0-rc4

[Gilles Chanteperdrix]

Hi, 

here is the 4th release candidate for Xenomai 2.6.0:
http://download.gna.org/xenomai/testing/xenomai-2.6.0-rc4.tar.bz2

Novelties since -rc3 include:
- a fix for the "long names" issue on psos+
- a fix for the build issue of mscan on mpc52xx (please Wolfgang, have 
a look at the patch, to see if you like it:)
http://git.xenomai.org/?p=xenomai-head.git;a=commitdiff;h=d22fd231db7eb0af8e77ec570efb89e578e13781;hp=4a2188f049e96fc59aa7c4a7a9d058075f3d79e8
- a new version of the I-pipe patch for linux 3.0 on ppc.

This should be the last release candidate.

Regards.

-- 
Gilles.

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

Re: [Xenomai-core] [RFC 0/1] Class driver for raw Ethernet packets

[Gilles Chanteperdrix]

On 09/27/2011 07:00 PM, Richard Cochran wrote:
> On Tue, Sep 27, 2011 at 06:26:44PM +0200, Jan Kiszka wrote:
>> On 2011-09-27 18:05, Richard Cochran wrote:
>>
>> That's a common misunderstanding: RTnet is a networking stack with many
>> _optional_ components (like RTmac, RTcfg etc.). I would bet that it's
>> more frequently used today in minimal setups, i.e. just the core, some
>> driver, and either PF_PACKET or UDP/IP.
> 
> I understood about the modular design, but I really want to know if
> rtnet will help me if I want to use of the industrial Ethernet
> protocols. AFAICT, rtnet really doesn't offer these.
> 
> So I'll ask the direct question once again. Does rtnet help me with
> industrial Ethernet (apart from the rtnet protocols), or not?
> 
>>> Unless rtnet implements (or helps to implement) these, it is kind of
>>> silly to say, "your way won't work, you should use rtnet instead."
>>>
>>> I don't know PowerLink or Profinet, but I do know EtherCAT and IEC
>>> 61850, and those two can surely be implemented on the interface that I
>>> am talking about.
>>
>> It works, but it won't give you a deterministic control loop as you
>> still have Linux in the game.
> 
> It really depends on how the driver is written. While my gianfar
> example does make use of normal Linux driver interrupts, it would not
> necessarily have to do so.
> 
>> I was simply hoping to collect some new ideas how to address the driver
>> maintenance issue in a better way but without dropping key features
>> needed for RT networking. Something like "let's add generic RT channels
>> to Linux upstream drivers and then only patch them fit RTDM". Not sure
>> if that works, but it would come with a vision how to keep things more
>> maintainable.
> 
> Well, can you turn the issue around and convince me that writing a
> rtnet driver is the best way to acheive raw Ethernet packet access?

>From the point of view of someone a bit external to the rtnet project,
rtnet is a TCP/IP stack, which contains the stack, useless for your
purposes, but defines an interface between drivers and the stack. By
following this interface to write a driver on one-side, and support for
raw packets on the other side you get:
- raw packets support for all drivers in rtnet repository
- TCP/IP support for the NIC you wrote a driver for.

As for the in-kernel driver patch versus out-of-tree driver, in-kernel
driver will have to be adapted for each release of the linux kernel,
when porting the I-pipe patch, and that is quickly going to become a
nightmare.

> You talk about the rtnet driver model, but is it described anywhere?
> 
> (BTW rtnet/Documentation/README.drvporting is horrible. It is just a
> random list of 40+ odd points without any sense. That document gave me
> the impression that developing an rtnet driver is a kind of extended
> "hack until it starts working.")

README.drvporting is frightening at first, but in fact, the job to port
a network driver to rtnet is not so hard.

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


-- 
Gilles.

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

Re: [Xenomai-core] P2020 support for ftrace with ipipe 2.12-01 and xeno 2.5.5.1

[Gilles Chanteperdrix]

On 09/23/2011 11:49 AM, Jean-Michel Hautbois wrote:
> OK, I have more traces (a few :)) :

I meant the I-pipe tracer alone. The I-pipe tracer intead of other
ftrace tracers.


-- 
Gilles.

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

Re: [Xenomai-core] P2020 support for ftrace with ipipe 2.12-01 and xeno 2.5.5.1

[Gilles Chanteperdrix]

On 09/23/2011 09:58 AM, Jean-Michel Hautbois wrote:
> Hi List,
> 
> I am trying to use ftrace on a P2020 board, using the following :
> - Linux 2.6.35-11
> - Xenomai 2.5.5.1 (or 2.5.6, same problem)
> - ipipe 2.12-01
> 
> I launch it using :
> $> mkdir /tmp/debug
> $> mount -t debugfs nodev /tmp/debug
> $> cd /tmp/debug/tracing
> $> echo function_graph > current_tracer
> 
> The last one fails (it hangs the CPU, I cannot do anything than hard reset).
> Do you know what could cause that ?
> As I can't have any trace, I don't really know how to go further, and before
> using a BDI I would like to know if it is a known issue, as I could not find
> anything related to this in the recent changes...
> 
> Thanks in advance for your help,
> Regards,
> JM

Does the I-pipe tracer work?
See:
http://www.xenomai.org/index.php/I-pipe:Tracer


-- 
Gilles.

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

[Xenomai-core] Xenomai 2.6.0-rc3

[Gilles Chanteperdrix]

Hi,

here comes xenomai v2.6.0-rc3:
http://download.gna.org/xenomai/testing/xenomai-2.6.0-rc3.tar.bz2

New since -rc2:
- fix of vxworks services taskDelete and taskDeleteForce;
- SCHED_FIFO threads switching to SCHED_OTHER while holding a mutex are
sent a SIGDEBUG signal when releasing the mutex;
- add the beginning of a regression tests suite.

Known remaining issues:
- mscan driver not building on mpc5xxx with linux 3.0, see:
http://sisyphus.hd.free.fr/~gilles/bx/lite5200/3.0.4-ppc_6xx-gcc-4.2.2/log.html#1
- issue with 4 characters ids in the psos skin.

Regards.

-- 
Gilles.

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