[Xenomai-core] SOLO: Too limited priorities for vxWorks threads

[Xenomai-core] SOLO: Too limited priorities for vxWorks threads

[Niklaus Giger]

Hi

I just tried to get a sample test program to run under Xenomai-SOLO
and run into this panic message:
Xenomai/SOLO: current implementation restricts VxWorkspriority levels to range [-2..0]
looking at the code I found at taskLib.c
> 263     {
> 264             if (wind_prio < 0 || wind_prio > 255) /* In theory. */
> 265                     return S_taskLib_ILLEGAL_PRIORITY;
> 266
> 267             if (wind_prio >= threadobj_max_prio - 1) /* In practice. */
> 268                     panic("current implementation restricts VxWorks"
> 269                           "priority levels to range [%d..0]",
> 270                           threadobj_max_prio - 2);
> 271             return OK;
Therefore I seem to have only the option of priority 0 which is way too limited.

I took a look at vxworks/testsuite/task-1.c and found that it spawns a task
with priority 70. Calling "make check" compiled a few more files but did not run
any checks.

After calling make in vxworks/testsuite and callling ./task-1 I got the same
error.

I am running the (unpatched) Debian kernel 2.6.24-1-686, as I just wanted to
run some test without requiring any realtime behaviour. Reading 
http://www.denx.de/cgi-bin/gitweb.cgi?p=xenomai-solo.git;a=blob;f=README
I found the sentence "SOLO may also be used with non-PREEMPT_RT kernels, likely
for basic debugging tasks which do not involve strict real-time requirements"
and concluded therefore that I should be able to use for my test a "normal"
kernel.

As glibc I use the Debian lenny version 2.7-10.

Best regards

Niklaus Giger

Re: [Xenomai-core] SOLO: Too limited priorities for vxWorks threads

[Philippe Gerum]

Niklaus Giger wrote:
> Hi
> 
> I just tried to get a sample test program to run under Xenomai-SOLO
> and run into this panic message:
> Xenomai/SOLO: current implementation restricts VxWorkspriority levels to range [-2..0]
> looking at the code I found at taskLib.c
>> 263     {
>> 264             if (wind_prio < 0 || wind_prio > 255) /* In theory. */
>> 265                     return S_taskLib_ILLEGAL_PRIORITY;
>> 266
>> 267             if (wind_prio >= threadobj_max_prio - 1) /* In practice. */
>> 268                     panic("current implementation restricts VxWorks"
>> 269                           "priority levels to range [%d..0]",
>> 270                           threadobj_max_prio - 2);
>> 271             return OK;
> Therefore I seem to have only the option of priority 0 which is way too limited.
> 

The SOLO version is purely Linux native, so you only get what the underlying
kernel provides you, including in terms of available priority scales. Since RT
threads are members of the SCHED_FIFO class, you get 99 priority levels, unless
you patch the vanilla kernel to handle more. The way to solve this properly for
SOLO is to write a patch against PREEMPT_RT that allows wider priority scales,
and to get it merged upstream.

> I took a look at vxworks/testsuite/task-1.c and found that it spawns a task
> with priority 70. Calling "make check" compiled a few more files but did not run
> any checks.
> 
> After calling make in vxworks/testsuite and callling ./task-1 I got the same
> error.
> 
> I am running the (unpatched) Debian kernel 2.6.24-1-686, as I just wanted to
> run some test without requiring any realtime behaviour. Reading 
> http://www.denx.de/cgi-bin/gitweb.cgi?p=xenomai-solo.git;a=blob;f=README
> I found the sentence "SOLO may also be used with non-PREEMPT_RT kernels, likely
> for basic debugging tasks which do not involve strict real-time requirements"
> and concluded therefore that I should be able to use for my test a "normal"
> kernel.
>

Which is wrong if you plan to compare latencies. You should at least use
PREEMPT_RT to do that, otherwise it's meaningless.

> As glibc I use the Debian lenny version 2.7-10.
> 
> Best regards
> 
> Niklaus Giger
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
> 


-- 
Philippe.

Re: [Xenomai-core] SOLO: Too limited priorities for vxWorks threads

[Philippe Gerum]

Niklaus Giger wrote:
> Hi
> 
> I just tried to get a sample test program to run under Xenomai-SOLO
> and run into this panic message:
> Xenomai/SOLO: current implementation restricts VxWorkspriority levels to range [-2..0]
> looking at the code I found at taskLib.c
>> 263     {
>> 264             if (wind_prio < 0 || wind_prio > 255) /* In theory. */
>> 265                     return S_taskLib_ILLEGAL_PRIORITY;
>> 266
>> 267             if (wind_prio >= threadobj_max_prio - 1) /* In practice. */
>> 268                     panic("current implementation restricts VxWorks"
>> 269                           "priority levels to range [%d..0]",
>> 270                           threadobj_max_prio - 2);
>> 271             return OK;
> Therefore I seem to have only the option of priority 0 which is way too limited.
>

No, this means there is a problem. threadobj_max_prio should be 99.

> I took a look at vxworks/testsuite/task-1.c and found that it spawns a task
> with priority 70. Calling "make check" compiled a few more files but did not run
> any checks.
> 
> After calling make in vxworks/testsuite and callling ./task-1 I got the same
> error.
> 
> I am running the (unpatched) Debian kernel 2.6.24-1-686, as I just wanted to
> run some test without requiring any realtime behaviour. Reading 
> http://www.denx.de/cgi-bin/gitweb.cgi?p=xenomai-solo.git;a=blob;f=README
> I found the sentence "SOLO may also be used with non-PREEMPT_RT kernels, likely
> for basic debugging tasks which do not involve strict real-time requirements"
> and concluded therefore that I should be able to use for my test a "normal"
> kernel.
> 
> As glibc I use the Debian lenny version 2.7-10.
> 
> Best regards
> 
> Niklaus Giger
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
> 


-- 
Philippe.

Re: [Xenomai-core] SOLO: Too limited priorities for vxWorks threads

[Niklaus Giger]

Am Sonntag, 18. Mai 2008 schrieb Philippe Gerum:
> Niklaus Giger wrote:
> > Hi
> > 
> > I just tried to get a sample test program to run under Xenomai-SOLO
> > and run into this panic message:
> > Xenomai/SOLO: current implementation restricts VxWorkspriority levels to range [-2..0]
> > looking at the code I found at taskLib.c
> >> 263     {
> >> 264             if (wind_prio < 0 || wind_prio > 255) /* In theory. */
> >> 265                     return S_taskLib_ILLEGAL_PRIORITY;
> >> 266
> >> 267             if (wind_prio >= threadobj_max_prio - 1) /* In practice. */
> >> 268                     panic("current implementation restricts VxWorks"
> >> 269                           "priority levels to range [%d..0]",
> >> 270                           threadobj_max_prio - 2);
> >> 271             return OK;
> > Therefore I seem to have only the option of priority 0 which is way too limited.
> > 
> 
> The SOLO version is purely Linux native, so you only get what the underlying
> kernel provides you, including in terms of available priority scales. Since RT
> threads are members of the SCHED_FIFO class, you get 99 priority levels, unless
> you patch the vanilla kernel to handle more. The way to solve this properly for
> SOLO is to write a patch against PREEMPT_RT that allows wider priority scales,
> and to get it merged upstream.
Sorry, but you did not get my point. I tried to call it with priority 50, which
should be in this range, which I verified with gdb
(gdb) info stack
#0  panic (fmt=0xb7eebb90 "current implementation restricts VxWorkspriority levels to range [%d..0]") at panic.c:45
#1  0xb7eea1ac in check_task_priority (wind_prio=50) at taskLib.c:268
#2  0xb7eea1d9 in __taskInit (task=0x9eda0e0, tcb=0x9eda10c, name=0xbfc43760 "BSysAsyncTimerMgrThread", prio=50, flags=0,
    entry=0x81281c4 <BSysOsWrapperThread_callback(int)>, stacksize=51200) at taskLib.c:284
<...>

I am happy with the rang 0.99 and also will no run any latency tests, as
xenomai-SOLO is for me at the moment just a test bed to check for compiler
error etc, as at the moment I have no running powerpc kernel for my PPC440
target.

Best regards

-- 

Re: [Xenomai-core] SOLO: Too limited priorities for vxWorks threads

[Philippe Gerum]

Niklaus Giger wrote:
> Am Sonntag, 18. Mai 2008 schrieb Philippe Gerum:
>> Niklaus Giger wrote:
>>> Hi
>>>
>>> I just tried to get a sample test program to run under Xenomai-SOLO
>>> and run into this panic message:
>>> Xenomai/SOLO: current implementation restricts VxWorkspriority levels to range [-2..0]
>>> looking at the code I found at taskLib.c
>>>> 263     {
>>>> 264             if (wind_prio < 0 || wind_prio > 255) /* In theory. */
>>>> 265                     return S_taskLib_ILLEGAL_PRIORITY;
>>>> 266
>>>> 267             if (wind_prio >= threadobj_max_prio - 1) /* In practice. */
>>>> 268                     panic("current implementation restricts VxWorks"
>>>> 269                           "priority levels to range [%d..0]",
>>>> 270                           threadobj_max_prio - 2);
>>>> 271             return OK;
>>> Therefore I seem to have only the option of priority 0 which is way too limited.
>>>
>> The SOLO version is purely Linux native, so you only get what the underlying
>> kernel provides you, including in terms of available priority scales. Since RT
>> threads are members of the SCHED_FIFO class, you get 99 priority levels, unless
>> you patch the vanilla kernel to handle more. The way to solve this properly for
>> SOLO is to write a patch against PREEMPT_RT that allows wider priority scales,
>> and to get it merged upstream.
> Sorry, but you did not get my point. I tried to call it with priority 50, which
> should be in this range, which I verified with gdb
> (gdb) info stack
> #0  panic (fmt=0xb7eebb90 "current implementation restricts VxWorkspriority levels to range [%d..0]") at panic.c:45
> #1  0xb7eea1ac in check_task_priority (wind_prio=50) at taskLib.c:268
> #2  0xb7eea1d9 in __taskInit (task=0x9eda0e0, tcb=0x9eda10c, name=0xbfc43760 "BSysAsyncTimerMgrThread", prio=50, flags=0,
>     entry=0x81281c4 <BSysOsWrapperThread_callback(int)>, stacksize=51200) at taskLib.c:284
> <...>
> 
> I am happy with the rang 0.99 and also will no run any latency tests, as
> xenomai-SOLO is for me at the moment just a test bed to check for compiler
> error etc, as at the moment I have no running powerpc kernel for my PPC440
> target.
>

Have a look at my next answer: the test fails because threadobj_max_prio is
zero, which can't be the case after the emulator has properly initialized. You
may have run into either of the following problems:

- since you seem to be using C++, don't create tasks in static constructors.
They are run before solo_init() is called.

- make sure to call kernelInit() from the VxWorks emulation lib, just like the
tests from the test suite do.


> Best regards
> 


-- 
Philippe.

Re: [Xenomai-core] SOLO: Too limited priorities for vxWorks threads

[Philippe Gerum]

Philippe Gerum wrote:
> Niklaus Giger wrote:
>> Am Sonntag, 18. Mai 2008 schrieb Philippe Gerum:
>>> Niklaus Giger wrote:
>>>> Hi
>>>>
>>>> I just tried to get a sample test program to run under Xenomai-SOLO
>>>> and run into this panic message:
>>>> Xenomai/SOLO: current implementation restricts VxWorkspriority levels to range [-2..0]
>>>> looking at the code I found at taskLib.c
>>>>> 263     {
>>>>> 264             if (wind_prio < 0 || wind_prio > 255) /* In theory. */
>>>>> 265                     return S_taskLib_ILLEGAL_PRIORITY;
>>>>> 266
>>>>> 267             if (wind_prio >= threadobj_max_prio - 1) /* In practice. */
>>>>> 268                     panic("current implementation restricts VxWorks"
>>>>> 269                           "priority levels to range [%d..0]",
>>>>> 270                           threadobj_max_prio - 2);
>>>>> 271             return OK;
>>>> Therefore I seem to have only the option of priority 0 which is way too limited.
>>>>
>>> The SOLO version is purely Linux native, so you only get what the underlying
>>> kernel provides you, including in terms of available priority scales. Since RT
>>> threads are members of the SCHED_FIFO class, you get 99 priority levels, unless
>>> you patch the vanilla kernel to handle more. The way to solve this properly for
>>> SOLO is to write a patch against PREEMPT_RT that allows wider priority scales,
>>> and to get it merged upstream.
>> Sorry, but you did not get my point. I tried to call it with priority 50, which
>> should be in this range, which I verified with gdb
>> (gdb) info stack
>> #0  panic (fmt=0xb7eebb90 "current implementation restricts VxWorkspriority levels to range [%d..0]") at panic.c:45
>> #1  0xb7eea1ac in check_task_priority (wind_prio=50) at taskLib.c:268
>> #2  0xb7eea1d9 in __taskInit (task=0x9eda0e0, tcb=0x9eda10c, name=0xbfc43760 "BSysAsyncTimerMgrThread", prio=50, flags=0,
>>     entry=0x81281c4 <BSysOsWrapperThread_callback(int)>, stacksize=51200) at taskLib.c:284
>> <...>
>>
>> I am happy with the rang 0.99 and also will no run any latency tests, as
>> xenomai-SOLO is for me at the moment just a test bed to check for compiler
>> error etc, as at the moment I have no running powerpc kernel for my PPC440
>> target.
>>
> 
> Have a look at my next answer: the test fails because threadobj_max_prio is
> zero, which can't be the case after the emulator has properly initialized. You
> may have run into either of the following problems:
> 
> - since you seem to be using C++, don't create tasks in static constructors.
> They are run before solo_init() is called.
> 

Actually, don't do anything that involves the emulation services - except
calling kernelInit() - in static constructors.

> - make sure to call kernelInit() from the VxWorks emulation lib, just like the
> tests from the test suite do.
> 

i.e. kernelInit() calls solo_init(), which initializes the thread emulation
package, which sets threadobj_max_prio appropriately.

> 
>> Best regards
>>
> 
> 


-- 
Philippe.