[Xenomai] RTDM !xnpod_unblockable_p() question

[Xenomai] RTDM !xnpod_unblockable_p() question

[Michael Smith]

Hi
I have been struggling with this problem for days on end, but there is just
not enough information in the code
or documentation for me to solve it.
I am calling rtdm_mutex_lock() inside a device driver module. It is called
by my PCI probe function as
the driver is initializing.
I keep on getting the error message:
Xenomai: assertion failed at kernel/xenomai/skins/rtdm/drvlib.c:1534
(!xnpod_unblockable_p())
And the resultant -EPERM error message from the return of the function.

I know these checks were inserted to stop any call from an incorrect
context. But as far as the documentation states
it can be called from a kernel module.
Also as the mail form March 2006 states
http://www.xenomai.org/pipermail/xenomai/2006-March/003116.html

!xnpod_unblockable_p():
- allows blockable RT-context (kernel and user threads)
- rejects user threads in secondary mode
- rejects Linux threads

Is there something I'm missing with regards to the calling context?
Are there any other situations this could also produce this return?
Because as far as I can see it should fine being called in a kernel module.

Thanks
Michael Smith

Re: [Xenomai] RTDM !xnpod_unblockable_p() question

[Philippe Gerum]

On 08/13/2014 02:28 PM, Michael Smith wrote:
> Hi
> I have been struggling with this problem for days on end, but there is just
> not enough information in the code
> or documentation for me to solve it.
> I am calling rtdm_mutex_lock() inside a device driver module. It is called
> by my PCI probe function as
> the driver is initializing.
> I keep on getting the error message:
> Xenomai: assertion failed at kernel/xenomai/skins/rtdm/drvlib.c:1534
> (!xnpod_unblockable_p())
> And the resultant -EPERM error message from the return of the function.
> 
> I know these checks were inserted to stop any call from an incorrect
> context. But as far as the documentation states
> it can be called from a kernel module.

The doc (2.6) reads:

 * This service can be called from:
 *
 * - Kernel-based task
 * - User-space task (RT)

The generic "kernel module" context is not mentioned. You get -EPERM
because you cannot call this from a probe() routine, which runs in
secondary/pure linux mode. Acquiring a RTDM mutex requires the caller to
run in real-time mode.

> Also as the mail form March 2006 states
> http://www.xenomai.org/pipermail/xenomai/2006-March/003116.html
> 
> !xnpod_unblockable_p():
> - allows blockable RT-context (kernel and user threads)
> - rejects user threads in secondary mode
> - rejects Linux threads
> 
> Is there something I'm missing with regards to the calling context?
> Are there any other situations this could also produce this return?
> Because as far as I can see it should fine being called in a kernel module.
> 
> Thanks
> Michael Smith
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai
> 


-- 
Philippe.

Re: [Xenomai] RTDM !xnpod_unblockable_p() question

[Philippe Gerum]

On 08/13/2014 02:52 PM, Philippe Gerum wrote:
> On 08/13/2014 02:28 PM, Michael Smith wrote:
>> Hi
>> I have been struggling with this problem for days on end, but there is just
>> not enough information in the code
>> or documentation for me to solve it.
>> I am calling rtdm_mutex_lock() inside a device driver module. It is called
>> by my PCI probe function as
>> the driver is initializing.
>> I keep on getting the error message:
>> Xenomai: assertion failed at kernel/xenomai/skins/rtdm/drvlib.c:1534
>> (!xnpod_unblockable_p())
>> And the resultant -EPERM error message from the return of the function.
>>
>> I know these checks were inserted to stop any call from an incorrect
>> context. But as far as the documentation states
>> it can be called from a kernel module.
> 
> The doc (2.6) reads:
> 
>  * This service can be called from:
>  *
>  * - Kernel-based task
>  * - User-space task (RT)
> 
> The generic "kernel module" context is not mentioned. You get -EPERM
> because you cannot call this from a probe() routine, which runs in
> secondary/pure linux mode. Acquiring a RTDM mutex requires the caller to
> run in real-time mode.
> 

By "kernel based task", the doc always implicitly means kernel-based
_Xenomai_ task, e.g. RTDM driver task. Such one always runs in primary mode.

-- 
Philippe.

Re: [Xenomai] RTDM !xnpod_unblockable_p() question

[Gilles Chanteperdrix]

On 08/13/2014 02:28 PM, Michael Smith wrote:
> but there is just not enough information in the code
> or documentation for me to solve it.

Actually, the information can very well be found in the source code.

#define xnpod_unblockable_p() \
    (xnpod_asynch_p() || xnthread_test_state(xnpod_current_thread(), XNROOT))

If you had digged a bit, you would have found that the failing test was
!xnthread_test_state(xnpod_current_thread(), XNROOT)

Which clearly means that you were calling rtdm_mutex_lock() from the 
context of the root thread and that the root thread is unblockable.

Now, if you do not understand what the root thread is, or why it can 
not be suspended from Xenomai's scheduler point of view, clearly, there 
are a thing or two you have not taken the time to understand about 
Xenomai. So, please do not reverse the roles: you are the one who has 
not read enough documentation, please do not accuse us of not having 
written enough.

-- 
                                                                Gilles.

[Xenomai] Fwd: RTDM !xnpod_unblockable_p() question

[Michael Smith]

On Wed, Aug 13, 2014 at 10:04 PM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> On 08/13/2014 02:28 PM, Michael Smith wrote:
> > but there is just not enough information in the code
> > or documentation for me to solve it.
>
> Actually, the information can very well be found in the source code.
>
> #define xnpod_unblockable_p() \
>     (xnpod_asynch_p() || xnthread_test_state(xnpod_current_thread(),
> XNROOT))
>
> If you had digged a bit, you would have found that the failing test was
> !xnthread_test_state(xnpod_current_thread(), XNROOT)
>
> Which clearly means that you were calling rtdm_mutex_lock() from the
> context of the root thread and that the root thread is unblockable.
>
> Now, if you do not understand what the root thread is, or why it can
> not be suspended from Xenomai's scheduler point of view, clearly, there
> are a thing or two you have not taken the time to understand about
> Xenomai. So, please do not reverse the roles: you are the one who has
> not read enough documentation, please do not accuse us of not having
> written enough.
>
> --
>                                                                 Gilles.
>

Hi Gilles
You have misunderstood the meaning of my email.
It was in no way a stab at the documentation of Xenomai, or the work that
anybody has done.
I have gone down to that level of the code up the the XNROOT definition,
believe me I have spent hours
scouring the existing documentation as well as the code, as well as mailing
lists.
So I have not come into this with no understanding.
All I asked was for an explanation of a portion I did not understand.
And as Philipe explained "By "kernel based task", the doc always implicitly
means kernel-based
_Xenomai_ task" I did not know about that assumption, maybe it is something
that
is obvious if you have coded the Xenomai source code for years, for me it
was not.

Regards
Michael.

Re: [Xenomai] Fwd: RTDM !xnpod_unblockable_p() question

[Philippe Gerum]

On 08/14/2014 09:02 AM, Michael Smith wrote:
> On Wed, Aug 13, 2014 at 10:04 PM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
> 
>> On 08/13/2014 02:28 PM, Michael Smith wrote:
>>> but there is just not enough information in the code
>>> or documentation for me to solve it.
>>
>> Actually, the information can very well be found in the source code.
>>
>> #define xnpod_unblockable_p() \
>>     (xnpod_asynch_p() || xnthread_test_state(xnpod_current_thread(),
>> XNROOT))
>>
>> If you had digged a bit, you would have found that the failing test was
>> !xnthread_test_state(xnpod_current_thread(), XNROOT)
>>
>> Which clearly means that you were calling rtdm_mutex_lock() from the
>> context of the root thread and that the root thread is unblockable.
>>
>> Now, if you do not understand what the root thread is, or why it can
>> not be suspended from Xenomai's scheduler point of view, clearly, there
>> are a thing or two you have not taken the time to understand about
>> Xenomai. So, please do not reverse the roles: you are the one who has
>> not read enough documentation, please do not accuse us of not having
>> written enough.
>>
>> --
>>                                                                 Gilles.
>>
> 
> Hi Gilles
> You have misunderstood the meaning of my email.
> It was in no way a stab at the documentation of Xenomai, or the work that
> anybody has done.
> I have gone down to that level of the code up the the XNROOT definition,
> believe me I have spent hours
> scouring the existing documentation as well as the code, as well as mailing
> lists.
> So I have not come into this with no understanding.
> All I asked was for an explanation of a portion I did not understand.
> And as Philipe explained "By "kernel based task", the doc always implicitly
> means kernel-based
> _Xenomai_ task" I did not know about that assumption, maybe it is something
> that
> is obvious if you have coded the Xenomai source code for years, for me it
> was not.
> 

The Xenomai 2 doc is misleading to newcomers discovering the charms of
dual kernel systems. As a matter of fact we used to assume that dual
kernel mode was the main context, regular linux mode being the ancillary
one for installation and other housekeeping chores.

Xenomai 3 introduced context tags in the documentation which should fix
this, partly because for most APIs the dual-kernel vs native kernel
distinction does not stand anymore.

-- 
Philippe.