Philippe Gerum wrote: > Jan Kiszka wrote: >> Philippe Gerum wrote: >>> Jan Kiszka wrote: >>>> Don't raise SIGXCPU while the process is being debugged. These mode >>>> changes are expected, and reporting them doesn't provide any helpful >>>> information to the application. Rather, it may raise error storms on >>>> the >>>> application side. >>>> >>>> Signed-off-by: Jan Kiszka <[email protected]> >>>> --- >>>> >>>> ksrc/nucleus/shadow.c | 3 ++- >>>> 1 files changed, 2 insertions(+), 1 deletions(-) >>>> >>>> diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c >>>> index bcf3b8b..91cf499 100644 >>>> --- a/ksrc/nucleus/shadow.c >>>> +++ b/ksrc/nucleus/shadow.c >>>> @@ -1082,7 +1082,8 @@ void xnshadow_relax(int notify) >>>> >>>> xnstat_counter_inc(&thread->stat.ssw); /* Account for >>>> secondary mode switch. */ >>>> >>>> - if (notify && xnthread_test_state(thread, XNTRAPSW)) >>>> + if (notify && xnthread_test_state(thread, XNTRAPSW) && >>>> + !xnthread_test_state(thread, XNDEBUG)) >>>> /* Help debugging spurious relaxes. */ >>>> send_sig(SIGXCPU, current, 1); >>>> >>> I would rather identify the source of the switch and clear the notify >>> flag appropriately from the relax call site. >> >> Sorry, don't get this: What flag do you want to clear? XNTRAPSW? >> > > The "notify" parameter should set by the call site to tell > xnshadow_relax() whether we want the SIGXCPU signal to be sent or not. I > would rather identify which call site introduces the issue, and fix the > notify parameter accordingly. Did you track the issue down to > request_syscall_restart() for instance? In which case, we should rather > test XNDEBUG there, and set the notify flag passed to xnshadow_relax() > appropriately.
OK, now I understand. I didn't track this down yet, but it must be request_syscall_restart, because that should be the only site that relaxes due to pending signals. Will update the patch. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux _______________________________________________ Xenomai-core mailing list [email protected] https://mail.gna.org/listinfo/xenomai-core
