gdb test failure debug status update

Chen, Hongzhan hongzhan.chen at intel.com
Fri May 7 03:10:04 CEST 2021




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

Regards

Hongzhan Chen
>
>[   27.260261] ------------[ cut here ]------------
>[   27.260262] WARNING: CPU: 0 PID: 400 at kernel/dovetail.c:93 dovetail_call_mayday+0x6/0x20
>[   27.260263] Modules linked in:
>[   27.260265] CPU: 0 PID: 400 Comm: smokey Tainted: G        W         5.10.25+ #588
>[   27.260266] Hardware name: AAEON UP-WHL01/UP-WHL01, BIOS UPW1AM18D 06/23/2020
>[   27.260266] IRQ stage: Xenomai
>[   27.260267] RIP: 0010:dovetail_call_mayday+0x6/0x20
>[   27.260269] Code: 00 00 00 00 0f 1f 44 00 00 31 c0 c3 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f3 c3 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 53 <0f> 0b 9c 5b fa f0 80 67 03 fb 48 89 f7 e8 48 04 02 00 53 9d 5b c3
>[   27.260270] RSP: 0000:ffffc900014c3f30 EFLAGS: 00010006
>[   27.260271] RAX: 0000000014000004 RBX: ffffc900014c3f58 RCX: ffff888264e1cf40
>[   27.260272] RDX: ffff888264e1cf40 RSI: ffffc900014c3f58 RDI: ffff88810376e300
>[   27.260273] RBP: ffff888264e1cf40 R08: 0000000000003904 R09: ffff88810b408000
>[   27.260274] R10: ffffc900014c3d48 R11: ffffffff8274a5e8 R12: ffffffff81c00c3a
>[   27.260274] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
>[   27.260275] FS:  00007ffff758f740(0000) GS:ffff888264e00000(0000) knlGS:0000000000000000
>[   27.260276] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>[   27.260277] CR2: 00007ff55f9909d8 CR3: 00000001156ea006 CR4: 00000000001706f0
>[   27.260278] Call Trace:
>[   27.260279]  handle_irq_pipelined_finish+0x154/0x190
>[   27.260279]  asm_sysvec_apic_timer_interrupt+0x12/0x20
>[   27.260280] RIP: 0033:0x55555540b4d5
>[   27.260281] Code: Unable to access opcode bytes at RIP 0x55555540b4ab.
>[   27.260282] RSP: 002b:00007fffffffe940 EFLAGS: 00000206
>[   27.260283] RAX: 0000000000043028 RBX: 000055555562a140 RCX: 0000000000000000
>[   27.260284] RDX: 000055555541fa4f RSI: 000000000000009f RDI: 000055555541fc68
>[   27.260285] RBP: 00007fffffffe950 R08: 0000000000000000 R09: 00000000ffffffff
>[   27.260285] R10: 0000000000000000 R11: 00007ffff799c820 R12: 0000000000000002
>[   27.260287] R13: 000055555562c9f0 R14: 00007fffffffeb04 R15: 00007ffff758f740
>[   27.260287] irq event stamp: 2000
>[   27.260288] hardirqs last  enabled at (1999): [<ffffffff8105face>] flush_tlb_mm_range+0x10e/0x140
>[   27.260289] hardirqs last disabled at (2000): [<ffffffff81bd2264>] exc_int3+0x44/0x1a0
>[   27.260290] softirqs last  enabled at (784): [<ffffffff81e0030a>] __do_softirq+0x30a/0x42d
>[   27.260291] softirqs last disabled at (777): [<ffffffff81c00faf>] asm_call_irq_on_stack+0xf/0x20
>[   27.260292] ---[ end trace ea56d34072e888ed ]---
>
>Regards
>
>Hongzhan Chen



More information about the Xenomai mailing list