[Xenomai-help] update from fusion 0.9.1 to xenomai 2.4.0

[Xenomai-help] update from fusion 0.9.1 to xenomai 2.4.0

[Racconico Lambrati]

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

Hi.

I've update my system to xenomai 2.4.0 from fusion 0.9.1 using vxworks skin

I used http://www.captain.at/xenomai-porting-fusion.php to make the porting
of my application.

now I have this linker problem:

... undefined reference to 'printk'
... undefined reference to 'intUnlock'
... undefined reference to 'intLock'
... undefined reference to 'sysClkConnect'

could you give me an hint?

thanks, Racconico

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

Re: [Xenomai-help] update from fusion 0.9.1 to xenomai 2.4.0

[Gilles Chanteperdrix]

On Dec 27, 2007 4:04 PM, Racconico Lambrati
<racconico.lambrati@domain.hid> wrote:
> Hi.
>
> I've update my system to xenomai 2.4.0 from fusion 0.9.1 using vxworks skin
>
> I used http://www.captain.at/xenomai-porting-fusion.php to make the porting
> of my application.
>
> now I have this linker problem:
>
> ... undefined reference to 'printk'
> ... undefined reference to 'intUnlock'
> ... undefined reference to 'intLock'
> ... undefined reference to 'sysClkConnect'
>
> could you give me an hint?

These functions are only available in kernel-space. The fact that you
must use them probably means that you should split your application:
move the part that require access to low-level functions in a driver
using the rtdm skin.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] update from fusion 0.9.1 to xenomai 2.4.0

[Racconico Lambrati]

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

It could be a chance but for now I want to run my
application as I run it under fusion to test that everything
is ok.

I see that intLock intUnlock and sysClkConnect are present
in vxworks.h, why the linker can't find it?



2007/12/27, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
>
> On Dec 27, 2007 4:04 PM, Racconico Lambrati
> <racconico.lambrati@domain.hid> wrote:
> > Hi.
> >
> > I've update my system to xenomai 2.4.0 from fusion 0.9.1 using vxworks
> skin
> >
> > I used http://www.captain.at/xenomai-porting-fusion.php to make the
> porting
> > of my application.
> >
> > now I have this linker problem:
> >
> > ... undefined reference to 'printk'
> > ... undefined reference to 'intUnlock'
> > ... undefined reference to 'intLock'
> > ... undefined reference to 'sysClkConnect'
> >
> > could you give me an hint?
>
> These functions are only available in kernel-space. The fact that you
> must use them probably means that you should split your application:
> move the part that require access to low-level functions in a driver
> using the rtdm skin.
>
> --
>                                                Gilles Chanteperdrix
>

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

Re: [Xenomai-help] update from fusion 0.9.1 to xenomai 2.4.0

[Gilles Chanteperdrix]

Racconico Lambrati wrote:
 > 2007/12/27, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
 > >
 > > On Dec 27, 2007 4:04 PM, Racconico Lambrati
 > > <racconico.lambrati@domain.hid> wrote:
 > > > Hi.
 > > >
 > > > I've update my system to xenomai 2.4.0 from fusion 0.9.1 using vxworks
 > > skin
 > > >
 > > > I used http://www.captain.at/xenomai-porting-fusion.php to make the
 > > porting
 > > > of my application.
 > > >
 > > > now I have this linker problem:
 > > >
 > > > ... undefined reference to 'printk'
 > > > ... undefined reference to 'intUnlock'
 > > > ... undefined reference to 'intLock'
 > > > ... undefined reference to 'sysClkConnect'
 > > >
 > > > could you give me an hint?
 > >
 > > These functions are only available in kernel-space. The fact that you
 > > must use them probably means that you should split your application:
 > > move the part that require access to low-level functions in a driver
 > > using the rtdm skin.
 > >
 > It could be a chance but for now I want to run my
 > application as I run it under fusion to test that everything
 > is ok.
 > 
 > I see that intLock intUnlock and sysClkConnect are present
 > in vxworks.h, why the linker can't find it?
 > 

As I already told these functions are only available in kernel-space,
they can not be implemented in user-space, they are not present in
the vxworks library so the linker can not find them.

Your only chance is to run your application in kernel-space. But this
will make it harder to debug.

Without seeing the parts of your code requiring these low-level calls,
it is hard to say anything.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] update from fusion 0.9.1 to xenomai 2.4.0

[Racconico Lambrati]

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

How can I run it in kernel space?
The application is designed to be little and stable, and with fusion
0.9.1run without problem

2007/12/27, Gilles Chanteperdrix < gilles.chanteperdrix@xenomai.org>:
> >
> > Racconico Lambrati wrote:
> > > 2007/12/27, Gilles Chanteperdrix < gilles.chanteperdrix@xenomai.org>:
> > > >
> > > > On Dec 27, 2007 4:04 PM, Racconico Lambrati
> > > > < racconico.lambrati@domain.hid> wrote:
> > > > > Hi.
> > > > >
> > > > > I've update my system to xenomai 2.4.0 from fusion 0.9.1 using
> > vxworks
> > > > skin
> > > > >
> > > > > I used http://www.captain.at/xenomai-porting-fusion.php to make
> > the
> > > > porting
> > > > > of my application.
> > > > >
> > > > > now I have this linker problem:
> > > > >
> > > > > ... undefined reference to 'printk'
> > > > > ... undefined reference to 'intUnlock'
> > > > > ... undefined reference to 'intLock'
> > > > > ... undefined reference to 'sysClkConnect'
> > > > >
> > > > > could you give me an hint?
> > > >
> > > > These functions are only available in kernel-space. The fact that
> > you
> > > > must use them probably means that you should split your application:
> > > > move the part that require access to low-level functions in a driver
> > > > using the rtdm skin.
> > > >
> > > It could be a chance but for now I want to run my
> > > application as I run it under fusion to test that everything
> > > is ok.
> > >
> > > I see that intLock intUnlock and sysClkConnect are present
> > > in vxworks.h, why the linker can't find it?
> > >
> >
> > As I already told these functions are only available in kernel-space,
> > they can not be implemented in user-space, they are not present in
> > the vxworks library so the linker can not find them.
> >
> > Your only chance is to run your application in kernel-space. But this
> > will make it harder to debug.
> >
> > Without seeing the parts of your code requiring these low-level calls,
> > it is hard to say anything.
> >
> > --
> >
> >
> >                                             Gilles Chanteperdrix.
> >
>
>

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

Re: [Xenomai-help] update from fusion 0.9.1 to xenomai 2.4.0

[Philippe Gerum]

Racconico Lambrati wrote:
> 
> How can I run it in kernel space?
> The application is designed to be little and stable, and with fusion
> 0.9.1 run without problem
>

If your application based on 0.9.1 used to run in user-space, then it
must have been based on the UVM support. This support has been dismissed
since Xenomai v2.3-rc1, because it was a temporary hack allowing
user-space development until all skins have a real user-space interface,
which is now the case.

The services you mention are now only available from the kernel-based
interface, provided by the xeno_vxworks.ko module, because they do not
make sense from a userland perspective.

Userland applications based on the VxWorks API
(/usr/xenomai/lib/libvxworks.so) should not need them at all. If for
some reason they do, then you should consider splitting the application
in two parts, one kernel-based, the other one running in userland. The
point is that dealing with interrupts should most often remain a kernel
business, and this obviously also applies to interposing on the tick timer.

If your application was not based on the UVM, then it must have been
running embodied into a kernel module, in which case the issue is
already solved.

Rehashing what Gilles already told you: until you actually explain _why_
you need such services, nobody will be able to suggest any solution to
your problem, I'm afraid.

-- 
Philippe.

Re: [Xenomai-help] update from fusion 0.9.1 to xenomai 2.4.0

[Racconico Lambrati]

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

2007/12/27, Philippe Gerum <rpm@xenomai.org>:
>
> Racconico Lambrati wrote:
> >
> > How can I run it in kernel space?
> > The application is designed to be little and stable, and with fusion
> > 0.9.1 run without problem
> >
>
> If your application based on 0.9.1 used to run in user-space, then it
> must have been based on the UVM support. This support has been dismissed
> since Xenomai v2.3-rc1, because it was a temporary hack allowing
> user-space development until all skins have a real user-space interface,
> which is now the case.


murphy's law  could be applied here! I use uvm

The services you mention are now only available from the kernel-based
> interface, provided by the xeno_vxworks.ko module, because they do not
> make sense from a userland perspective.


then is it possible to create a kernel-based application with vxworks skins?
How can i do it?
I use "$(xeno-config --uvm-ldflags) -lvxworks -lrtai -lm" as LDFLAGS option.

Userland applications based on the VxWorks API
> (/usr/xenomai/lib/libvxworks.so) should not need them at all. If for
> some reason they do, then you should consider splitting the application
> in two parts, one kernel-based, the other one running in userland. The
> point is that dealing with interrupts should most often remain a kernel
> business, and this obviously also applies to interposing on the tick
> timer.


I've alredy done, using rt_pipe to make a communication line to a non-RT
application and my RT application.

If your application was not based on the UVM, then it must have been
> running embodied into a kernel module, in which case the issue is
> already solved.


This is not my case

Rehashing what Gilles already told you: until you actually explain _why_
> you need such services, nobody will be able to suggest any solution to
> your problem, I'm afraid.
>
> --
> Philippe.
>

The application use intLock and intUnlock first of all to handle a CAN
device.
I use it also to handle a timers array. when I delete a timers from an array
I disable the interrupt to avoid some race condition's problem (maybe a
timer that is going to be delete wake up during it's deleting routine).

I use SysClkConnect to hang the clock to a function that send the Give
signal to a semaphore every 'n' cycle.

the semaphore is used to give the start to a function that handle the most
important duty of the system, then when it term it cycle, it send the Give
signal to a second semaphore that will launch a second task that manage the
lesser important things.

This is an overview of my software. there aren't many other thing, only the
processing of the data received from CAN device, that is a lot of code but
it don't need the realtime services. this code is executed in the first task


I hope you understand my needs (my English is not so good).


Now I want understand the possible solution to my problem.

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

Re: [Xenomai-help] update from fusion 0.9.1 to xenomai 2.4.0

[Racconico Lambrati]

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

2007/12/27, Philippe Gerum <rpm@xenomai.org>:
>
> Racconico Lambrati wrote:
> >
> > How can I run it in kernel space?
> > The application is designed to be little and stable, and with fusion
> > 0.9.1 run without problem
> >
>
> If your application based on 0.9.1 used to run in user-space, then it
> must have been based on the UVM support. This support has been dismissed
> since Xenomai v2.3-rc1, because it was a temporary hack allowing
> user-space development until all skins have a real user-space interface,
> which is now the case.


murphy's law  could be applied here! I use uvm

The services you mention are now only available from the kernel-based
> interface, provided by the xeno_vxworks.ko module, because they do not
> make sense from a userland perspective.


then is it possible to create a kernel-based application with vxworks skins?
How can i do it?
I use "$(xeno-config --uvm-ldflags) -lvxworks -lrtai -lm" as LDFLAGS option.

Userland applications based on the VxWorks API
> (/usr/xenomai/lib/libvxworks.so) should not need them at all. If for
> some reason they do, then you should consider splitting the application
> in two parts, one kernel-based, the other one running in userland. The
> point is that dealing with interrupts should most often remain a kernel
> business, and this obviously also applies to interposing on the tick
> timer.


I've alredy done, using rt_pipe to make a communication line to a non-RT
application and my RT application.

If your application was not based on the UVM, then it must have been
> running embodied into a kernel module, in which case the issue is
> already solved.


This is not my case

Rehashing what Gilles already told you: until you actually explain _why_
> you need such services, nobody will be able to suggest any solution to
> your problem, I'm afraid.
>
> --
> Philippe.
>

The application use intLock and intUnlock first of all to handle a CAN
device.
I use it also to handle a timers array. when I delete a timers from an array
I disable the interrupt to avoid some race condition's problem (maybe a
timer that is going to be delete wake up during it's deleting routine).

I use SysClkConnect to hang the clock to a function that send the Give
signal to a semaphore every 'n' cycle.

the semaphore is used to give the start to a function that handle the most
important duty of the system, then when it term it cycle, it send the Give
signal to a second semaphore that will launch a second task that manage the
lesser important things.

This is an overview of my software. there aren't many other thing, only the
processing of the data received from CAN device, that is a lot of code but
it don't need the realtime services. this code is executed in the first task


I hope you understand my needs (my English is not so good).


Now I want understand the possible solution to my problem.

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

Re: [Xenomai-help] update from fusion 0.9.1 to xenomai 2.4.0

[Gilles Chanteperdrix]

On Dec 28, 2007 2:56 AM, Racconico Lambrati
<racconico.lambrati@domain.hid> wrote:
>
>
> 2007/12/27, Philippe Gerum <rpm@xenomai.org>:
> > Racconico Lambrati wrote:
> > >
> > > How can I run it in kernel space?
> > > The application is designed to be little and stable, and with fusion
> > > 0.9.1 run without problem
> > >
> >
> > If your application based on 0.9.1 used to run in user-space, then it
> > must have been based on the UVM support. This support has been dismissed
> > since Xenomai v2.3-rc1, because it was a temporary hack allowing
> > user-space development until all skins have a real user-space interface,
> > which is now the case.
>
> murphy's law  could be applied here! I use uvm
>
> > The services you mention are now only available from the kernel-based
> > interface, provided by the xeno_vxworks.ko module, because they do not
> > make sense from a userland perspective.
>
> then is it possible to create a kernel-based application with vxworks skins?
> How can i do it?
> I use "$(xeno-config --uvm-ldflags) -lvxworks -lrtai -lm" as LDFLAGS option.
>
> > Userland applications based on the VxWorks API
> > (/usr/xenomai/lib/libvxworks.so) should not need them at all. If for
> > some reason they do, then you should consider splitting the application
> > in two parts, one kernel-based, the other one running in userland. The
> > point is that dealing with interrupts should most often remain a kernel
> > business, and this obviously also applies to interposing on the tick
> timer.
>
> I've alredy done, using rt_pipe to make a communication line to a non-RT
> application and my RT application.
>
> > If your application was not based on the UVM, then it must have been
> > running embodied into a kernel module, in which case the issue is
> > already solved.
>
> This is not my case
>
> > Rehashing what Gilles already told you: until you actually explain _why_
> > you need such services, nobody will be able to suggest any solution to
> > your problem, I'm afraid.
>
> The application use intLock and intUnlock first of all to handle a CAN
> device.

This would better be done in a driver, in kernel-space. Or if you want
to continue to handle the CAN device in user-space, you will have to
replace intLock/intUnlock with a mutex.

> I use it also to handle a timers array. when I delete a timers from an array
> I disable the interrupt to avoid some race condition's problem (maybe a
> timer that is going to be delete wake up during it's deleting routine).

I am not sure I understand what you mean. If you are doing your own
timer handling, you should probably use vxworks watchdogs instead.
Xenomai timers are handled in a linked list by default, but you can
choose other data structures if you have to handle a lot of timers.
If by timers array, you mean an array of vxworks watchdogs, you do not
have to worry about locking, this is already done by xenomai vxworks
services. If what you want to protect is concurrent access to the
array, then you can use a mutex.

>
> I use SysClkConnect to hang the clock to a function that send the Give
> signal to a semaphore every 'n' cycle.

You can use a watchdog for that too.

>
> the semaphore is used to give the start to a function that handle the most
> important duty of the system, then when it term it cycle, it send the Give
> signal to a second semaphore that will launch a second task that manage the
> lesser important things.
>
> This is an overview of my software. there aren't many other thing, only the
> processing of the data received from CAN device, that is a lot of code but
> it don't need the realtime services. this code is executed in the first task
>
> I hope you understand my needs (my English is not so good).

Do not worry, english is not my mother tongue, so, even if you make
mistakes, I do not see them.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] update from fusion 0.9.1 to xenomai 2.4.0

[Racconico Lambrati]

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

I've done some works, and searched in xenomai's native function.

To replace SysClkConnect I've created a periodic task with priority=90 that
wait 5ms.
The last operation in a task's cycle is semGive(gServiceSem);
A second task, non periodic, have as first operation of the cycle
semTake(gServiceSem,WAIT_FOREVER);
the second task has priority=50

when the total time for one cycle of task1 and task2 everything seems run
properly , when task2 take more then 5ms for do it's cycle
rt_task_wait_period(NULL) return me 146 and not 0, and the time for task1 is
not respected.

This sound strange for me, why the scheduler don't switch the task in
execution?


A second question is, if can I change (TaskIdSelf() == IdTask) with
(rt_task_self() == &IdTask)?

thanks for all, Racconico

2007/12/28, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
>
> On Dec 28, 2007 2:56 AM, Racconico Lambrati
> <racconico.lambrati@domain.hid> wrote:
> >
> >
> > 2007/12/27, Philippe Gerum <rpm@xenomai.org>:
> > > Racconico Lambrati wrote:
> > > >
> > > > How can I run it in kernel space?
> > > > The application is designed to be little and stable, and with fusion
> > > > 0.9.1 run without problem
> > > >
> > >
> > > If your application based on 0.9.1 used to run in user-space, then it
> > > must have been based on the UVM support. This support has been
> dismissed
> > > since Xenomai v2.3-rc1, because it was a temporary hack allowing
> > > user-space development until all skins have a real user-space
> interface,
> > > which is now the case.
> >
> > murphy's law  could be applied here! I use uvm
> >
> > > The services you mention are now only available from the kernel-based
> > > interface, provided by the xeno_vxworks.ko module, because they do not
> > > make sense from a userland perspective.
> >
> > then is it possible to create a kernel-based application with vxworks
> skins?
> > How can i do it?
> > I use "$(xeno-config --uvm-ldflags) -lvxworks -lrtai -lm" as LDFLAGS
> option.
> >
> > > Userland applications based on the VxWorks API
> > > (/usr/xenomai/lib/libvxworks.so) should not need them at all. If for
> > > some reason they do, then you should consider splitting the
> application
> > > in two parts, one kernel-based, the other one running in userland. The
> > > point is that dealing with interrupts should most often remain a
> kernel
> > > business, and this obviously also applies to interposing on the tick
> > timer.
> >
> > I've alredy done, using rt_pipe to make a communication line to a non-RT
> > application and my RT application.
> >
> > > If your application was not based on the UVM, then it must have been
> > > running embodied into a kernel module, in which case the issue is
> > > already solved.
> >
> > This is not my case
> >
> > > Rehashing what Gilles already told you: until you actually explain
> _why_
> > > you need such services, nobody will be able to suggest any solution to
> > > your problem, I'm afraid.
> >
> > The application use intLock and intUnlock first of all to handle a CAN
> > device.
>
> This would better be done in a driver, in kernel-space. Or if you want
> to continue to handle the CAN device in user-space, you will have to
> replace intLock/intUnlock with a mutex.
>
> > I use it also to handle a timers array. when I delete a timers from an
> array
> > I disable the interrupt to avoid some race condition's problem (maybe a
> > timer that is going to be delete wake up during it's deleting routine).
>
> I am not sure I understand what you mean. If you are doing your own
> timer handling, you should probably use vxworks watchdogs instead.
> Xenomai timers are handled in a linked list by default, but you can
> choose other data structures if you have to handle a lot of timers.
> If by timers array, you mean an array of vxworks watchdogs, you do not
> have to worry about locking, this is already done by xenomai vxworks
> services. If what you want to protect is concurrent access to the
> array, then you can use a mutex.
>
> >
> > I use SysClkConnect to hang the clock to a function that send the Give
> > signal to a semaphore every 'n' cycle.
>
> You can use a watchdog for that too.
>
> >
> > the semaphore is used to give the start to a function that handle the
> most
> > important duty of the system, then when it term it cycle, it send the
> Give
> > signal to a second semaphore that will launch a second task that manage
> the
> > lesser important things.
> >
> > This is an overview of my software. there aren't many other thing, only
> the
> > processing of the data received from CAN device, that is a lot of code
> but
> > it don't need the realtime services. this code is executed in the first
> task
> >
> > I hope you understand my needs (my English is not so good).
>
> Do not worry, english is not my mother tongue, so, even if you make
> mistakes, I do not see them.
>
> --
>                                                Gilles Chanteperdrix
>

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

Re: [Xenomai-help] update from fusion 0.9.1 to xenomai 2.4.0

[Gilles Chanteperdrix]

On Dec 30, 2007 9:17 PM, Racconico Lambrati
<racconico.lambrati@domain.hid> wrote:
> I've done some works, and searched in xenomai's native function.
>
> To replace SysClkConnect I've created a periodic task with priority=90 that
> wait 5ms.
> The last operation in a task's cycle is semGive(gServiceSem);
> A second task, non periodic, have as first operation of the cycle
> semTake(gServiceSem,WAIT_FOREVER);
> the second task has priority=50
>
> when the total time for one cycle of task1 and task2 everything seems run
> properly , when task2 take more then 5ms for do it's cycle
> rt_task_wait_period(NULL) return me 146 and not 0, and the time for task1 is
> not respected.
>
> This sound strange for me, why the scheduler don't switch the task in
> execution?

This looks strange, could you try and reduce your application to a
simple example which exhibits the same behaviour ? Maybe you lock the
scheduler with taskLock/taskUnlock ?

> A second question is, if can I change (TaskIdSelf() == IdTask) with
> (rt_task_self() == &IdTask)?

No, the task id spaces are distinct. You can only use TaskIdSelf in a
vxworks skin task (created with taskInit or taskSpawn) and
rt_task_self with a native skin task (created with rt_task_create).
You can use most native skin services (such as rt_task_set_periodic
with a NULL task id) in  a vxworks skin task, but vxworks skin
services expect a vxworks skin task. If I were you, I would use only
vxworks skin services (for example, watchdog services to make a task
perdioc).

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] update from fusion 0.9.1 to xenomai 2.4.0

[Racconico Lambrati]

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

2007/12/31, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
>
> On Dec 30, 2007 9:17 PM, Racconico Lambrati
> <racconico.lambrati@domain.hid> wrote:
> > I've done some works, and searched in xenomai's native function.
> >
> > To replace SysClkConnect I've created a periodic task with priority=90
> that
> > wait 5ms.
> > The last operation in a task's cycle is semGive(gServiceSem);
> > A second task, non periodic, have as first operation of the cycle
> > semTake(gServiceSem,WAIT_FOREVER);
> > the second task has priority=50
> >
> > when the total time for one cycle of task1 and task2 everything seems
> run
> > properly , when task2 take more then 5ms for do it's cycle
> > rt_task_wait_period(NULL) return me 146 and not 0, and the time for
> task1 is
> > not respected.
> >
> > This sound strange for me, why the scheduler don't switch the task in
> > execution?
>
> This looks strange, could you try and reduce your application to a
> simple example which exhibits the same behaviour ? Maybe you lock the
> scheduler with taskLock/taskUnlock ?


I use the rt_task_set_mode with T_LOCK option in critical section, could it
be the cause of the problem?


> A second question is, if can I change (TaskIdSelf() == IdTask) with
> > (rt_task_self() == &IdTask)?
>
> No, the task id spaces are distinct. You can only use TaskIdSelf in a
> vxworks skin task (created with taskInit or taskSpawn) and
> rt_task_self with a native skin task (created with rt_task_create).
> You can use most native skin services (such as rt_task_set_periodic
> with a NULL task id) in  a vxworks skin task, but vxworks skin
> services expect a vxworks skin task. If I were you, I would use only
> vxworks skin services (for example, watchdog services to make a task
> perdioc).


I changed all the handling of task to native skin, so IdTask now is a
RT_TASK variable.

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

Re: [Xenomai-help] update from fusion 0.9.1 to xenomai 2.4.0

[Gilles Chanteperdrix]

On Dec 31, 2007 3:58 PM, Racconico Lambrati
<racconico.lambrati@domain.hid> wrote:
>
>
> 2007/12/31, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> > On Dec 30, 2007 9:17 PM, Racconico Lambrati
> > <racconico.lambrati@domain.hid> wrote:
> > > I've done some works, and searched in xenomai's native function.
> > >
> > > To replace SysClkConnect I've created a periodic task with priority=90
> that
> > > wait 5ms.
> > > The last operation in a task's cycle is semGive(gServiceSem);
> > > A second task, non periodic, have as first operation of the cycle
> > > semTake(gServiceSem,WAIT_FOREVER);
> > > the second task has priority=50
> > >
> > > when the total time for one cycle of task1 and task2 everything seems
> run
> > > properly , when task2 take more then 5ms for do it's cycle
> > > rt_task_wait_period(NULL) return me 146 and not 0, and the time for
> task1 is
> > > not respected.
> > >
> > > This sound strange for me, why the scheduler don't switch the task in
> > > execution?
> >
> > This looks strange, could you try and reduce your application to a
> > simple example which exhibits the same behaviour ? Maybe you lock the
> > scheduler with taskLock/taskUnlock ?
>
> I use the rt_task_set_mode with T_LOCK option in critical section, could it
> be the cause of the problem?

Yes, the aim of T_LOCK is precisely to prevent the scheduler from
switching to another task as long as the bit is armed.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] update from fusion 0.9.1 to xenomai 2.4.0

[Racconico Lambrati]

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

2007/12/31, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
>
> On Dec 31, 2007 3:58 PM, Racconico Lambrati
> <racconico.lambrati@domain.hid> wrote:
> >
> >
> > 2007/12/31, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> > > On Dec 30, 2007 9:17 PM, Racconico Lambrati
> > > <racconico.lambrati@domain.hid> wrote:
> > > > I've done some works, and searched in xenomai's native function.
> > > >
> > > > To replace SysClkConnect I've created a periodic task with
> priority=90
> > that
> > > > wait 5ms.
> > > > The last operation in a task's cycle is semGive(gServiceSem);
> > > > A second task, non periodic, have as first operation of the cycle
> > > > semTake(gServiceSem,WAIT_FOREVER);
> > > > the second task has priority=50
> > > >
> > > > when the total time for one cycle of task1 and task2 everything
> seems
> > run
> > > > properly , when task2 take more then 5ms for do it's cycle
> > > > rt_task_wait_period(NULL) return me 146 and not 0, and the time for
> > task1 is
> > > > not respected.
> > > >
> > > > This sound strange for me, why the scheduler don't switch the task
> in
> > > > execution?
> > >
> > > This looks strange, could you try and reduce your application to a
> > > simple example which exhibits the same behaviour ? Maybe you lock the
> > > scheduler with taskLock/taskUnlock ?
> >
> > I use the rt_task_set_mode with T_LOCK option in critical section, could
> it
> > be the cause of the problem?
>
> Yes, the aim of T_LOCK is precisely to prevent the scheduler from
> switching to another task as long as the bit is armed.


But I reset the mask after the critical section...  I'll try without  this
lock and report the result

thanks Racconico

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

Re: [Xenomai-help] update from fusion 0.9.1 to xenomai 2.4.0

[Gilles Chanteperdrix]

On Dec 31, 2007 4:23 PM, Racconico Lambrati
<racconico.lambrati@domain.hid> wrote:
>
>
>
>
> 2007/12/31, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> > On Dec 31, 2007 3:58 PM, Racconico Lambrati
> > <racconico.lambrati@domain.hid> wrote:
> > >
> > >
> > > 2007/12/31, Gilles Chanteperdrix < gilles.chanteperdrix@xenomai.org>:
> > > > On Dec 30, 2007 9:17 PM, Racconico Lambrati
> > > > <racconico.lambrati@domain.hid> wrote:
> > > > > I've done some works, and searched in xenomai's native function.
> > > > >
> > > > > To replace SysClkConnect I've created a periodic task with
> priority=90
> > > that
> > > > > wait 5ms.
> > > > > The last operation in a task's cycle is semGive(gServiceSem);
> > > > > A second task, non periodic, have as first operation of the cycle
> > > > > semTake(gServiceSem,WAIT_FOREVER);
> > > > > the second task has priority=50
> > > > >
> > > > > when the total time for one cycle of task1 and task2 everything
> seems
> > > run
> > > > > properly , when task2 take more then 5ms for do it's cycle
> > > > > rt_task_wait_period(NULL) return me 146 and not 0, and the time for
> > > task1 is
> > > > > not respected.
> > > > >
> > > > > This sound strange for me, why the scheduler don't switch the task
> in
> > > > > execution?
> > > >
> > > > This looks strange, could you try and reduce your application to a
> > > > simple example which exhibits the same behaviour ? Maybe you lock the
> > > > scheduler with taskLock/taskUnlock ?
> > >
> > > I use the rt_task_set_mode with T_LOCK option in critical section, could
> it
> > > be the cause of the problem?
> >
> > Yes, the aim of T_LOCK is precisely to prevent the scheduler from
> > switching to another task as long as the bit is armed.
>
> But I reset the mask after the critical section...  I'll try without  this
> lock and report the result

I recently noticed something strange in xnpod_schedule which might
explain this bug: when the T_LOCK bit is set, xnpod_schedule clears
the rescheduling bit even though it does not reschedule. So, could you
try, in xnpod_schedule, to replace:

if (xnthread_test_state(runthread, XNLOCK))
        goto signal_unlock_and_exit;

with:

if (xnthread_test_state(runthread, XNLOCK)) {
        xnsched_set_resched(sched);
        goto signal_unlock_and_exit;
}

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] update from fusion 0.9.1 to xenomai 2.4.0

[Racconico Lambrati]

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

2008/1/23, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
>
> On Dec 31, 2007 4:23 PM, Racconico Lambrati
> <racconico.lambrati@domain.hid> wrote:
> >
> >
> >
> >
> > 2007/12/31, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> > > On Dec 31, 2007 3:58 PM, Racconico Lambrati
> > > <racconico.lambrati@domain.hid> wrote:
> > > >
> > > >
> > > > 2007/12/31, Gilles Chanteperdrix < gilles.chanteperdrix@xenomai.org>:
> > > > > On Dec 30, 2007 9:17 PM, Racconico Lambrati
> > > > > <racconico.lambrati@domain.hid> wrote:
> > > > > > I've done some works, and searched in xenomai's native function.
> > > > > >
> > > > > > To replace SysClkConnect I've created a periodic task with
> > priority=90
> > > > that
> > > > > > wait 5ms.
> > > > > > The last operation in a task's cycle is semGive(gServiceSem);
> > > > > > A second task, non periodic, have as first operation of the
> cycle
> > > > > > semTake(gServiceSem,WAIT_FOREVER);
> > > > > > the second task has priority=50
> > > > > >
> > > > > > when the total time for one cycle of task1 and task2 everything
> > seems
> > > > run
> > > > > > properly , when task2 take more then 5ms for do it's cycle
> > > > > > rt_task_wait_period(NULL) return me 146 and not 0, and the time
> for
> > > > task1 is
> > > > > > not respected.
> > > > > >
> > > > > > This sound strange for me, why the scheduler don't switch the
> task
> > in
> > > > > > execution?
> > > > >
> > > > > This looks strange, could you try and reduce your application to a
> > > > > simple example which exhibits the same behaviour ? Maybe you lock
> the
> > > > > scheduler with taskLock/taskUnlock ?
> > > >
> > > > I use the rt_task_set_mode with T_LOCK option in critical section,
> could
> > it
> > > > be the cause of the problem?
> > >
> > > Yes, the aim of T_LOCK is precisely to prevent the scheduler from
> > > switching to another task as long as the bit is armed.
> >
> > But I reset the mask after the critical section...  I'll try
> without  this
> > lock and report the result
>
> I recently noticed something strange in xnpod_schedule which might
> explain this bug: when the T_LOCK bit is set, xnpod_schedule clears
> the rescheduling bit even though it does not reschedule. So, could you
> try, in xnpod_schedule, to replace:
>
> if (xnthread_test_state(runthread, XNLOCK))
>         goto signal_unlock_and_exit;
>
> with:
>
> if (xnthread_test_state(runthread, XNLOCK)) {
>         xnsched_set_resched(sched);
>         goto signal_unlock_and_exit;
> }
>
> --
>                                                Gilles Chanteperdrix
>

I make this change but nothing changed...

The deadlock it seem not connected to rt_task_set_mode because if I remove
it the deadlock is always present.

when the cycle for(i=0;i<=1000;i++)    appo*=1.01;
do more then 100000 cycle came the deadlock...

It's seems that is related to rt_task_wait_period

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

Re: [Xenomai-help] update from fusion 0.9.1 to xenomai 2.4.0

[Gilles Chanteperdrix]

On Jan 29, 2008 10:15 AM, Racconico Lambrati
<racconico.lambrati@domain.hid> wrote:
>
>
> 2008/1/23, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
>
> > On Dec 31, 2007 4:23 PM, Racconico Lambrati
> > <racconico.lambrati@domain.hid> wrote:
> > >
> > >
> > >
> > >
> > > 2007/12/31, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> > > > On Dec 31, 2007 3:58 PM, Racconico Lambrati
> > > > <racconico.lambrati@domain.hid> wrote:
> > > > >
> > > > >
> > > > > 2007/12/31, Gilles Chanteperdrix < gilles.chanteperdrix@xenomai.org>:
> > > > > > On Dec 30, 2007 9:17 PM, Racconico Lambrati
> > > > > > <racconico.lambrati@domain.hid> wrote:
> > > > > > > I've done some works, and searched in xenomai's native function.
> > > > > > >
> > > > > > > To replace SysClkConnect I've created a periodic task with
> > > priority=90
> > > > > that
> > > > > > > wait 5ms.
> > > > > > > The last operation in a task's cycle is semGive(gServiceSem);
> > > > > > > A second task, non periodic, have as first operation of the
> cycle
> > > > > > > semTake(gServiceSem,WAIT_FOREVER);
> > > > > > > the second task has priority=50
> > > > > > >
> > > > > > > when the total time for one cycle of task1 and task2 everything
> > > seems
> > > > > run
> > > > > > > properly , when task2 take more then 5ms for do it's cycle
> > > > > > > rt_task_wait_period(NULL) return me 146 and not 0, and the time
> for
> > > > > task1 is
> > > > > > > not respected.
> > > > > > >
> > > > > > > This sound strange for me, why the scheduler don't switch the
> task
> > > in
> > > > > > > execution?
> > > > > >
> > > > > > This looks strange, could you try and reduce your application to a
> > > > > > simple example which exhibits the same behaviour ? Maybe you lock
> the
> > > > > > scheduler with taskLock/taskUnlock ?
> > > > >
> > > > > I use the rt_task_set_mode with T_LOCK option in critical section,
> could
> > > it
> > > > > be the cause of the problem?
> > > >
> > > > Yes, the aim of T_LOCK is precisely to prevent the scheduler from
> > > > switching to another task as long as the bit is armed.
> > >
> > > But I reset the mask after the critical section...  I'll try without
> this
> > > lock and report the result
> >
> > I recently noticed something strange in xnpod_schedule which might
> > explain this bug: when the T_LOCK bit is set, xnpod_schedule clears
> > the rescheduling bit even though it does not reschedule. So, could you
> > try, in xnpod_schedule, to replace:
> >
> > if (xnthread_test_state(runthread, XNLOCK))
> >         goto signal_unlock_and_exit;
> >
> > with:
> >
> > if (xnthread_test_state(runthread, XNLOCK)) {
> >         xnsched_set_resched(sched);
> >         goto signal_unlock_and_exit;
> > }
> >
> > --
> >                                                Gilles Chanteperdrix
> >
>
> I make this change but nothing changed...
>
> The deadlock it seem not connected to rt_task_set_mode because if I remove
> it the deadlock is always present.
>
> when the cycle for(i=0;i<=1000;i++)    appo*=1.01;
>  do more then 100000 cycle came the deadlock...
>
> It's seems that is related to rt_task_wait_period

Please do not forget that if Linux never runs, it is normal to observe a lockup.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] update from fusion 0.9.1 to xenomai 2.4.0

[Racconico Lambrati]

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

I've make a more clever test program (I hope).

The scheduler work fine but there is some other problem

First of all I've reduced the working time into the two task (to avoid
deadlock as you suggested). I also insert the code that in corresponding of
the two task high a bit on the parallel port.
Then I use the oscilloscope to test that every 5 milliseconds the TaskPlc
start it's execution. In normal condition there's no problem, but when I
make a write on the disk, or I mount an external device the time of High
priority task increase in considerable  manner.

I cannot explain this situation, that is not respecting the priority of the
task...


2008/1/29, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
>
> On Jan 29, 2008 10:15 AM, Racconico Lambrati
> <racconico.lambrati@domain.hid> wrote:
> >
> >
> > 2008/1/23, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> >
> > > On Dec 31, 2007 4:23 PM, Racconico Lambrati
> > > <racconico.lambrati@domain.hid> wrote:
> > > >
> > > >
> > > >
> > > >
> > > > 2007/12/31, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>:
> > > > > On Dec 31, 2007 3:58 PM, Racconico Lambrati
> > > > > <racconico.lambrati@domain.hid> wrote:
> > > > > >
> > > > > >
> > > > > > 2007/12/31, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org>:
> > > > > > > On Dec 30, 2007 9:17 PM, Racconico Lambrati
> > > > > > > <racconico.lambrati@domain.hid> wrote:
> > > > > > > > I've done some works, and searched in xenomai's native
> function.
> > > > > > > >
> > > > > > > > To replace SysClkConnect I've created a periodic task with
> > > > priority=90
> > > > > > that
> > > > > > > > wait 5ms.
> > > > > > > > The last operation in a task's cycle is
> semGive(gServiceSem);
> > > > > > > > A second task, non periodic, have as first operation of the
> > cycle
> > > > > > > > semTake(gServiceSem,WAIT_FOREVER);
> > > > > > > > the second task has priority=50
> > > > > > > >
> > > > > > > > when the total time for one cycle of task1 and task2
> everything
> > > > seems
> > > > > > run
> > > > > > > > properly , when task2 take more then 5ms for do it's cycle
> > > > > > > > rt_task_wait_period(NULL) return me 146 and not 0, and the
> time
> > for
> > > > > > task1 is
> > > > > > > > not respected.
> > > > > > > >
> > > > > > > > This sound strange for me, why the scheduler don't switch
> the
> > task
> > > > in
> > > > > > > > execution?
> > > > > > >
> > > > > > > This looks strange, could you try and reduce your application
> to a
> > > > > > > simple example which exhibits the same behaviour ? Maybe you
> lock
> > the
> > > > > > > scheduler with taskLock/taskUnlock ?
> > > > > >
> > > > > > I use the rt_task_set_mode with T_LOCK option in critical
> section,
> > could
> > > > it
> > > > > > be the cause of the problem?
> > > > >
> > > > > Yes, the aim of T_LOCK is precisely to prevent the scheduler from
> > > > > switching to another task as long as the bit is armed.
> > > >
> > > > But I reset the mask after the critical section...  I'll try without
> > this
> > > > lock and report the result
> > >
> > > I recently noticed something strange in xnpod_schedule which might
> > > explain this bug: when the T_LOCK bit is set, xnpod_schedule clears
> > > the rescheduling bit even though it does not reschedule. So, could you
> > > try, in xnpod_schedule, to replace:
> > >
> > > if (xnthread_test_state(runthread, XNLOCK))
> > >         goto signal_unlock_and_exit;
> > >
> > > with:
> > >
> > > if (xnthread_test_state(runthread, XNLOCK)) {
> > >         xnsched_set_resched(sched);
> > >         goto signal_unlock_and_exit;
> > > }
> > >
> > > --
> > >                                                Gilles Chanteperdrix
> > >
> >
> > I make this change but nothing changed...
> >
> > The deadlock it seem not connected to rt_task_set_mode because if I
> remove
> > it the deadlock is always present.
> >
> > when the cycle for(i=0;i<=1000;i++)    appo*=1.01;
> >  do more then 100000 cycle came the deadlock...
> >
> > It's seems that is related to rt_task_wait_period
>
> Please do not forget that if Linux never runs, it is normal to observe a
> lockup.
>
> --
>                                                Gilles Chanteperdrix
>

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

[-- Attachment #2: testSched.tar --]
[-- Type: application/x-tar, Size: 61440 bytes --]

Re: [Xenomai-help] update from fusion 0.9.1 to xenomai 2.4.0

[Gilles Chanteperdrix]

On Thu, Jan 31, 2008 at 9:10 AM, Racconico Lambrati
<racconico.lambrati@domain.hid> wrote:
> I've make a more clever test program (I hope).
>
> The scheduler work fine but there is some other problem
>
> First of all I've reduced the working time into the two task (to avoid
> deadlock as you suggested). I also insert the code that in corresponding of
> the two task high a bit on the parallel port.
>  Then I use the oscilloscope to test that every 5 milliseconds the TaskPlc
> start it's execution. In normal condition there's no problem, but when I
> make a write on the disk, or I mount an external device the time of High
> priority task increase in considerable  manner.
>
> I cannot explain this situation, that is not respecting the priority of the
> task...

The printf between the two calls to sysOutByte causes your tasks to
switch to secondary mode, if you had set the T_WARNSW bit, you would
have been informed of the mode switch by a signal. If using a recent
version of Xenomai, #include <rtdk.h> and use rt_printf instead of
printf.


-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] update from fusion 0.9.1 to xenomai 2.4.0

[Gilles Chanteperdrix]

On Thu, Jan 31, 2008 at 9:10 AM, Racconico Lambrati
<racconico.lambrati@domain.hid> wrote:
> I've make a more clever test program (I hope).
>
> The scheduler work fine but there is some other problem
>
> First of all I've reduced the working time into the two task (to avoid
> deadlock as you suggested). I also insert the code that in corresponding of
> the two task high a bit on the parallel port.
>  Then I use the oscilloscope to test that every 5 milliseconds the TaskPlc
> start it's execution. In normal condition there's no problem, but when I
> make a write on the disk, or I mount an external device the time of High
> priority task increase in considerable  manner.
>
> I cannot explain this situation, that is not respecting the priority of the
> task...

Setting the task mode to primary mode before calling
rt_task_wait_period is just wasting time for a useless syscall:
rt_task_wait_period already migrates the calling task to primary mode.

-- 
                                               Gilles Chanteperdrix