Philippe Gerum wrote:
> A common issue causing lockups is having the CPU being stormed by a
> level triggered interrupt which does not get masked and processed
> properly. IRQ threading may add a certain amount of confusion to this,
> since  it may have an impact on the order your IRQ threads must be
> scheduled to avoid this situation. Think of the situation with a GPIO
> demultiplexing IRQ for instance, where you want all multiplexed IRQ
> threads to run before the demultiplexer ISR runs and unmasks the
> interrupt source.
> Even without the threading issue, the interrupt storm issue is quite
> frequent during the initial stage of porting the I-pipe; it usually
> happens because the assumption that the IRQ handler would be called
> shortly after the interrupt is taken becomes wrong with the I-pipe. As a
> matter of fact, pipelining interrupts means that they may be delayed for
> some time, before the Linux device driver is called and actually removes
> the interrupt condition at hw level (think of a real-time activity
> preempting the CPU, while some device hammers the CPU with interrupts
> because Linux does not seem to care fast enough). This is why most - if
> not all interrupts - should be masked+acked at receipt (see ipipe_ack)
> then unmasked after handler completion, when the I-pipe is enabled.

Oh yes I already had such interrupt storms, I now use the "level" interrupt 
handler as blackfin
does. Because the IRQ ack process is very IRQ source specific, the IRQ ismasked 
as long as it is
not allowed to be served and unmasked after the real ISR has run (the ISRhas to 
do the ack).

>> I think the problem is that the IRQ threads do not get scheduled and so 
>> cannot handle the
>> Interrupts, although they have been "kicked" by __ipipe_run_isr.
> Are you sure you need to thread the Linux ISRs on your target
> architecture? This is a Blackfin-specific implementation of the I-pipe,
> which addresses some arch-dependent peculiarities on this CPU. I suspect
> you may not need this at all, which would greatly simplify the issue.

Thanks for this hint, actually after removing the IRQ threads the interrupts of 
the Linux domain get
served whenever the higher-priority Test domain suspends itself.

But even though the Test domain suspends itself the Linux domain never runs. Do 
I need
to check for TIF_NEED_RESCHED (like after a syscall) after executing an ISR via 

Or as a more general question: Where should the switch from one domain to 
another domain be done 
when one domain suspends itself?

> Which arch are we talking about?

Unfortunately Theobroma Systems is not yet allowed to disclose (under NDA) the 
architecture but this 
will soon be the case and the whole Code will be publicly available under the 
GPL license.

Best regards,



Peter Schüller
Theobroma Systems Design und Consulting GmbH
Gutheil-Schoder-Gasse 17, A-1230 Vienna, Austria
Phone: +43 (1) 2369893-403, Fax: +43 (1) 2369893-9-403

Xenomai-core mailing list

Reply via email to