Re: [Xenomai-core] Frozen timer IRQ - now traced with kgdb :)

[Philippe Gerum <rpm@xenomai.org>]

Jan Kiszka wrote:
> 
> 
> Yep, I dug deeper meanwhile and also came across this.
> 
> I already have a trivial hack running here. The most tricky part for me
> was to learn quilt, but now I start to love it :). Here is a snapshot
> series for 2.6.15.5:
> 
> <kgdb series from CVS>
> prepare-ipipe-x86.patch
> adeos-ipipe-2.6.15-i386-1.2-01.patch
> kgdb-ipipe-x86.patch
>

In order to ease patch maintenance, we should move the relevant portions 
of this infrastructure to the I-pipe patch directly (i.e. I-pipe 
specific kgdb-ipipe-* code).

> I'm currently wondering if it makes sense to register a kgdb domain and
> "officially" capture all involved IRQs and events. So far the serial
> line IRQ is hard-coded (should be retrieved from some internal kgdb
> structure later). Anyway, it seems to work quite well, I'm currently
> stepping through a network IRQ at ipipe-level.
> 

Having a separate domain would allow to break into any runaway code from 
lower priority domains even with disabled interrupts, except the ipipe 
itself. This said, pushing a domain on top of Xenomai would break the 
assumption that hw interrupts are indeed disabled when operating due to 
the 'last domain optimization' feature, and introduce additional 
jittery. The other option would be to install a KGDB 'redirector' in 
__ipipe_handle_irq so that serial or network interrupts to KGDB would 
never be blocked by the stall bit; I would actually prefer this one.

> 
> While playing with this tool a bit, displaying the the ipipe structures,
> and thinking about the original problem again, I wondered what could
> cause a temporary (as I think to found out now) stalled xeno domain
> without locking up the system? Some irq-lock leaks at driver level (i.e.
> inside our own code)?
> 

At first sight, it might be related to the way __ipipe_unstall_iret_root 
operates. Basically, the idea is to make sure that the stall flag of the 
root domain upon return from the pipelining process always reflects the 
state of the hw interrupt flag at the time the processed event was taken 
by the CPU. It seems that your testcase shows that under some 
cicumstances, the root stage might be spuriously left in a stalled state 
by __ipipe_unstall_iret_root.

-- 

Philippe.