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

<kgdb series from CVS>

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.



Xenomai-core mailing list

Reply via email to