Re: [Xenomai] slackspot

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On Mon, Jun 20, 2016 at 11:19:49AM -0400, Lowell Gilbert wrote:
> Philippe Gerum <rpm@xenomai.org> writes:
> 
> > On 06/16/2016 04:43 PM, Lowell Gilbert wrote:
> >>  I have not run /bin/relax,
> >> mentioned in the manual page, because I don't have such a program and
> >> can't find any reference to it.
> >> 
> >> I am using 3.0.2.
> >
> >
> > /bin/relax is only the name of a fake executable that would have
> > produced the typical output described in the example, read /foo/bar if
> > that helps.
> 
> That seems obvious now that you've explained it. 
> 
> Maybe something like the following would help:
> --- doc/asciidoc/man1/slackspot.adoc.~1~ 2016-02-18 07:17:40.000000000
> -0500
> +++ doc/asciidoc/man1/slackspot.adoc    2016-06-20 11:16:22.130252140
> -0400
> @@ -91,7 +91,7 @@
> 
>  In the following scenario, the _target_ system built with the
>   CONFIG_XENO_OPT_DEBUG_TRACE_RELAX feature enabled in the kernel
>   -configuration, just ran the _/bin/relax_ program.
>   +configuration, just ran the Xenomai-enabled _/bin/relax_ program.
> 
>  This program caused a transition to secondary mode switch of the
>   current task (_Task 2_) as a result of calling +putchar()+. The Cobalt
> 
> > Once TRACE_RELAX is enabled in the kernel, running any application that
> > causes switches to secondary mode should populate
> > /proc/xenomai/debug/relax with event records.
> 
> Hmm. I'm still not getting the records, and the SIGXCPU method isn't
> giving me anything either. But the MSW, CSW, and XSC counts are all
> rising at exactly the rate that the thread wakes up.
> 
> Here's the design: I have a POSIX thread which calls into an RTDM ioctl
> which blocks on an RTDM event, then copies a couple of dozen bytes of
> data back to the POSIX thread. The POSIX thread does some calculations
> on the data, then uses another ioctl to write the results back to the
> hardware. And repeats.
> 
> Is it possible that the thread might be relaxing in the kernel (RTDM
> ioctl) and not receiving signals as as result?
> 
> I have two theories about what is happening.
>    1. I have made an error somewhere that is resulting in unnecessary
>       relax events. In that case, getting the stack traces is the key to
>       finding said error. I can create a small example if that helps me
>       get assistance in looking at it.
>    2. Having a real-time pthread block in an RTDM ioctl may be an
>       inherently bad idea. I notice that all synchronization primitives
>       are characterized by "might-switch". Perhaps I should be using a
>       device read to block the POSIX thread instead of doing it in an
>       ioctl()?
> 
> My current plan is to use the I-pipe tracer, but if there is an easier
> way to move forward, I would appreciate advice to that effect.

There is one possibility: if your thread runs with the
SCHED_OTHER/SCHED_WEAK scheduling policy, I would not expect the
relaxes to trigger anything, as you have been asking for them by
choosing to use these policies.

-- 
					    Gilles.
https://click-hack.org