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.
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
