All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe Gerum <rpm@xenomai.org>
To: ROSSIER Daniel <Daniel.Rossier@domain.hid>
Cc: xenomai@xenomai.org, jan.kiszka@domain.hid
Subject: RE: [Xenomai-help] Strange behaviour w/mutex&semaphore
Date: Thu, 20 Jul 2006 14:04:26 +0200	[thread overview]
Message-ID: <1153397066.5078.10.camel@domain.hid> (raw)
In-Reply-To: <FDBBB5CC70676540B3EF7CFE83FD94E0210E16@domain.hid>

On Thu, 2006-07-20 at 13:17 +0200, ROSSIER Daniel wrote:
> 
> > -----Message d'origine-----
> > De : jan.kiszka@domain.hid [mailto:jan.kiszka@domain.hid]
> > Envoyé : jeudi, 20. juillet 2006 13:03
> > À : ROSSIER Daniel
> > Cc : xenomai@xenomai.org
> > Objet : Re: [Xenomai-help] Strange behaviour w/mutex&semaphore
> > 
> > ROSSIER Daniel wrote:
> > > Hi all,
> > >
> > > I've a strange behaviour with the attached piece of code.
> > > It's really simple: there are 3 tasks and we're spinning within the task
> > in order
> > > to simulate task load.
> > >
> > > It's a pure academic exercice, so don't try to think about the
> > usefulness of this code ;-)
> > >
> > >
> > > Actually, after insmod'ing the code into the kernel, the system freezes
> > and
> > > the "meteoDataAcquisition" task is suspended runaway by the internal
> > xenomai watchdog.
> > >
> > > Why?
> > >
> > > Anything wrong in this code?
> > 
> > Check the values you assign to rt_task_set_periodic. Kind of... fast?
> 
> No, with at these frequencies, there is no problem (the jiffy is at 1ms). Actually, putting TM_NOW in the rt_task_set_periodic() instead of 18 as it is, we noticed that it works.
> Removing the mutex & semaphore stuff, with the delay in set_periodic(), does not change the behaviour.
> We came up with this issue after another one, actually, with a more sophisticated code showing a priority inversion. We reduce the code, and then find this issue. I do not know it both issues are related, but I'd like
> to solve this one first.
> 

-  rt_task_set_periodic(&meteoDataAcquisitionTask, 18, 1000);
+  rt_task_set_periodic(&meteoDataAcquisitionTask, rt_timer_read() + 18,
1000);

The current call should return with -ETIMEDOUT, in which case, the
associated acquisition thread would enter a runaway loop, with
rt_task_wait_period() systematically bailing out upon the same error,
which in turn makes the task sucking all the available CPU. Then came
the relentless watchdog...

> > 
> > >
> > > Thanks for any advice.
> > >
> > > Daniel
> > >
> > >
> > >
> > > ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > Xenomai-help mailing list
> > > Xenomai-help@domain.hid
> > > https://mail.gna.org/listinfo/xenomai-help
> > 
> 
> 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.




  parent reply	other threads:[~2006-07-20 12:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-20 10:54 [Xenomai-help] Strange behaviour w/mutex&semaphore ROSSIER Daniel
2006-07-20 11:03 ` Jan Kiszka
2006-07-20 11:17   ` ROSSIER Daniel
2006-07-20 11:49     ` Gilles Chanteperdrix
2006-07-20 11:59       ` ROSSIER Daniel
2006-07-20 12:04     ` Philippe Gerum [this message]
2006-07-20 12:44       ` ROSSIER Daniel

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=1153397066.5078.10.camel@domain.hid \
    --to=rpm@xenomai.org \
    --cc=Daniel.Rossier@domain.hid \
    --cc=jan.kiszka@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.