[Xenomai] kconfig CONFIG_XENO_OPT_TIMING_PERIODIC=y/n

[Xenomai] kconfig CONFIG_XENO_OPT_TIMING_PERIODIC=y/n

[Michael Haberler]

I'm testing linuxcnc with John's 3.5.7 - 2.6.2.1 kernel and found an issue with the deprecated linuxcnc xenomai-kernel threads version (the userland threads version is fine; both using native skin). I traced that back to rt_timer_ticks2ns(30000) returning zero.

The config difference I see is: CONFIG_XENO_OPT_TIMING_PERIODIC=y on 3.5.7, unset on 3.2.21

The way I read back messages I'd think that should be unset for native and Posix skins; these are compiled in:

CONFIG_XENO_SKIN_NATIVE=y
CONFIG_XENO_SKIN_POSIX=y
CONFIG_XENO_SKIN_PSOS=m
CONFIG_XENO_SKIN_UITRON=m
CONFIG_XENO_SKIN_VRTX=m
CONFIG_XENO_SKIN_VXWORKS=m
CONFIG_XENO_SKIN_RTDM=y

(not that we're about to use the other skins soon, but I understand John is shooting for a most generic setup)

Am I correct to assume the right thing to do is to set CONFIG_XENO_OPT_TIMING_PERIODIC=n for that purpose?

thanks in advance,

Michael

Re: [Xenomai] kconfig CONFIG_XENO_OPT_TIMING_PERIODIC=y/n

[John Morris]

On 01/29/2013 06:54 AM, Michael Haberler wrote:
> I'm testing linuxcnc with John's 3.5.7 - 2.6.2.1 kernel and found an
> issue with the deprecated linuxcnc xenomai-kernel threads version
> (the userland threads version is fine; both using native skin). I
> traced that back to rt_timer_ticks2ns(30000) returning zero.
> 
> The config difference I see is: CONFIG_XENO_OPT_TIMING_PERIODIC=y on
> 3.5.7, unset on 3.2.21

The periodic timing option =y made it into my kernel
script-kiddie-style:  I copied it directly from Gilles's config without
trying to understand every option.

> 
> The way I read back messages I'd think that should be unset for
> native and Posix skins; these are compiled in:
> 
> CONFIG_XENO_SKIN_NATIVE=y
> CONFIG_XENO_SKIN_POSIX=y
> CONFIG_XENO_SKIN_PSOS=m
> CONFIG_XENO_SKIN_UITRON=m
> CONFIG_XENO_SKIN_VRTX=m
> CONFIG_XENO_SKIN_VXWORKS=m
> CONFIG_XENO_SKIN_RTDM=y

Now that I've gone back and read, I don't understand either.  Native and
posix styles need periodic timing unset.

At least the VXWorks skin needs periodic timing, so loading the VXWorks
skin module with periodic timing unset has no purpose, since RT programs
using the skin won't work.

> 
> (not that we're about to use the other skins soon, but I understand
> John is shooting for a most generic setup)

Yes, that's right, and of course with a preference to support the work
you did on LinuxCNC.  :)  Luckily, its interface with Xenomai is pretty
simple and uses the native skin, which I would have picked for a generic
kernel anyway.

> 
> Am I correct to assume the right thing to do is to set
> CONFIG_XENO_OPT_TIMING_PERIODIC=n for that purpose?

Still scratching my head on this.

	John


> 
> thanks in advance,
> 
> Michael
> 
> 
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai
> 

Re: [Xenomai] kconfig CONFIG_XENO_OPT_TIMING_PERIODIC=y/n

[Gilles Chanteperdrix]

Le 02/02/2013 22:30, Gilles Chanteperdrix a écrit :
> Le 02/02/2013 21:19, John Morris a écrit :
>>
>>
>> On 01/29/2013 06:54 AM, Michael Haberler wrote:
>>> I'm testing linuxcnc with John's 3.5.7 - 2.6.2.1 kernel and found an
>>> issue with the deprecated linuxcnc xenomai-kernel threads version
>>> (the userland threads version is fine; both using native skin). I
>>> traced that back to rt_timer_ticks2ns(30000) returning zero.
>>>
>>> The config difference I see is: CONFIG_XENO_OPT_TIMING_PERIODIC=y on
>>> 3.5.7, unset on 3.2.21
>>
>> The periodic timing option =y made it into my kernel
>> script-kiddie-style:  I copied it directly from Gilles's config without
>> trying to understand every option.
>>
>>>
>>> The way I read back messages I'd think that should be unset for
>>> native and Posix skins; these are compiled in:
>>>
>>> CONFIG_XENO_SKIN_NATIVE=y
>>> CONFIG_XENO_SKIN_POSIX=y
>>> CONFIG_XENO_SKIN_PSOS=m
>>> CONFIG_XENO_SKIN_UITRON=m
>>> CONFIG_XENO_SKIN_VRTX=m
>>> CONFIG_XENO_SKIN_VXWORKS=m
>>> CONFIG_XENO_SKIN_RTDM=y
>>
>> Now that I've gone back and read, I don't understand either.  Native and
>> posix styles need periodic timing unset.
>
> No, since xenomai 2.5, each skin decides whether it uses a periodic or
> aperiodic timing.
>
> without CONFIG_XENO_OPT_TIMING_PERIODIC, only the aperiodic timer is
> available, with this option set, the user has the choice.
>
> Each skin has:
> - a pre-set timer period in micro-seconds (which should be 0 by default
> for the native and posix skin, meaning the default aperiodic mode)
> - a module parameter "tick_arg" allowing to override the compiled-in
> pre-set timer period.
>
> So, enabling this option is what makes the most sense for a "generic"
> configuration. Now, what you observe with rt_timer_ticks2ns is
> undoubtely a bug.
>


-- 
Gilles.

Re: [Xenomai] kconfig CONFIG_XENO_OPT_TIMING_PERIODIC=y/n

[Gilles Chanteperdrix]

On 01/29/2013 01:54 PM, Michael Haberler wrote:

> I'm testing linuxcnc with John's 3.5.7 - 2.6.2.1 kernel and found an
> issue with the deprecated linuxcnc xenomai-kernel threads version
> (the userland threads version is fine; both using native skin). I
> traced that back to rt_timer_ticks2ns(30000) returning zero.


Hi Michael,

I am unable to reproduce this issue. I have written the following 
kernel code:

#include <native/timer.h>

int init(void)
{
	rt_timer_set_mode(0);
	xnprintf("mode aperiodic, ticks2ns: %Lu\n", rt_timer_ticks2ns(30000));
	rt_timer_set_mode(1000000);
	xnprintf("mode periodic, ticks2ns: %Lu\n", rt_timer_ticks2ns(30000));
			
	return 0;
}

module_init(init);
MODULE_LICENSE("GPL");

And I get:
[   17.366373] Xenomai: mode 0, ticks2ns: 30000                                    
[   17.370918] Xenomai: mode periodic, ticks2ns: 30000000000                       

Which is the expected behaviour.

Could you send us a test case allowing to reproduce the issue you 
encountered ?


-- 
                                                                Gilles.

Re: [Xenomai] kconfig CONFIG_XENO_OPT_TIMING_PERIODIC=y/n

[Michael Haberler]

Hi Gilles,

sorry I should have mentioned I fixed this by removing the code - problematic behaviour vanished. 

this was a mystification and I think a programming error on my behalf - that ticket can be closed as 'user error'

thanks!

Michael

Am 14.04.2013 um 07:54 schrieb Gilles Chanteperdrix:

> On 01/29/2013 01:54 PM, Michael Haberler wrote:
> 
>> I'm testing linuxcnc with John's 3.5.7 - 2.6.2.1 kernel and found an
>> issue with the deprecated linuxcnc xenomai-kernel threads version
>> (the userland threads version is fine; both using native skin). I
>> traced that back to rt_timer_ticks2ns(30000) returning zero.
> 
> 
> Hi Michael,
> 
> I am unable to reproduce this issue. I have written the following 
> kernel code:
> 
> #include <native/timer.h>
> 
> int init(void)
> {
> 	rt_timer_set_mode(0);
> 	xnprintf("mode aperiodic, ticks2ns: %Lu\n", rt_timer_ticks2ns(30000));
> 	rt_timer_set_mode(1000000);
> 	xnprintf("mode periodic, ticks2ns: %Lu\n", rt_timer_ticks2ns(30000));
> 			
> 	return 0;
> }
> 
> module_init(init);
> MODULE_LICENSE("GPL");
> 
> And I get:
> [   17.366373] Xenomai: mode 0, ticks2ns: 30000                                    
> [   17.370918] Xenomai: mode periodic, ticks2ns: 30000000000                       
> 
> Which is the expected behaviour.
> 
> Could you send us a test case allowing to reproduce the issue you 
> encountered ?
> 
> 
> -- 
>                                                                Gilles.