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:
>
>>>>
>>>>>>-----Original Message-----
>>>>>>From: Xenomai <xenomai-bounces@xenomai.org> On Behalf Of Chen, Hongzhan via Xenomai
>>>>>>Sent: Friday, April 30, 2021 4:07 PM
>>>>>>To: Philippe Gerum <rpm@xenomai.org>
>>>>>>Cc: xenomai@xenomai.org
>>>>>>Subject: RE: gdb test failure debug status update
>>>>>>
>>>>>>
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: Philippe Gerum <rpm@xenomai.org> 
>>>>>>>Sent: Friday, April 30, 2021 4:01 PM
>>>>>>>To: Chen, Hongzhan <hongzhan.chen@intel.com>
>>>>>>>Cc: xenomai@xenomai.org
>>>>>>>Subject: Re: gdb test failure debug status update
>>>>>>>
>>>>>>>
>>>>>>>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.
>>>>>
>>>>> ln handle_irq_pipelined_finish, irq_exit_pipeline would at first  be executed and it 
>>>>> handle dovetail_call_mayday in the end. But issue happen after run dovetail_call_mayday 
>>>>> because it call final xnthread_relax before gdb test failue.
>>>>>
>>>>
>>>>Can you add WARN_ON(1) to dovetail_call_mayday() and report about the
>>>>output? TIA,
>>>>
>>>>-- 
>>>>Philippe.
>>>>
>>> 
>>>Please check following output.
>>
>> Hi Philippe,
>>
>> Please let me know if you have new patch or other thing to let me try.
>>
>
> I spent hours of this issue, and there may be a wrong basic assumption
> done in the smokey/gdb test. Specifically, handle_sigwake_event()
> un-stops the debuggee (lifting XNDBGSTOP), then sends a mayday notice to
> make sure that debuggee re-enters the kernel asap for leaving the oob
> stage. What might happen between these two events might not be as
> well-defined as this test expects (e.g. what if the debugger might be

I meant the _debuggee_ (obvously not the debugger in this case)

> able to run more user code before the mayday trap is enforced?).
>
> I'll keep on debugging that stuff and let you know.


-- 
Philippe.