[Xenomai-help] Getting calling task id inside RTDM driver

[Xenomai-help] Getting calling task id inside RTDM driver

[Sean McGranaghan]

[-- Attachment #1: Type: text/html, Size: 991 bytes --]

Re: [Xenomai-help] Getting calling task id inside RTDM driver

[Sebastian Smolorz]

Am Freitag 14. April 2006 16:30 schrieb Sean McGranaghan:

> I am writing an RTDM driver that needs a simple task suspend/resume. I
> have a simple ioctl() that needs to initiate some io and then sleep
> until an interrupt occurs. I have been trying to use rt_task_suspend()
> and rt_task_resume().

Try to avoid using skin functions other than those of RTDM inside drivers. 
Your problem can be solved with a semaphore with an initial value of 0. A  
rtdm_sem_down will make your task sleep. Inside the interrupt handler a 
rtdm_sem_up will wake up your task (after the interrupt handler has exited).

Sebastian

Re: [Xenomai-help] Getting calling task id inside RTDM driver

[Philippe Gerum]

Sean McGranaghan wrote:
> Hello all,
> 
> I am writing an RTDM driver that needs a simple task suspend/resume. I 
> have a simple ioctl() that needs to initiate some io and then sleep 
> until an interrupt occurs. I have been trying to use rt_task_suspend() 
> and rt_task_resume(). I tried to save the calling task id using 
> rt_task_self() inside open(). When I try to suspend the task in the 
> ioclt() rt_task_suspend() returns an EINVAL. (I looked at the code and 
> it appears to fail a magic number test.)
> 

Object descriptors must be exclusively used in the execution space (i.e. 
kernel or user) they have been obtained from. Those descriptors are only 
containers of some data pointing at the indexed object, therefore they 
can be mapped at distinct addresses whilst still representing the same 
object -- and they actually do when they belong to different execution 
spaces.

> I then compared the calling task id before the open() to the task id 
> inside open() and they are different. Is there a way to retrieve the 
> calling task id without explicitly sending it to the ioctl()?

suspend/resume are going to be racy for synchronization purpose. It 
would be better to use RTDM services (e.g. sema4s), which would fix the 
current issue in the same move.

> 
> Sean
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help


-- 

Philippe.

Re: [Xenomai-help] Getting calling task id inside RTDM driver

[Sean McGranaghan]

[-- Attachment #1: Type: text/html, Size: 1856 bytes --]

Re: [Xenomai-help] Getting calling task id inside RTDM driver

[Jan Kiszka]

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

Sean McGranaghan wrote:
> After posting I performed a two tests, first using an RTDM event and then using 
> a semaphore as described below. The synchronization worked in both cases, but I 
> think I have another problem. On exit my test application generates a 
> segmentation fault, but only occasionally. I do not get a stack dump in the 
> kernel log and the system does not seem to become unstable. I tried running my 
> test application under strace and gdb. In both cases I could not reproduce the 
> error. I am installing the latest version of Xenomai and adding debugging 
> options to the build. I will post when I know more.

mlockall? That's a typical thing to forget in your application (also
happens to me from time to time...), and it may or may not hit you with
a segfault one day.

> 
> Any suggestions on which Xenomai and kernel options to set for debugging?

The SVN contains some nice new debugging features for RTDM: catch
illegal contexts of rtdm_xxx-services and detect forgotten spinlocks
(via IRQs-on check) on return to the user. The latter already helped to
discover a bug in the xeno_16550A driver.

Moreover, if you are working on x86, the recent work on the kgdb
integration may be interesting as well. See related threads on the list.

Jan


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