From: Philippe Gerum <rpm@xenomai.org>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] CONFIG_XENO_OPT_SELECT
Date: Mon, 31 Jan 2011 16:07:03 +0100 [thread overview]
Message-ID: <1296486423.2214.58.camel@domain.hid> (raw)
In-Reply-To: <4D46CB77.5000004@domain.hid>
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.
next prev parent reply other threads:[~2011-01-31 15:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-31 9:46 [Xenomai-help] CONFIG_XENO_OPT_SELECT roderik.wildenburg
2011-01-31 10:07 ` Philippe Gerum
2011-01-31 14:47 ` Gilles Chanteperdrix
2011-01-31 15:07 ` Philippe Gerum [this message]
2011-01-31 15:11 ` Gilles Chanteperdrix
2011-01-31 15:17 ` Philippe Gerum
2011-02-01 9:44 ` roderik.wildenburg
2011-02-01 9:59 ` Philippe Gerum
2011-02-01 9:23 ` roderik.wildenburg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1296486423.2214.58.camel@domain.hid \
--to=rpm@xenomai.org \
--cc=gilles.chanteperdrix@xenomai.org \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.