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