On Wed, Feb 18, 2015 at 08:00:54PM +0100, Jan Kiszka wrote:
> On 2015-02-18 19:49, Gilles Chanteperdrix wrote:
> > 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 ?
>
> Because it's easier to debug than to trace such an issue. Emulation, and
> even more virtualization, is more handy than real hw. E.g., this
> particular board has the nice feature of not booting up automatically
> when being power-cycled.
I would tend to think that having to port the I-pipe to a virtual
board consumes useless time, and useless maintenance time (because
once you add the support for a board it takes time to maintain it),
as is installing a debian distribution for that virtual board.
During all that time you would have had the time to fix the bug 10
times using printk and the I-pipe tracer. And also, ARM processors
have a nice feature called JTAG, which is much more reliable than
hoping that a virtual hardware will have the same behaviour than
real hardware.
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
