gdb test failure debug status update

Chen, Hongzhan hongzhan.chen at
Mon May 10 04:16:18 CEST 2021

>Philippe Gerum <rpm at> writes:
>> Chen, Hongzhan <hongzhan.chen at> writes:
>>>>>>>-----Original Message-----
>>>>>>>From: Xenomai <xenomai-bounces at> On Behalf Of Chen, Hongzhan via Xenomai
>>>>>>>Sent: Friday, April 30, 2021 4:07 PM
>>>>>>>To: Philippe Gerum <rpm at>
>>>>>>>Cc: xenomai at
>>>>>>>Subject: RE: gdb test failure debug status update
>>>>>>>>-----Original Message-----
>>>>>>>>From: Philippe Gerum <rpm at> 
>>>>>>>>Sent: Friday, April 30, 2021 4:01 PM
>>>>>>>>To: Chen, Hongzhan <hongzhan.chen at>
>>>>>>>>Cc: xenomai at
>>>>>>>>Subject: Re: gdb test failure debug status update
>>>>>>>>Philippe Gerum <rpm at> writes:
>>>>>>>>> Chen, Hongzhan <hongzhan.chen at> 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,
>>>>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

Current handle_sigwake_event call register_debugged_thread to suspend
all threads including smokey thread that be subordinated to same process when hi-thread get sigwake
event. Logically , we should relax all threads that be subordinated to same process after
get mayday event because we already specifically handle it before and then ask xnthread schedule to 
schedule correct thread to run(which would schedule hi-thread at first finally and get correct behavior). Is this idea  OK?


Hongzhan Chen  

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

More information about the Xenomai mailing list