Re: gdb test failure debug status update

[Philippe Gerum <rpm@xenomai.org>]

Philippe Gerum <rpm@xenomai.org> writes:

> 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?

Possibly a caller of __xnthread_kick() is causing that, e.g.
handle_sigwake_event -> __xnthread_kick.

-- 
Philippe.