[Xenomai-help] Execution error with rtdm heartbeat example

[Xenomai-help] Execution error with rtdm heartbeat example

[Jean-Luc Pamart]

Hello

I  try to execute the heartbeat example (xenomai 2.3 with kernel 2.6.19)
With the unmodified sources when the heartbeat module
is being unloaded (rmmod)  I obtain :

atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying 
access hardware directly.  

and the unloading can't be finished.

I try to slightly change the sources. It works with no bad kernel 
message and
complete unloaded with this modification :

void heartbeat(void *cookie)
{
       
        while (!end) {
              ...
        }
    set_leds(0);
    
}
void cleanup_module(void)
{
    //  set_leds(0);
}  

My interpretation :
In the non modified example, We try to access directly to the keyboard
after the end of the rt-driver(after  
rtdm_task_join_nrt(&heartbeat_task, 100);)
So it is a problem for the kernel.

Is it a good interpretation ?
 
what is the difference between rtdm_task_join_nrt(&heartbeat_task, 100) and
 rtdm_task_destroy(&heartbeat_task) ?
What is the role of the polling argument (value 100) ?


best regards

Re: [Xenomai-help] Execution error with rtdm heartbeat example

[Jan Kiszka]

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

Jean-Luc Pamart wrote:
> Hello
> 
> I  try to execute the heartbeat example (xenomai 2.3 with kernel 2.6.19)
> With the unmodified sources when the heartbeat module
> is being unloaded (rmmod)  I obtain :
> 
> atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying 
> access hardware directly.  
> 
> and the unloading can't be finished.
> 
> I try to slightly change the sources. It works with no bad kernel 
> message and
> complete unloaded with this modification :
> 
> void heartbeat(void *cookie)
> {
>        
>         while (!end) {
>               ...
>         }
>     set_leds(0);
>     
> }
> void cleanup_module(void)
> {
>     //  set_leds(0);
> }  
> 
> My interpretation :
> In the non modified example, We try to access directly to the keyboard
> after the end of the rt-driver(after  
> rtdm_task_join_nrt(&heartbeat_task, 100);)
> So it is a problem for the kernel.

Hmm, the problem might be that set_leds(0) gets preempted. Could you try

local_irq_disable();
set_leds(0);
local_irq_enable();

for cleanup_module()?

Yes, this demo accesses shared hardware directly, and that can confuse
Linux or cause even worse situations. Moreover, this high-prio task also
causes fairly high latencies. So it is nothing for serious use anyway.
But if we can improve obvious issues, there is no need to hesitate.

> 
> Is it a good interpretation ?
>  
> what is the difference between rtdm_task_join_nrt(&heartbeat_task, 100) and
>  rtdm_task_destroy(&heartbeat_task) ?
> What is the role of the polling argument (value 100) ?

Not being too lazy to answer, but I would like to know if the doc is
improvable: Did you read the API documentation [1]?

Jan

[1]http://www.xenomai.org/documentation/branches/v2.3.x/html/api/group__rtdmtask.html


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Execution error with rtdm heartbeat example

[Jean-Luc Pamart]

Jan Kiszka a écrit :
> Jean-Luc Pamart wrote:
>   
>> Hello
>>
>> I  try to execute the heartbeat example (xenomai 2.3 with kernel 2.6.19)
>> With the unmodified sources when the heartbeat module
>> is being unloaded (rmmod)  I obtain :
>>
>> atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying 
>> access hardware directly.  
>>
>> and the unloading can't be finished.
>>
>> I try to slightly change the sources. It works with no bad kernel 
>> message and
>> complete unloaded with this modification :
>>
>> void heartbeat(void *cookie)
>> {
>>        
>>         while (!end) {
>>               ...
>>         }
>>     set_leds(0);
>>     
>> }
>> void cleanup_module(void)
>> {
>>     //  set_leds(0);
>> }  
>>
>> My interpretation :
>> In the non modified example, We try to access directly to the keyboard
>> after the end of the rt-driver(after  
>> rtdm_task_join_nrt(&heartbeat_task, 100);)
>> So it is a problem for the kernel.
>>     
>
> Hmm, the problem might be that set_leds(0) gets preempted. Could you try
>
> local_irq_disable();
> set_leds(0);
> local_irq_enable();
>
> for cleanup_module()?
>
> Yes, this demo accesses shared hardware directly, and that can confuse
> Linux or cause even worse situations. Moreover, this high-prio task also
> causes fairly high latencies. So it is nothing for serious use anyway.
> But if we can improve obvious issues, there is no need to hesitate.
>
>   
>> Is it a good interpretation ?
>>  
>> what is the difference between rtdm_task_join_nrt(&heartbeat_task, 100) and
>>  rtdm_task_destroy(&heartbeat_task) ?
>> What is the role of the polling argument (value 100) ?
>>     
>
> Not being too lazy to answer, but I would like to know if the doc is
> improvable: Did you read the API documentation [1]?
>
> Jan
>
> [1]http://www.xenomai.org/documentation/branches/v2.3.x/html/api/group__rtdmtask.html
>
>   
Hi

I don't want to use this example for a real application.
It's only for the "fun" : I' ll have to write a rtdm driver
so now, I study ...

That's was a good proposition for the heartbeat module :

void cleanup_module(void)
{
    end = 1;
    rtdm_task_join_nrt(&heartbeat_task, 100); 
    local_irq_disable();     // to be added
    set_leds(0);
    local_irq_enable();     // to be added
}

1 / it run as usual very well
2/ his unloading can finish
3/ his unloading doesn't anymore cause  "Spurious ACK .."
so all is all right now !


But, this problem appears only when unloading the module.
After all, set_leds() is used by heartbeat() without any problem.
Why not in cleanup_module() ?
Sorry it's perhaps an obviousness but not for me.

I have red the rtdm_api.pdf doc which is embedded with the Xenomai sources.
I'd like to try "hello world examples" for a more large point of view
and some easy begining you haven't when you read the documentation :
a list of functions and a brief use - too short for the beginner i am -
Well, it's the same situation (it's my point of view, perhaps I am alone ??)
when you try to write a letter in a unknown language :
the dictionnaries are good for spelling not for grammar (construct of
the sentence).

So for the differences between rtdm_task_join_nrt and rtdm_task_destroy,
what I understand :

1/rtdm_task_destroy(&heartbeat_task)
Stop and destroy immediately the target task.

2/rtdm_task_join_nrt(&heartbeat_task, 100);
Wait for the end of target task
It is the user to take care of the termination of the target task
If not, rtdm will never return
(the task must cooperate)

Ok but what is "polling delay" for ?
At the first look I think about a watchdog but it's not the case

Sorry for these obvious issues !

BTW, the "real-time" answers of this forum is impressive : bravo !


Jean-Luc

Re: [Xenomai-help] Execution error with rtdm heartbeat example

[Jan Kiszka]

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

Jean-Luc Pamart wrote:
> Jan Kiszka a écrit :
>> Jean-Luc Pamart wrote:
>>  
>>> Hello
>>>
>>> I  try to execute the heartbeat example (xenomai 2.3 with kernel 2.6.19)
>>> With the unmodified sources when the heartbeat module
>>> is being unloaded (rmmod)  I obtain :
>>>
>>> atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying
>>> access hardware directly. 
>>> and the unloading can't be finished.
>>>
>>> I try to slightly change the sources. It works with no bad kernel
>>> message and
>>> complete unloaded with this modification :
>>>
>>> void heartbeat(void *cookie)
>>> {
>>>                while (!end) {
>>>               ...
>>>         }
>>>     set_leds(0);
>>>     }
>>> void cleanup_module(void)
>>> {
>>>     //  set_leds(0);
>>> } 
>>> My interpretation :
>>> In the non modified example, We try to access directly to the keyboard
>>> after the end of the rt-driver(after 
>>> rtdm_task_join_nrt(&heartbeat_task, 100);)
>>> So it is a problem for the kernel.
>>>     
>>
>> Hmm, the problem might be that set_leds(0) gets preempted. Could you try
>>
>> local_irq_disable();
>> set_leds(0);
>> local_irq_enable();
>>
>> for cleanup_module()?
>>
>> Yes, this demo accesses shared hardware directly, and that can confuse
>> Linux or cause even worse situations. Moreover, this high-prio task also
>> causes fairly high latencies. So it is nothing for serious use anyway.
>> But if we can improve obvious issues, there is no need to hesitate.
>>
>>  
>>> Is it a good interpretation ?
>>>  
>>> what is the difference between rtdm_task_join_nrt(&heartbeat_task,
>>> 100) and
>>>  rtdm_task_destroy(&heartbeat_task) ?
>>> What is the role of the polling argument (value 100) ?
>>>     
>>
>> Not being too lazy to answer, but I would like to know if the doc is
>> improvable: Did you read the API documentation [1]?
>>
>> Jan
>>
>> [1]http://www.xenomai.org/documentation/branches/v2.3.x/html/api/group__rtdmtask.html
>>
>>
>>   
> Hi
> 
> I don't want to use this example for a real application.
> It's only for the "fun" : I' ll have to write a rtdm driver
> so now, I study ...
> 
> That's was a good proposition for the heartbeat module :
> 
> void cleanup_module(void)
> {
>    end = 1;
>    rtdm_task_join_nrt(&heartbeat_task, 100);    local_irq_disable();    
> // to be added
>    set_leds(0);
>    local_irq_enable();     // to be added
> }
> 
> 1 / it run as usual very well
> 2/ his unloading can finish
> 3/ his unloading doesn't anymore cause  "Spurious ACK .."
> so all is all right now !
> 

OK, good know. That experiment was just to check the theory, I will
actually commit your first proposal as fix (call set_leds before leaving
heartbeat()). It's shorter.

> 
> But, this problem appears only when unloading the module.
> After all, set_leds() is used by heartbeat() without any problem.
> Why not in cleanup_module() ?
> Sorry it's perhaps an obviousness but not for me.

The difference between the RTDM task function heartbeat() and
cleanup_module() is the execution context: the former it RT, thus cannot
be preempted by any Linux activity, the latter is a Linux task that is
preemptible by Linux interrupts or other Linux tasks, including other
keyboard-using code.

Actually, all this is only true for single-processor systems. SMP will
cause troubles due to the unsynchronised HW access of Linux vs.
hearbeat. Anyway, this remains an imperfect demo.

> 
> I have red the rtdm_api.pdf doc which is embedded with the Xenomai sources.
> I'd like to try "hello world examples" for a more large point of view
> and some easy begining you haven't when you read the documentation :
> a list of functions and a brief use - too short for the beginner i am -
> Well, it's the same situation (it's my point of view, perhaps I am alone
> ??)
> when you try to write a letter in a unknown language :
> the dictionnaries are good for spelling not for grammar (construct of
> the sentence).

Yep, I understand and agree. Still, writing appropriate introductions
for all this, either as text or in form of thoroughly worked out
examples, takes quite some effort (means: time).

Therefore, the best would be if some former beginners help us by filling
gaps in the existing documentation and/or examples repository. Fixing
remaining glitches in their contribution is not a big problem (see e.g.
how the RTnet docs started on xenomai.org). The point is that we would
then already know where to invest required effort effectively. Keep in
mind: individual project contributors don't scale infinitely, thus the
team size need to.

> 
> So for the differences between rtdm_task_join_nrt and rtdm_task_destroy,
> what I understand :
> 
> 1/rtdm_task_destroy(&heartbeat_task)
> Stop and destroy immediately the target task.
> 
> 2/rtdm_task_join_nrt(&heartbeat_task, 100);
> Wait for the end of target task
> It is the user to take care of the termination of the target task
> If not, rtdm will never return
> (the task must cooperate)
> 
> Ok but what is "polling delay" for ?
> At the first look I think about a watchdog but it's not the case
> 
> Sorry for these obvious issues !

No need to apologise, specifically as that "polling delay" is in fact
badly documented. rtdm_task_join_nrt() may wait on the termination by
periodically checking (polling) the RT task state. So the delay defines
this period. Will fix.

> 
> BTW, the "real-time" answers of this forum is impressive : bravo !
> 

I think this is mandatory for real-time projects, isn't it? ;)

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] Execution error with rtdm heartbeat example

[Jean-Luc Pamart]

Jan Kiszka a écrit :
> Jean-Luc Pamart wrote:
>   
>> Jan Kiszka a écrit :
>>     
>>> Jean-Luc Pamart wrote:
>>>  
>>>       
>>>> Hello
>>>>
>>>> I  try to execute the heartbeat example (xenomai 2.3 with kernel 2.6.19)
>>>> With the unmodified sources when the heartbeat module
>>>> is being unloaded (rmmod)  I obtain :
>>>>
>>>> atkbd.c: Spurious ACK on isa0060/serio0. Some program might be trying
>>>> access hardware directly. 
>>>> and the unloading can't be finished.
>>>>
>>>> I try to slightly change the sources. It works with no bad kernel
>>>> message and
>>>> complete unloaded with this modification :
>>>>
>>>> void heartbeat(void *cookie)
>>>> {
>>>>                while (!end) {
>>>>               ...
>>>>         }
>>>>     set_leds(0);
>>>>     }
>>>> void cleanup_module(void)
>>>> {
>>>>     //  set_leds(0);
>>>> } 
>>>> My interpretation :
>>>> In the non modified example, We try to access directly to the keyboard
>>>> after the end of the rt-driver(after 
>>>> rtdm_task_join_nrt(&heartbeat_task, 100);)
>>>> So it is a problem for the kernel.
>>>>     
>>>>         
>>> Hmm, the problem might be that set_leds(0) gets preempted. Could you try
>>>
>>> local_irq_disable();
>>> set_leds(0);
>>> local_irq_enable();
>>>
>>> for cleanup_module()?
>>>
>>> Yes, this demo accesses shared hardware directly, and that can confuse
>>> Linux or cause even worse situations. Moreover, this high-prio task also
>>> causes fairly high latencies. So it is nothing for serious use anyway.
>>> But if we can improve obvious issues, there is no need to hesitate.
>>>
>>>  
>>>       
>>>> Is it a good interpretation ?
>>>>  
>>>> what is the difference between rtdm_task_join_nrt(&heartbeat_task,
>>>> 100) and
>>>>  rtdm_task_destroy(&heartbeat_task) ?
>>>> What is the role of the polling argument (value 100) ?
>>>>     
>>>>         
>>> Not being too lazy to answer, but I would like to know if the doc is
>>> improvable: Did you read the API documentation [1]?
>>>
>>> Jan
>>>
>>> [1]http://www.xenomai.org/documentation/branches/v2.3.x/html/api/group__rtdmtask.html
>>>
>>>
>>>   
>>>       
>> Hi
>>
>> I don't want to use this example for a real application.
>> It's only for the "fun" : I' ll have to write a rtdm driver
>> so now, I study ...
>>
>> That's was a good proposition for the heartbeat module :
>>
>> void cleanup_module(void)
>> {
>>    end = 1;
>>    rtdm_task_join_nrt(&heartbeat_task, 100);    local_irq_disable();    
>> // to be added
>>    set_leds(0);
>>    local_irq_enable();     // to be added
>> }
>>
>> 1 / it run as usual very well
>> 2/ his unloading can finish
>> 3/ his unloading doesn't anymore cause  "Spurious ACK .."
>> so all is all right now !
>>
>>     
>
> OK, good know. That experiment was just to check the theory, I will
> actually commit your first proposal as fix (call set_leds before leaving
> heartbeat()). It's shorter.
>
>   
>> But, this problem appears only when unloading the module.
>> After all, set_leds() is used by heartbeat() without any problem.
>> Why not in cleanup_module() ?
>> Sorry it's perhaps an obviousness but not for me.
>>     
>
> The difference between the RTDM task function heartbeat() and
> cleanup_module() is the execution context: the former it RT, thus cannot
> be preempted by any Linux activity, the latter is a Linux task that is
> preemptible by Linux interrupts or other Linux tasks, including other
> keyboard-using code.
>
> Actually, all this is only true for single-processor systems. SMP will
> cause troubles due to the unsynchronised HW access of Linux vs.
> hearbeat. Anyway, this remains an imperfect demo.
>
>   
>> I have red the rtdm_api.pdf doc which is embedded with the Xenomai sources.
>> I'd like to try "hello world examples" for a more large point of view
>> and some easy begining you haven't when you read the documentation :
>> a list of functions and a brief use - too short for the beginner i am -
>> Well, it's the same situation (it's my point of view, perhaps I am alone
>> ??)
>> when you try to write a letter in a unknown language :
>> the dictionnaries are good for spelling not for grammar (construct of
>> the sentence).
>>     
>
> Yep, I understand and agree. Still, writing appropriate introductions
> for all this, either as text or in form of thoroughly worked out
> examples, takes quite some effort (means: time).
>
> Therefore, the best would be if some former beginners help us by filling
> gaps in the existing documentation and/or examples repository. Fixing
> remaining glitches in their contribution is not a big problem (see e.g.
> how the RTnet docs started on xenomai.org). The point is that we would
> then already know where to invest required effort effectively. 
I work for a school project "systeme de vision artificielle pour 
prétailleuse" : a tractor which cut the vine of Champagne
(the famous drink ...)
The embedded application will analyse the movies in real time and lead 
the cutting part of this machine (with a CAN-BUS).
I have to write a driver which interface a PCI board (connected to a 
little camera) and ask
Rodrigo Rosenfeld Rosas for a squeletton of his driver.
So, I think I have now a beginning ...
In the future, if the project is finished, I can send the whole driver 
to the xenomai-forum
with, (if you find that interresting) some explanations (from a beginner 
point of view)

> Keep in
> mind: individual project contributors don't scale infinitely, thus the
> team size need to.
>
>   
Do you mean that there isnt enought contributors or the team whant to be 
bigger ?


>> So for the differences between rtdm_task_join_nrt and rtdm_task_destroy,
>> what I understand :
>>
>> 1/rtdm_task_destroy(&heartbeat_task)
>> Stop and destroy immediately the target task.
>>
>> 2/rtdm_task_join_nrt(&heartbeat_task, 100);
>> Wait for the end of target task
>> It is the user to take care of the termination of the target task
>> If not, rtdm will never return
>> (the task must cooperate)
>>
>> Ok but what is "polling delay" for ?
>> At the first look I think about a watchdog but it's not the case
>>
>> Sorry for these obvious issues !
>>     
>
> No need to apologise, specifically as that "polling delay" is in fact
> badly documented. rtdm_task_join_nrt() may wait on the termination by
> periodically checking (polling) the RT task state. So the delay defines
> this period. Will fix.
>
>   
Ok it's clear now :
some of the fonctions are in rt context and the others not and especially
the interface with insmod, rmmod etc. obviously in user mode.


>> BTW, the "real-time" answers of this forum is impressive : bravo !
>>
>>     
>
> I think this is mandatory for real-time projects, isn't it? ;)
>   
yes !

> Jan
>
>   

Re: [Xenomai-help] Execution error with rtdm heartbeat example

[Jan Kiszka]

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

Jean-Luc Pamart wrote:
> Jan Kiszka a écrit :
>> ...
>> Therefore, the best would be if some former beginners help us by filling
>> gaps in the existing documentation and/or examples repository. Fixing
>> remaining glitches in their contribution is not a big problem (see e.g.
>> how the RTnet docs started on xenomai.org). The point is that we would
>> then already know where to invest required effort effectively. 
> I work for a school project "systeme de vision artificielle pour
> prétailleuse" : a tractor which cut the vine of Champagne
> (the famous drink ...)

Well known.

> The embedded application will analyse the movies in real time and lead
> the cutting part of this machine (with a CAN-BUS).
> I have to write a driver which interface a PCI board (connected to a
> little camera) and ask

Sounds like an interesting project - with quite a worthwhile application.

> Rodrigo Rosenfeld Rosas for a squeletton of his driver.
> So, I think I have now a beginning ...
> In the future, if the project is finished, I can send the whole driver
> to the xenomai-forum
> with, (if you find that interresting) some explanations (from a beginner
> point of view)

Great, you are welcome.

> 
>> Keep in
>> mind: individual project contributors don't scale infinitely, thus the
>> team size need to.
>>
>>   
> Do you mean that there isnt enought contributors or the team whant to be
> bigger ?

There more we can distribute work on multiple shoulders, the better and
the faster the project can proceed. Documenting is an important job, not
only hacking core code. But it's not everyone's number #1 favourite if
there is a choice or time is lacking.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]