[Xenomai-help] CONFIG_XENO_OPT_SELECT

[Xenomai-help] CONFIG_XENO_OPT_SELECT

[roderik.wildenburg]

In the Xenomai 2.4.x series there was a kernel option CONFIG_XENO_OPT_SELECT.
Unfortunately there is no help available for this option and Google  wasn´t very fertile.
Could somebody tell me, what this option is for?
I am asking, as we face some problems with "select" in a Xenomai task (task is stuck in select, was permanently marked as running (R in /proc/xenomai/sched) and lower priority tasks weren´t  scheduled). I am wondering whether this could be related to this option, which isn´t activated in my kernel config.
We are running a 2.4.25 PPC Kernel with Xenomai 2.4.9.

Many thanks in advance
Roderik

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

Re: [Xenomai-help] CONFIG_XENO_OPT_SELECT

[Philippe Gerum]

On Mon, 2011-01-31 at 10:46 +0100, roderik.wildenburg@domain.hid
wrote:
> In the Xenomai 2.4.x series there was a kernel option CONFIG_XENO_OPT_SELECT.
> Unfortunately there is no help available for this option and Google  wasn´t very fertile.
> Could somebody tell me, what this option is for?
> I am asking, as we face some problems with "select" in a Xenomai task (task is stuck in select, was permanently marked as running (R in /proc/xenomai/sched) and lower priority tasks weren´t  scheduled). I am wondering whether this could be related to this option, which isn´t activated in my kernel config.
> We are running a 2.4.25 PPC Kernel with Xenomai 2.4.9.

This option is not related to the issue, it's basically to compile in
the support for select() over RTDM fildes. Your issue is likely related
to a bug in the RPI protocol, we did fix some bugs in this area in
2.5.x.

Try disabling CONFIG_XENO_OPT_PRIOCPL to check whether it helps.

> 
> Many thanks in advance
> Roderik
> 
> --------------------------------------------------------
> manroland AG
> Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
> Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
> Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
> USt-Ident-Nr. DE 250200933
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

-- 
Philippe.

Re: [Xenomai-help] CONFIG_XENO_OPT_SELECT

[Gilles Chanteperdrix]

roderik.wildenburg@domain.hid wrote:
> In the Xenomai 2.4.x series there was a kernel option
> CONFIG_XENO_OPT_SELECT. Unfortunately there is no help available for
> this option and Google  wasn´t very fertile.

CONFIG_XENO_OPT_SELECT is an internal option of Xenomai. The options you
should be looking at are

CONFIG_XENO_OPT_POSIX_SELECT
CONFIG_XENO_OPT_RTDM_SELECT

These ones are documented, and selecting them, simply select
CONFIG_XENO_OPT_SELECT. So, the fact that CONFIG_XENO_OPT_SELECT is off
in your kernel configuration is off simply means that the other two
options are off.

 Could somebody tell me,
> what this option is for? I am asking, as we face some problems with
> "select" in a Xenomai task (task is stuck in select, was permanently
> marked as running (R in /proc/xenomai/sched) and lower priority tasks
> weren´t  scheduled).

This looks strange. Each call to select should result in a call to
Xenomai "select" syscall, if you are using the POSIX skin, which should
return -ENOSYS, then select should call the glibc select. Since
obviously what you want is to call glibc select directly, you can try
calling __real_select instead.

Note that the issue with priorities you observe show that you have a
task with a priority higher than 0 using a glibc syscall, thereby
causing it to switch to secondary mode. The fact that lower priority
threads do not run is the effect of the "priority coupling", but the
real issue here is that a task with real-time priority is using a linux
syscall, which is something you should normally avoid.

-- 
					    Gilles.

Re: [Xenomai-help] CONFIG_XENO_OPT_SELECT

[Philippe Gerum]

On Mon, 2011-01-31 at 15:47 +0100, Gilles Chanteperdrix wrote:
> roderik.wildenburg@domain.hid wrote:
> > In the Xenomai 2.4.x series there was a kernel option
> > CONFIG_XENO_OPT_SELECT. Unfortunately there is no help available for
> > this option and Google  wasn´t very fertile.
> 
> CONFIG_XENO_OPT_SELECT is an internal option of Xenomai. The options you
> should be looking at are
> 
> CONFIG_XENO_OPT_POSIX_SELECT
> CONFIG_XENO_OPT_RTDM_SELECT
> 
> These ones are documented, and selecting them, simply select
> CONFIG_XENO_OPT_SELECT. So, the fact that CONFIG_XENO_OPT_SELECT is off
> in your kernel configuration is off simply means that the other two
> options are off.
> 
>  Could somebody tell me,
> > what this option is for? I am asking, as we face some problems with
> > "select" in a Xenomai task (task is stuck in select, was permanently
> > marked as running (R in /proc/xenomai/sched) and lower priority tasks
> > weren´t  scheduled).
> 
> This looks strange. Each call to select should result in a call to
> Xenomai "select" syscall, if you are using the POSIX skin, which should
> return -ENOSYS, then select should call the glibc select. Since
> obviously what you want is to call glibc select directly, you can try
> calling __real_select instead.
> 
> Note that the issue with priorities you observe show that you have a
> task with a priority higher than 0 using a glibc syscall, thereby
> causing it to switch to secondary mode. The fact that lower priority
> threads do not run is the effect of the "priority coupling", but the
> real issue here is that a task with real-time priority is using a linux
> syscall, which is something you should normally avoid.
> 

The caller should lose its RPI boost as soon as the regular select()
syscall blocks it though - and I assume it does, so we do have a bug in
2.4.9 here (although I'm pretty sure it has been fixed in later
releases). Having a shadow stuck in 'R'unnable mode
in /proc/xenomai/sched is a good sign that something is broken deep
inside.

-- 
Philippe.

Re: [Xenomai-help] CONFIG_XENO_OPT_SELECT

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> The caller should lose its RPI boost as soon as the regular select()
> syscall blocks it though - and I assume it does, so we do have a bug in
> 2.4.9 here (although I'm pretty sure it has been fixed in later
> releases). Having a shadow stuck in 'R'unnable mode
> in /proc/xenomai/sched is a good sign that something is broken deep
> inside.

The issue may be that the syscall caused the switch to primary mode,
then the libc select is looping without syscall for whatever reason?
Also, maybe testing 2.4.10 is worth a shot.

-- 
					    Gilles.

Re: [Xenomai-help] CONFIG_XENO_OPT_SELECT

[Philippe Gerum]

On Mon, 2011-01-31 at 16:11 +0100, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > The caller should lose its RPI boost as soon as the regular select()
> > syscall blocks it though - and I assume it does, so we do have a bug in
> > 2.4.9 here (although I'm pretty sure it has been fixed in later
> > releases). Having a shadow stuck in 'R'unnable mode
> > in /proc/xenomai/sched is a good sign that something is broken deep
> > inside.
> 
> The issue may be that the syscall caused the switch to primary mode,
> then the libc select is looping without syscall for whatever reason?
> Also, maybe testing 2.4.10 is worth a shot.
> 

What bothers me, is that we should not even be able to
read /proc/xenomai/sched from an unrelated shell, in case we had a
runaway primary or even secondary SCHED_FIFO task. (IIRC, Roderik is
running Xenomai over a single core ppc board, mpc52xx/icecube).

-- 
Philippe.

Re: [Xenomai-help] CONFIG_XENO_OPT_SELECT

[roderik.wildenburg]

> What bothers me, is that we should not even be able to
> read /proc/xenomai/sched from an unrelated shell, in case we had a
> runaway primary or even secondary SCHED_FIFO task. (IIRC, Roderik is
> running Xenomai over a single core ppc board, mpc52xx/icecube).
> 

Yes this is amazing. The stuck task seems just to be marked running, but isn´t really consuming CPU. Or could the linux kernel also be stuck at the callers prio and therefore execute other syscalls? (Or the task is simply running very often (every time we look at /proc/xenomai sched), so it just seems to be stuck at R).

Another irregularity we observed after we replaced the select-call  by a poll-call: In this case everything went fine apart from that mode switches  and context switches in /proc/xenomai/stat weren´t incremented any more, even though we are sure that the task is running and yielding CPU.

Roderik

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933

Re: [Xenomai-help] CONFIG_XENO_OPT_SELECT

[Philippe Gerum]

On Tue, 2011-02-01 at 10:44 +0100, roderik.wildenburg@domain.hid
wrote:
> > What bothers me, is that we should not even be able to
> > read /proc/xenomai/sched from an unrelated shell, in case we had a
> > runaway primary or even secondary SCHED_FIFO task. (IIRC, Roderik is
> > running Xenomai over a single core ppc board, mpc52xx/icecube).
> > 
> 
> Yes this is amazing. The stuck task seems just to be marked running, but isn´t really consuming CPU. Or could the linux kernel also be stuck at the callers prio and therefore execute other syscalls? (Or the task is simply running very often (every time we look at /proc/xenomai sched), so it just seems to be stuck at R).
> 

This clearly points the finger at the prio coupling code. Basically, the
root thread is never downgraded to its original priority, despite the
boost should have been lifted (typically because the relaxed thread is
blocked on a linux syscall, or moved back to primary mode -- in your
case, the former case is likely relevant).

> Another irregularity we observed after we replaced the select-call  by a poll-call: In this case everything went fine apart from that mode switches  and context switches in /proc/xenomai/stat weren´t incremented any more, even though we are sure that the task is running and yielding CPU.
> 

I suspect that by calling Xenomai's wrapped select(), your thread moves
to primary mode (this happens regardless of whether OPT_SELECT is
enabled or not). Therefore, that thread migrates back and forth between
the primary and secondary modes, because if OPT_SELECT is switched off,
your request is automatically forwarded to __real_select() after -ENOSYS
is received from the Xenomai nucleus. Because your thread somehow
oscillates between the two runtime modes at high frequency, the prio
coupling bug is more prone to happen.

OTOH, if your thread directly calls __real_select(), it simply remains
in secondary mode, so the prio coupling bug does not bite.

You could try to confirm this by switching off OPT_PRIOCPL.

> Roderik
> 
> --------------------------------------------------------
> manroland AG
> Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
> Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
> Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
> USt-Ident-Nr. DE 250200933

-- 
Philippe.

Re: [Xenomai-help] CONFIG_XENO_OPT_SELECT

[roderik.wildenburg]

> This looks strange. Each call to select should result in a call to
> Xenomai "select" syscall, if you are using the POSIX skin, which should
> return -ENOSYS, then select should call the glibc select. Since
> obviously what you want is to call glibc select directly, you can try
> calling __real_select instead.

Indeed we replaced the "select"-call by a "poll"-call and the problem astonishingly disappeared (or it just shifted).
Perhaps this is a hint what´s going wrong? Perhaps a __real_select would work too. I will try this, as soon as we can reproduce the effect in office (at the moment problem occurs only at customer).
Just to understand things right: Xenomai-select returns ENOSYS as the option  CONFIG_XENO_OPT_RTDM_SELECT isn´t set? (CONFIG_XENO_OPT_POSIX_SELECT isn´t available in 2.4.9, at least in my config-file).  What would happen when CONFIG_XENO_OPT_RTDM_SELECT was set?

> 
> Note that the issue with priorities you observe show that you have a
> task with a priority higher than 0 using a glibc syscall, thereby
> causing it to switch to secondary mode. The fact that lower priority
> threads do not run is the effect of the "priority coupling", but the
> real issue here is that a task with real-time priority is using a linux
> syscall, which is something you should normally avoid.
> 

But isn´t this  the idea with "priority coupling", that the kernel is executed with realtime task priority? What should "priority coupling" be good for, when I have to avoid linux sys-calls? And, as Philippe wrote, the realtime task blocks as soon as the linux sys-call blocks and so the other realtime tasks get CPU again.
Did I misunderstood something?

Roderik

--------------------------------------------------------
manroland AG
Vorsitzender des Aufsichtsrates: Hanno C. Fiedler
Vorstand: Gerd Finkbeiner (Vorsitzender), Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle   
Sitz der Gesellschaft: Offenbach am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592
USt-Ident-Nr. DE 250200933