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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [EMAIL PROTECTED] https://mail.gna.org/listinfo/xenomai-help
