Re: [Xenomai] Linux scheduling is hijacked from xenomai scheduling

[Philippe Gerum <rpm@xenomai.org>]

On 01/27/2015 11:32 AM, Luca Galvagno wrote:
> Hi Philippe,
> we are trying  2.6.4 and 2.5.6 xenomai versions.
> Moreover in the past we did not have the problem with kernel 2.6.23.14,
> Adeos adeos-ipipe-2.6.23-powerpc-DENX-2.0-09.patch , xenomai 2.4.6.1

That's the story of a hacker's life: bugs come and go unexpectedly, and
much time is spent understanding the reason for such frustrating
transitions.

Anyway, do you have OPT_PRIOCPL off in your Xenomai configuration? If
set, you should disable it.

In addition, you should check whether OPT_WATCHDOG is turned on. Your
pipeline patch is way too old to support the lockup recovery feature
available with 2.6.4, but at least you would have some feedback on your
console if a rt task is spinning continuously.

> thanks
> Regards
> 
> Luca Galvagno
> 
> On 27/01/2015 11:23, Philippe Gerum wrote:
>> On 01/27/2015 10:56 AM, Luca Galvagno wrote:
>>> Hi to all,
>>> we are using kernel 2.6.34 with the corresponding ADEOS patch
>> Which Xenomai release?
>>
>>> (2.6.34-powerpc-2.10-03.patch ) and Xenomai on a PowerPC MPC5200b.
>> 4 years old kernel and pipeline patch, don't expect much feedback on
>> this configuration.
>>
>>> We are facing on a strange behavior when mixing Linux SysCalls with
>>> Xenomai tasks . The effect of the above mix is that the "pure" (without
>>> linux syscall) xenomai task continues to run , the remaining "mixed"
>>> task (for example we have one with a posix socket server) and moreover
>>> the linux os itself are not scheduled anymore. Specifically, to test
>>> this behavior, we connected an oscilloscope to a cpu pin , the result is
>>> that the xenomai task is moving the pin up and down (as it was
>>> programmed) but the linux machine is neither accessible via ping or via
>>> SSH.
>>>
>>> Do you have some suggestions, or some tests we can do ?
>> Xenomai starving the regular kernel from CPU cycles until all the
>> pending real-time duties have been carried out is the basic idea behind
>> the dual kernel design, this is nothing strange.
>>
>> Now the question is: why does your real-time code seem to never complete
>> its work loop, and there never leaves some CPU time to linux?
>>
> 
> 


-- 
Philippe.