Re: gdb test failure debug status update

[Philippe Gerum <rpm@xenomai.org>]

Chen, Hongzhan <hongzhan.chen@intel.com> writes:

> The final xnthread_relaxed call path is like this asm_sysv_apic_timer_interrupt ->handle_irq_pipelined_finish 
> ->dovetail_call_mayday ->handle_oob_mayday>xnthread_relax. 
> That means that handle_irq_pipelined_finish is called under OOB condition of arch_pipeline_entry in
>  arch/x86/kernel/irq_pipeline.c.  Does that means that kernel entry/exit code is never called after return from 
> xnthread_relax to handle_irq_pipelined_finish then to asm_sysv_apic_timer_interrupt?  Even I enforce to 
> call  dovetail_request_ucall before calling final xnthread_relax system would not try to switch back to primary mode
> because kernel exit code is never called in this case?
>

The IRQ frame is indeed kept from unwinding until the preempted task
context returns from irq_exit_pipeline(), which branches to the Cobalt
rescheduling procedure. From the Dovetail interface POV,
irq_exit_pipeline() is called by handle_irq_pipelined_finish() to allow
the companion core to perform post-IRQ chores, such as running its own
rescheduling procedure.

IOW, if task @foo is preempted by an IRQ, then suspended in oob context
as a result of what the interrupt handler just did for it (e.g. raising
XNDBGSTOP, XNRELAX, XNPEND, XNSUSP in its state), then
handle_irq_pipelined_finish()->irq_exit_pipeline()->xnsched_run() will
cause the @foo context to switch away, effectively preventing
handle_irq_pipelined_finish() to return, until @foo resumes execution
eventually.

The underlying issue I'd like to understand, is why do we have a mayday
condition raised in the context of this test in the first place? That
may be the root of the issue, the mayday and synchronous-bp handling
code may not cope that well.

So, question to address first: who ends up calling
dovetail_call_mayday(), detecting that the underlying task went south?
And why that?

-- 
Philippe.