All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe Gerum <rpm@xenomai.org>
To: "mau.salvi@domain.hid" <mau.salvi@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] Interrupt handling vs. scheduler
Date: Sun, 12 Dec 2010 23:04:10 +0100	[thread overview]
Message-ID: <1292191450.1837.22.camel@domain.hid> (raw)
In-Reply-To: <8659178.81831292179675169.JavaMail.defaultUser@domain.hid>

On Sun, 2010-12-12 at 19:47 +0100, mau.salvi@domain.hid wrote:
> Hello to all,
> 
> I observed a strange behaviour on oscilloscope during 
> interrupt handling when RT periodic tasks reschedule happens.
> 
> I have 
> an interrupt generated every 1ms by a PCI card: the interrupt was 
> handled into user-space with a RT task (priority 99) that sleeps on 
> rt_intr_wait(), and the handler was created with I_NOAUTOENA flag, so 
> there is a rt_intr_enable() call each cycle immediately before 
> rt_intr_wait(). Into my code there is another task that works 
> periodically on this PCI card data.
> 
> Due to a "slip" between PC and PCI 
> card hardware timers, sometimes there is an overlap between interrupt 
> handling and periodic task wakeup: in detail, during interrupt 
> handling, the periodic time for latter task expires, so wakeup must 
> take place. In this (and only in this) condition I observe a wrong call 
> to interrupt handling task immediately after the end of right handling: 
> so, I have two consecutive interrupt calls, as the expire timer signal 
> was delivered also to my interrupt handler. Task wakeup takes 
> regularily place.
> 
> This behaviour happens only if there is some other 
> periodic task into my executable: without that, interrupts was properly 
> handled every 1ms. "Strange" behaviour also happens if periodic task 
> does nothing (waits rescheduling only).

What is the return value of rt_intr_wait() in both the valid and
spurious cases?

> 
> I'm working on Ubuntu 10.04 
> x86 with Xenomai 2.5.5.2 on a vanilla kernel 2.6.35.7, Adeos patch 2.7-
> 04.
> Hardware:  Intel Celeron M 512 MHz processor, motherboard with SMI 
> services disabled by Xenomai at startup.
> 
> I've seen that a new Adeos 
> patch (2.8) was released for x86 arch, with more modifies into IRQ 
> code: does new patch fixes this problem?

We don't know which problem this could be the symptom of, yet.

> 
> Thanks in advance, bye
> 
> 
> 
> Supera i limiti: raddoppia la velocità da 10 a 20 Mega!   Risparmia con Tutto Incluso: telefono + adsl 20 mega a soli 29,95 € al mese per due anni!  SCONTO DI 240 EURO!  http://abbonati.tiscali.it/telefono-adsl/prodotti/tc/tuttoincluso/?WT.mc_id=01fw 
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help

-- 
Philippe.




  reply	other threads:[~2010-12-12 22:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-12 18:47 [Xenomai-help] Interrupt handling vs. scheduler mau.salvi
2010-12-12 22:04 ` Philippe Gerum [this message]
     [not found]   ` <AANLkTikHyianvhgO7bbe9RGkgCJsNjPXsFt1J_pvtWOc@domain.hid>
2010-12-14 20:26     ` Philippe Gerum
  -- strict thread matches above, loose matches on Subject: below --
2010-12-12 18:45 mau.salvi

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=1292191450.1837.22.camel@domain.hid \
    --to=rpm@xenomai.org \
    --cc=mau.salvi@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.