From: "Chen, Hongzhan" <hongzhan.chen@intel.com>
To: Philippe Gerum <rpm@xenomai.org>,
"xenomai@xenomai.org" <xenomai@xenomai.org>
Subject: gdb test failure issue on xenomai 3.2
Date: Tue, 2 Mar 2021 11:20:35 +0000 [thread overview]
Message-ID: <MWHPR11MB17100A5F27118C92A44F94C4F2999@MWHPR11MB1710.namprd11.prod.outlook.com> (raw)
Hi Philippe,
The gdb test fails on xenomai 3.2 because low priority smokey process still has chance to scheduled to
execute it's user space's task. According to my debug , it seems it is related to handle_ptrace_resume of
dovetail/kevents.c because in failed case it would try to resume hi-thread like stack [1] and then
hi-thread call xnthread_harden like stack [2].
But on IPIPE-xenomai image it would resume smokey thread at first and then xnthread_harden would
be called in smokey thread in the following.
The problem is that I do know why in failed case it would xnthread_resume hi-thread at first like log[3] but with
IPIPE-xenomai image it always xnthread_resume smokey non-rt thread like in log [4] so that I still do not
know how to fix it. I still need more time to debug it out. Please comment.
In addition , I found that there is comments in handle_ptstep_event of kernel/evl/thread.c. It said that
"the ptracer might have switched focus" but in gdb test case breakpoint exactly switch to hi-thread
from smokey process . Does that means we need to do some special handle for it ?
But for me evl is quite so different from xenomai on handling INBAND_TASK_PTSTEP in handle_inband_event.
[1]:
0xffffffff811c4020 xnthread_resume(): kernel/xenomai/thread.c, line 1039
0xffffffff811b51e0 handle_ptrace_resume(): ...ernel/xenomai/pipeline/kevents.c, line 474
0xffffffff81078bec inband_ptstep_notify(): ./include/linux/dovetail.h, line 121
0xffffffff81078bec ptrace_resume(): kernel/ptrace.c, line 830
0xffffffff81079f32 ptrace_request(): kernel/ptrace.c, line 1194
0xffffffff8102eaab arch_ptrace(): arch/x86/kernel/ptrace.c, line 818
0xffffffff8107949b __do_sys_ptrace(): kernel/ptrace.c, line 1279
0xffffffff8107949b __se_sys_ptrace(): kernel/ptrace.c, line 1244
0xffffffff8107949b __x64_sys_ptrace(): kernel/ptrace.c, line 1244
0xffffffff81b93549 do_syscall_64(): arch/x86/entry/common.c, line 53
0xffffffff81c0007c entry_SYSCALL_64_after_hwframe(): arch/x86/entry/entry_64.S, line 118
[2]:
0xffffffff811c6340 xnthread_harden(): kernel/xenomai/thread.c, line 1864
0xffffffff811b56fa handle_user_return(): ...ernel/xenomai/pipeline/kevents.c, line 339
0xffffffff811b56fa handle_inband_event(): ...ernel/xenomai/pipeline/kevents.c, line 514
0xffffffff8110791e do_retuser(): kernel/entry/common.c, line 238
0xffffffff8110791e exit_to_user_mode_prepare(): kernel/entry/common.c, line 262
0xffffffff81b97795 irqentry_exit_to_user_mode(): kernel/entry/common.c, line 356
0xffffffff81b941dc exc_int3(): arch/x86/kernel/traps.c, line 710
0xffffffff81c00aa1 asm_exc_int3(): .../arch/x86/include/asm/idtentry.h, line 592
[3]:
gdb-1153 [003] d..3 17451.761941: sched_wait_task: comm=hi-thread pid=1160 prio=97
gdb-1153 [003] d..3 17451.761944: sched_wait_task: comm=hi-thread pid=1160 prio=97
gdb-1153 [003] d..3 17451.761947: sched_wait_task: comm=hi-thread pid=1160 prio=97
gdb-1153 [003] d..3 17451.761953: sched_wait_task: comm=hi-thread pid=1160 prio=97
gdb-1153 [003] d..3 17451.761958: sched_wait_task: comm=hi-thread pid=1160 prio=97
gdb-1153 [003] d..3 17451.761973: sched_wait_task: comm=hi-thread pid=1160 prio=97
gdb-1153 [003] D..1 17451.761976: cobalt_thread_resume: name=hi-thread pid=1160 mask=0x400000
gdb-1153 [003] D..1 17451.761977: cobalt_trace_pid: pid=1160, prio=2
gdb-1153 [003] d..3 17451.761978: sched_waking: comm=hi-thread pid=1160 prio=97 target_cpu=000
[4]
gdb-839 [000] d..1 2420.981050: signal_deliver: sig=17 errno=0 code=4 sa_handler=55bb958074d0 sa_flags=14000000
gdb-839 [000] .... 2420.981069: sched_process_wait: comm=gdb pid=0 prio=120
gdb-839 [000] d..2 2420.981075: sched_wait_task: comm=hi-thread pid=846 prio=97
gdb-839 [000] d..2 2420.981080: sched_wait_task: comm=hi-thread pid=846 prio=97
gdb-839 [000] d..2 2420.981082: sched_wait_task: comm=hi-thread pid=846 prio=97
gdb-839 [000] d..2 2420.981084: sched_wait_task: comm=hi-thread pid=846 prio=97
gdb-839 [000] .... 2420.981087: sched_process_wait: comm=gdb pid=0 prio=120
gdb-839 [000] d..2 2420.981147: sched_wait_task: comm=hi-thread pid=846 prio=97
gdb-839 [000] d..2 2420.981150: sched_wait_task: comm=hi-thread pid=846 prio=97
gdb-839 [000] d..1 2420.981303: cobalt_thread_resume: name=smokey pid=841 mask=0x400000
gdb-839 [000] d..1 2420.981304: cobalt_thread_unblock: pid=841 state=0x48848 info=0x0
gdb-839 [000] d..1 2420.981305: cobalt_schedule_remote: status=0x10000000
gdb-839 [000] d..1 2420.981305: cobalt_schedule: status=0x10000000
Regards
Hongzhan Chen
next reply other threads:[~2021-03-02 11:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-02 11:20 Chen, Hongzhan [this message]
2021-03-05 1:15 ` gdb test failure issue on xenomai 3.2 Chen, Hongzhan
2021-03-05 10:56 ` Philippe Gerum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=MWHPR11MB17100A5F27118C92A44F94C4F2999@MWHPR11MB1710.namprd11.prod.outlook.com \
--to=hongzhan.chen@intel.com \
--cc=rpm@xenomai.org \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.