Re: [Xenomai-core] Interrupt priorities

[Philippe Gerum <rpm@xenomai.org>]

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.