[Xenomai-help] How to resolve this lockup situation?

[Xenomai-help] How to resolve this lockup situation?

[jmf]

Dear all,

this is the situation: from a Xeno task, a shared library function is called
to control some device. After a system update (both Xeno and the device
drivers) that function returns with a timeout. As it turns out, as a part of
the device drivers, there is also a deamon running which the shared lib
tries to talk to. Obviously, while the RT task waits for the function to return,
that deamon does not get any CPU time to answer so the function returns
a timeout.

Now, the questions are: why did it work before the update, before we
noticed the existence of a deamon? Is there any way to make Xenomai give
the Linux scheduler some time so the deamon can do its work? Or can that
deamon process somehow be moved to the Xeno domain? I think I stumbled
upon a respective function meant for testing once but can't find it anymore...

Thanks a lot for any clue!
-jmf

Re: [Xenomai-help] How to resolve this lockup situation?

[Gilles Chanteperdrix]

jmf wrote:
> Dear all,
> 
> this is the situation: from a Xeno task, a shared library function is called
> to control some device. After a system update (both Xeno and the device
> drivers) that function returns with a timeout. As it turns out, as a part of
> the device drivers, there is also a deamon running which the shared lib
> tries to talk to. Obviously, while the RT task waits for the function to return,
> that deamon does not get any CPU time to answer so the function returns
> a timeout.

I do not understand how this is obvious. If the RT task waits, the rest
of the system may run, including the daemon.

If the daemon is not an RT application, and you have an RT task wait for
it, then your system has a serious flaw: it is not real-time. As could
have told you the T_WARNSW bit if you are using the native skin, or the
PTHREAD_WARNSW if you are using the posix skin (for more details, see
http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#Using_the_PTHREAD_WARNSW_bit.
)


> 
> Now, the questions are: why did it work before the update, before we
> noticed the existence of a deamon? Is there any way to make Xenomai give
> the Linux scheduler some time so the deamon can do its work? Or can that
> deamon process somehow be moved to the Xeno domain? I think I stumbled
> upon a respective function meant for testing once but can't find it anymore...
> 
> Thanks a lot for any clue!

Without seeing any code, we have no clue either.

-- 
					    Gilles.

Re: [Xenomai-help] How to resolve this lockup situation?

[jmf]

Maybe to clarify: the SDK of the said device comes with a shared lib
(whose function I'm calling from an RT thread) and that deamon which
is probably doing the communication with the usb device; with the old
setup where things were still working, I just didn't notice it's existence.
These two only come as binaries. So yes, my system has a serious flaw,
it's not RT. Before, the deamon obviously answered to the shared lib
function in a timely manner. Until we can redesign that system from
ground up and get rid of the non-RT compatible component, I'm just
concerned with getting the old status back. I don't understand what's
different, but is there any way to get Linux some processing time back?