[Rtai] running an infinite loop RTAI task

[mantegazza at aero.polimi.it]

>
>
> On Fri, 26 Sep 2008, Paolo Mantegazza wrote:
>>
>> If you are talking of free RTLinux then you are on 2.2 or a very old
>> 2.4. So CPU isolation is likely done with an own specific support that
>> moves all tasks away from the isolated CPU. Printk work because of the
>> kind of service it uses, who is aware of pending printk requests away
>> from the isolated CPUs, while RTAI relies on a patch that act
>> differently.
>
> No, we are using the commercial version, based on 2.6.19 kernel. The free
> version of RTLinux is just too old to handle the hardware we have.
>
>> If you adopt the RTAI own scheme, found in x86_64 only, it
>> is likely it will print. It is at the end of x86_64 hal.immed, you can
>> copy and use it directly in your application, but you have to care to
>> copy its srq pending routine and change it to pend requests on non
>> isolated cpus. BTW that is what I hint in the README.
>
> I will install the 64-bit system and trying the latest vulcano out of CVS
> there in the hopes it works better than i386.
>

It will make no difference. I was just referring to the rt_printk stuff.
Since having a never ending loop in hard real time completely locks Linux
but isolcpus leaves deamons on each cpu alive I'm wondering if they are
left with something to do that is vital to Linux, even if they do not run
on isolcpus.
Bernard's way should make a difference in such a case.

Paolo.

>> > My latest RTAI results are very encouraging. The things are almost
>> there,
>> > so I have great hopes. Everything works for a while, but sometimes
>> some
>> > things just lock up. If I'd only knew how to debug this...
>> >
>>
>> I'm not using the never ending loop in production nowadays but I know it
>> works with isolcpus. I can do it playing with the infinite loop examples
>> used for testing RTAI watch dog support. I cannot kill a task in
>> infinite loop, so it stays there forever. It can be suspended though,
>> nowadays I simple type a line from python and I free its CPU in a snap,
>> but a killing signal will just resume the infinite loop. If I needed I
>> simply put the while on a ariable in shared memory I can set to exit the
>> loop, so letting the task dye by itself. So it works for me and I see no
>> locking but that might depend on what you are using. Are you sure there
>> are no applications that need the isolated CPU specifically and get
>> stuck being forbidden to access it?
>
> No, there is just one control loop application that gets assigned to the
> isolated CPU, that's it. The programs that get stuck are the regular Linux
> programs, like make or perl or su. My standard test now is to go from root
> to user "controls" with "su - controls" command. Normally. this works, of
> course. But after I start my real-time program, "su - controls" command
> just sits there until I stop my real-time code. After that the command
> completes.
>
>> That said isolcpus seems not the best thing nowadays. When I suggested
>> you to read the related README I likely forgot to tell you I was
>> referring to the latest version found in RTAI CVSes only, sorry. It
>> contains a nice contribution/suggestion of Bernard (Pfund) about using
>> the latest features provided by Linux. I suggest you to try what
>> suggested by Bernard. He seems doing some finest things with it and
>> provides support scripting too.
>
> I have tried Bernard's script and it changes nothing for me, still the
> same problem with some programs just getting stuck and the whole OS
> eventually getting in a locked up state, nonresponsive. I do get an error
> message from the script about cgroup filesystem non-existent, not sure
> what to make of it.
>
> Alex
>
>