All of lore.kernel.org
 help / color / mirror / Atom feed
* [Xenomai-help] Interrupt handling vs. scheduler
@ 2010-12-12 18:45 mau.salvi
  0 siblings, 0 replies; 4+ messages in thread
From: mau.salvi @ 2010-12-12 18:45 UTC (permalink / raw)
  To: xenomai

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).

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?

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Xenomai-help] Interrupt handling vs. scheduler
@ 2010-12-12 18:47 mau.salvi
  2010-12-12 22:04 ` Philippe Gerum
  0 siblings, 1 reply; 4+ messages in thread
From: mau.salvi @ 2010-12-12 18:47 UTC (permalink / raw)
  To: xenomai

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).

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?

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Xenomai-help] Interrupt handling vs. scheduler
  2010-12-12 18:47 [Xenomai-help] Interrupt handling vs. scheduler mau.salvi
@ 2010-12-12 22:04 ` Philippe Gerum
       [not found]   ` <AANLkTikHyianvhgO7bbe9RGkgCJsNjPXsFt1J_pvtWOc@domain.hid>
  0 siblings, 1 reply; 4+ messages in thread
From: Philippe Gerum @ 2010-12-12 22:04 UTC (permalink / raw)
  To: mau.salvi@domain.hid; +Cc: xenomai

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.




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Xenomai-help] Interrupt handling vs. scheduler
       [not found]   ` <AANLkTikHyianvhgO7bbe9RGkgCJsNjPXsFt1J_pvtWOc@domain.hid>
@ 2010-12-14 20:26     ` Philippe Gerum
  0 siblings, 0 replies; 4+ messages in thread
From: Philippe Gerum @ 2010-12-14 20:26 UTC (permalink / raw)
  To: Mauro; +Cc: xenomai

On Tue, 2010-12-14 at 20:37 +0100, Mauro wrote:
> 2010/12/12 Philippe Gerum <rpm@xenomai.org>
>         
>         
>         
>         What is the return value of rt_intr_wait() in both the valid
>         and
>         spurious cases?
>         
>         
>         --
>         Philippe.
>         
>         
> 
> 
> Return value is 1 in both cases.
> 
> 
> I forgot to mention that periodic task was a Xenomai RT task with
> priority less than interrupt task priority.
> 

I see no way for a timer expiration to wake up the wrong thread (each
thread has its own private periodic timer). However I see a scenario
where your low priority thread could trigger a subsequent IRQ early
enough in the time frame to let you think of a spurious return of
rt_intr_wait(), albeit you did receive two different IRQs as
rt_intr_wait() indicates.

Maybe you should try instrumenting rt_intr_handler()
(ksrc/skins/native.syscall.c) to issue a spot on your oscilloscope, so
as to observe whether you actually get the following sequence:

- rt_intr_handler
- IRQ server wakeup and block back in rt_intr_wait
- periodic task wakeup, trigger IRQ via mmio of some sort
- rt_intr_handler
- second IRQ server wakeup

all in a short time frame.

Please keep the list Cced.

> 
> Thank you, bye.
> 
> 
> Mauro

-- 
Philippe.




^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2010-12-14 20:26 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-12 18:47 [Xenomai-help] Interrupt handling vs. scheduler mau.salvi
2010-12-12 22:04 ` Philippe Gerum
     [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

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.