All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: Tomas Kalibera <kalibera@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] runaway secondary tasks lock up
Date: Fri, 16 May 2008 20:27:03 +0200	[thread overview]
Message-ID: <18477.53751.771867.378280@domain.hid> (raw)
In-Reply-To: <482DCA2F.9010609@domain.hid>

Tomas Kalibera wrote:
 > 
 > Gilles Chanteperdrix wrote:
 > > Tomas Kalibera wrote:
 > >  > 
 > >  > Hi,
 > >  > 
 > >  > I've noticed an interesting difference regarding primary and secondary 
 > >  > domain runaway tasks. The primary domain ones are detected by Xenomai 
 > >  > watchdog and terminated. The secondary domain ones are not terminated, 
 > >  > but cause a system lockup, because a secondary domain task is always run 
 > >  > in preference of other tasks  (kernel complains by  BUG: soft lockup - 
 > >  > CPU#0 stuck for 11s!). Would there be a way to also detect the secondary 
 > >  > domain runaway threads ? Since the kernel itself can do it, it should be 
 > >  > possible, right ?
 > >
 > > Yes, but if the Linux kernel does it, why would Xenomai reinvent the wheel ?
 > >   
 > Because the wheels behave differently. Xenomai watchdog kills the app 
 > after 4 seconds, kernel just writes a message. This is not nice for 
 > debugging large Xenomai applications. You add a debug printf somewhere 
 > and it makes the system freeze because it switches to secondary domain.  
 > And when the application just does not have full control over when it 
 > runs in primary or secondary domain (i.e. a JVM), this is  somewhat 
 > painful.

I would say the best thing to do then, is to patch the Linux soft-lockup
detector. It will probably be much easier than re-implemeting the whole
thing in Xenomai. And it may even be useful to other people not using
Xenomai.

 > >  > 
 > >  > Now, I've discovered that if I assign the secondary domain task priority 
 > >  > 0, it would not lock up the system. 1 would, 99 would as well. What is 
 > >  > the semantics ? Any secondary domain task with priority above zero runs 
 > >  > in preference of any (non-Xenomai) Linux thread ?
 > >
 > > This is not related to Xenomai, that is the semantic of SCHED_FIFO, also
 > > called fixed priority scheduling.
 > >   
 > Thank you for explaining this. It would be nice if the Xenomai API 
 > documentation could say that the priorities are directly mapped to Linux 
 > priorities and that SCHED_FIFO is used.

I think it is explained in the articles "Life with Adeos" and "Native API
tour".

-- 


					    Gilles.


      reply	other threads:[~2008-05-16 18:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-16 16:47 [Xenomai-help] runaway secondary tasks lock up Tomas Kalibera
2008-05-16 17:26 ` Gilles Chanteperdrix
2008-05-16 17:53   ` Tomas Kalibera
2008-05-16 18:27     ` Gilles Chanteperdrix [this message]

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=18477.53751.771867.378280@domain.hid \
    --to=gilles.chanteperdrix@xenomai.org \
    --cc=kalibera@domain.hid \
    --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.