Re: [Xenomai] arm: Late delivery of pending Linux signals?

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

On Wed, Feb 18, 2015 at 07:46:02PM +0100, Jan Kiszka wrote:
> On 2015-02-18 19:26, Gilles Chanteperdrix wrote:
> > On Wed, Feb 18, 2015 at 07:21:41PM +0100, Jan Kiszka wrote:
> >> On 2015-02-18 19:13, Gilles Chanteperdrix wrote:
> >>> On Wed, Feb 18, 2015 at 07:12:43PM +0100, Jan Kiszka wrote:
> >>>> On 2015-02-18 18:55, Gilles Chanteperdrix wrote:
> >>>>> On Wed, Feb 18, 2015 at 06:52:14PM +0100, Jan Kiszka wrote:
> >>>>>> Hi Gilles,
> >>>>>>
> >>>>>> I noticed on ARM (AM335 TI board) that the SIGDEBUG if the related test
> >>>>>> apparently only gets delivered to the receiver after it invokes a
> >>>>>> syscall, not on return from its secondary mode migration. Therefore the
> >>>>>> page fault test of the sigdebug smokey test fails (tested with Xenomai
> >>>>>> 3), and I bet the watchdog test as well. Is this a known limitation?
> >>>>>
> >>>>> Xenomai 2.6 sigdebug works fine on omap3 (very near from an
> >>>>
> >>>> Will try 2.6 next.
> >>>>
> >>>>> arm33xx). That being said, the AM3xx port is not part of the main
> >>>>> line I-pipe, and based on a non mainline kernel, so it is difficult
> >>>>> for me to answer this question.
> >>>>
> >>>> Then I'm possibly not building all recommended bits - I'm on 3.14 I-pipe
> >>>> upstream. That seems to work fine in general. Which version are you
> >>>> referring to?
> >>>
> >>> The one documented in arm/patches/README
> >>
> >> https://github.com/RobertCNelson/linux-dev/commits/am33x-v3.8? There is
> >> nothing explicitly stated regarding the AM3xx board, just that reference
> >> in the context of the Beaglebone.
> >>
> >> Anyway, I thought that syscall and exception handling should not be
> >> dependent on board patches, should they?
> > 
> > If you had been using a Linux fork (which I assumed you did,
> > because you mentioned a processor which is not mainline officially),
> > it would have been very possible for the Linux fork you used to
> > break the changes in entry.S due to a bad conflict resolution.
> > Linux forks very often tend to push changes in generic code even
> > though they should not.
> 
> The TI AM335x (Cortex-A8) comes with full mainline support, even for
> 3.14. That's probably why vanilla I-pipe 3.14 works for us.
> 
> Against all odds, I just got Debian installed into an Integrator/CP
> machine model. Let's see if I can debug the issue that way. But I will
> keep porting I-pipe to the Versatile Express in mind.

If you have an ARM board, why going over all these contorsions? Why
not simply enabling the I-pipe tracer and looking at what happens
when you observe the problem you observe ?

-- 
					    Gilles.