All of lore.kernel.org
 help / color / mirror / Atom feed
* [Xenomai-core] Interrupt priorities
@ 2006-03-20 19:47 Rodrigo Rosenfeld Rosas
  2006-03-22 23:04 ` Philippe Gerum
  0 siblings, 1 reply; 4+ messages in thread
From: Rodrigo Rosenfeld Rosas @ 2006-03-20 19:47 UTC (permalink / raw)
  To: xenomai-core

Hi Philippe.

I was wondering if there are any plans to provide an option to Xenomai to 
allow the use of interrupt priorities. I mean, by having the timer source as 
the most prioritary interrupt so that the scheduler could preempt the 
interrupt.

Let me explain why such option would be good. When I was testing my 
framegrabber driver, I had to reboot my PC about 10 times until I could 
identificate what was causing total freeze of the system. The problem was on 
the interrupt handler. One of the problems was that I was not clearing the 
interrupt events correctly so that the handler was in loop. The other problem 
was a crash inside the interrupt due to something like:

uint64_t timestamp=rtdm_clock_read();
b.timestamp = *((struct timeval *) timestamp);

Where it should be
b.timestamp = *((struct timeval *) &timestamp);

I forgot the '&' char.

If it was possible to preempt the interrupt, by a task of greater priority, I 
could write a watchdog that would disable the interrupt in case the system 
stops responding.

Do you think it would worth providing such option to Xenomai, at least as a 
debug feature?

Best Regards,

Rodrigo.

P.S: BTW, I think my driver is usable now, so that you (or someone else) could 
cite it in some article or documentation. When I finish my master thesis (my 
deadline is the end of June ), I think I'll have time to comment it better 
and to remove the Data Translation specific code so that it can me made 
available as a template for real-time video interfaces. Or maybe you could 
convince Data Translation to allow me to show all the code! ;)

		
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com



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

* Re: [Xenomai-core] Interrupt priorities
  2006-03-20 19:47 [Xenomai-core] Interrupt priorities Rodrigo Rosenfeld Rosas
@ 2006-03-22 23:04 ` Philippe Gerum
  2006-03-23  2:35   ` Rodrigo Rosenfeld Rosas
  0 siblings, 1 reply; 4+ messages in thread
From: Philippe Gerum @ 2006-03-22 23:04 UTC (permalink / raw)
  To: Rodrigo Rosenfeld Rosas; +Cc: xenomai-core

Rodrigo Rosenfeld Rosas wrote:
> Hi Philippe.
> 
> I was wondering if there are any plans to provide an option to Xenomai to 
> allow the use of interrupt priorities. I mean, by having the timer source as 
> the most prioritary interrupt so that the scheduler could preempt the 
> interrupt.
> 
> Let me explain why such option would be good. When I was testing my 
> framegrabber driver, I had to reboot my PC about 10 times until I could 
> identificate what was causing total freeze of the system. The problem was on 
> the interrupt handler. One of the problems was that I was not clearing the 
> interrupt events correctly so that the handler was in loop. The other problem 
> was a crash inside the interrupt due to something like:
> 
> uint64_t timestamp=rtdm_clock_read();
> b.timestamp = *((struct timeval *) timestamp);
> 
> Where it should be
> b.timestamp = *((struct timeval *) &timestamp);
> 
> I forgot the '&' char.
> 
> If it was possible to preempt the interrupt, by a task of greater priority, I 
> could write a watchdog that would disable the interrupt in case the system 
> stops responding.
> 
> Do you think it would worth providing such option to Xenomai, at least as a 
> debug feature?
> 

Actually, this is an Adeos issue. Adeos should be taught to preserve hw 
interrupt priorities, or at least be given some sort of fairness, when 
syncing the interrupt log. Currently, high-numbered IRQs are processed 
before low-numbered ones, so if the former pile up indefinitely, this 
could prevent the delivery of the latter.

A way to pull the brake when some interrupt channel goes wild is to 
activate Xenomai's NMI watchdog, which is never pipelined on any Adeos 
implementation. This requires an APIC to be available on your x86 CPU 
though. Additionally, interrupt serialization could be prevented just by 
re-enabling hw interrupts in Xenomai's ISR, since the nucleus supports 
reentrancy, but I don't think that's the issue you experienced. Timer 
IRQs did show up, but likely remained stuck in the log due to the 
misbehaving IRQ channel with higher software priority.

> Best Regards,
> 
> Rodrigo.
> 
> P.S: BTW, I think my driver is usable now, so that you (or someone else) could 
> cite it in some article or documentation. When I finish my master thesis (my 
> deadline is the end of June ), I think I'll have time to comment it better 
> and to remove the Data Translation specific code so that it can me made 
> available as a template for real-time video interfaces. Or maybe you could 
> convince Data Translation to allow me to show all the code! ;)
> 

Having a reusable template would already be nice, and likely appreciated 
by the RTDM people too, since that's precious on hand information.

> 		
> _______________________________________________________
> Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
> http://br.acesso.yahoo.com
> 
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
> 


-- 

Philippe.


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

* Re: [Xenomai-core] Interrupt priorities
  2006-03-22 23:04 ` Philippe Gerum
@ 2006-03-23  2:35   ` Rodrigo Rosenfeld Rosas
  2006-03-23 14:20     ` Philippe Gerum
  0 siblings, 1 reply; 4+ messages in thread
From: Rodrigo Rosenfeld Rosas @ 2006-03-23  2:35 UTC (permalink / raw)
  To: Philippe Gerum; +Cc: Xenomai-core

--- Philippe Gerum <rpm@xenomai.org> escreveu:
> ... 
> A way to pull the brake when some interrupt channel goes wild is to 
> activate Xenomai's NMI watchdog, which is never pipelined on any Adeos 
> implementation.

Where can I find more information about this feature?

> This requires an APIC to be available on your x86 CPU 
> though.

I need to verify that on college. My PC is a P4 1.7Ghz, Intel motherboard I guess.

> ... 
> Having a reusable template would already be nice, and likely appreciated 
> by the RTDM people too, since that's precious on hand information.

Ok, I'll probably do that after finishing my master thesis, probably after June. Or if I got
permission from Data Translation until there I could send the code as it is... :) But as I'm not
counting on this, we'll have to wait until I have time to reorganize the code and remove the
specific Data Translation code...

Thanks for the explanations,

Rodrigo.


__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger 
http://br.beta.messenger.yahoo.com/ 


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

* Re: [Xenomai-core] Interrupt priorities
  2006-03-23  2:35   ` Rodrigo Rosenfeld Rosas
@ 2006-03-23 14:20     ` Philippe Gerum
  0 siblings, 0 replies; 4+ messages in thread
From: Philippe Gerum @ 2006-03-23 14:20 UTC (permalink / raw)
  To: Rodrigo Rosenfeld Rosas; +Cc: Xenomai-core

Rodrigo Rosenfeld Rosas wrote:
> --- Philippe Gerum <rpm@xenomai.org> escreveu:
> 
>>... 
>>A way to pull the brake when some interrupt channel goes wild is to 
>>activate Xenomai's NMI watchdog, which is never pipelined on any Adeos 
>>implementation.
> 
> 
> Where can I find more information about this feature?
> 

Machine menu from the Xenomai configuration panel, NMI watchdog feature.

> 
>>This requires an APIC to be available on your x86 CPU 
>>though.
> 
> 
> I need to verify that on college. My PC is a P4 1.7Ghz, Intel motherboard I guess.
> 

Should be ok.

> 
>>... 
>>Having a reusable template would already be nice, and likely appreciated 
>>by the RTDM people too, since that's precious on hand information.
> 
> 
> Ok, I'll probably do that after finishing my master thesis, probably after June. Or if I got
> permission from Data Translation until there I could send the code as it is... :) But as I'm not
> counting on this, we'll have to wait until I have time to reorganize the code and remove the
> specific Data Translation code...
> 
> Thanks for the explanations,
> 
> Rodrigo.
> 
> 
> __________________________________________________
> Faça ligações para outros computadores com o novo Yahoo! Messenger 
> http://br.beta.messenger.yahoo.com/ 
> 


-- 

Philippe.


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

end of thread, other threads:[~2006-03-23 14:20 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-03-20 19:47 [Xenomai-core] Interrupt priorities Rodrigo Rosenfeld Rosas
2006-03-22 23:04 ` Philippe Gerum
2006-03-23  2:35   ` Rodrigo Rosenfeld Rosas
2006-03-23 14:20     ` Philippe Gerum

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.