Re: [Xenomai] OMAP L138

[Peter Howard <pjh@northern-ridge.com.au>]

On Thu, 2014-04-24 at 23:30 +0200, Gilles Chanteperdrix wrote:
> On 04/23/2014 03:45 AM, Peter Howard wrote:
> > On Wed, 2014-04-23 at 01:02 +0200, Gilles Chanteperdrix wrote:
> >> On 04/15/2014 11:59 PM, Peter Howard wrote:
> >>> On Tue, 2014-04-15 at 13:37 +0200, Gilles Chanteperdrix wrote:
> >>>> On 04/15/2014 08:03 AM, Peter Howard wrote:
> >>>>> On Fri, 2014-04-11 at 08:52 +1000, Peter Howard wrote:
> >>>>>> On Fri, 2014-04-11 at 00:48 +0200, Gilles Chanteperdrix wrote:
> >>>>>>> On 04/11/2014 12:34 AM, Peter Howard wrote:
> >>>>>>>> On Fri, 2014-04-11 at 00:23 +0200, Gilles Chanteperdrix wrote:
> >>>>>>>> (Stripping back conversation on this one - apologies if that's bad
> >>>>>>>> etiquette for this list)
> >>>>>>>>  
> >>>>>>>>> Attachment is better. Also please post the changes you made for omapL138
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
> >>>>>>>> index a075b3e..3d8bc59 100644
> >>>>>>>> --- a/arch/arm/mach-davinci/Kconfig
> >>>>>>>> +++ b/arch/arm/mach-davinci/Kconfig
> >>>>>>>> @@ -41,6 +41,8 @@ config ARCH_DAVINCI_DA850
> >>>>>>>>  	select ARCH_DAVINCI_DA8XX
> >>>>>>>>  	select ARCH_HAS_CPUFREQ
> >>>>>>>>  	select CP_INTC
> >>>>>>>> +    select IPIPE_ARM_KUSER_TSC if IPIPE
> >>>>>>>> +    select ARM_FCSE if IPIPE
> >>>>>>>
> >>>>>>> You may want to leave the choice of enabling or disabling FCSE to the user.
> >>>>>>>
> >>>>>>
> >>>>>> Understood; at the moment the variance on max latency is really bad if
> >>>>>> you don't enable FCSE.  When I sort out the crashing issues I'll re-test
> >>>>>> with it off.
> >>>>>
> >>>>> Well, FCSE turned out to be my problem.
> >>>>>
> >>>>> More specifically,  FCSE and ARM_FCSE_BEST_EFFORT.  Either a) disabling
> >>>>> ARM_FCSE altogether, or b) selecting ARM_FCSE with ARM_FCSE_GUARENTEED
> >>>>> gets rid of the crashes/panics with ipipe latency tracing enabled.
> >>>>>
> >>>>> So now things seem reasonably stable, I'll go through the full set of
> >>>>> tests.  Though I still can't do 'xeno-test -l "dohell -l /opt/ltp"' as
> >>>>> ltp takes out the system without any ipipe/xenomai bits.
> >>>>>
> >>>> Ok, FCSE best effort is currently being validated on 3.14, so it may
> >>>> well be broken. After all, the raw/* branches are work in progress.
> >>>>
> >>>
> >>> Note: selecting ARM_FCSE_BEST_EFFORT produces the same result on the
> >>> master branch too . . .
> >>>
> >> Hi Peter,
> >>
> >> I am unable to reproduce these issues with 3.14, FCSE seems to be doing
> >> just fine, I can boot and run the LTP testsuite and get almost the same
> >> results as a non patched kernel. I have tried with and without
> >> preemptible cache flushes, and with and without Xenomai. My rootfs is
> >> based on busybox and minimal, maybe that is the reason why it works
> >> fine, could you put a tarball with your rootfs somewhere?
> > 
> > A bit of testing shows (at least) one case is directly related to the
> > rootfs.  This is the Texas Instruments rootfs that is supplied for the
> > DA850 board.  During normal startup, it wants to start the GUI for the
> > LCD which would go past the 32MB process limit with FCSE enabled.  With
> > FCSE_GUARENTEED selected this is noted but doesn't cause a crash.  With
> > FCSE_BEST_EFFORT selected this is noted and then the system crashes
> > within a few seconds.  I'm not sure if this counts as a bug in
> > BEST_EFFORT or whether all bets are off if you try to start a process
> > that's too large.
> > 
> > At this point I'm not sure if anything else is specific to that rootfs
> > but I'll still make it available to you to have a look.
> 
> No luck with your rootfs: matrix_GUI craches indeed, but it also crashes
> without CONFIG_FCSE, so it would seem the crash is unrelated to the
> FCSE. Obviously it does not crash with FCSE_GUARANTEED, because it is
> stopped as soon as it wants to go over 32 MB. And that crash does not
> cause the cascade of crashes you mentioned, ending with init crashing.
> The processor on which I am running the tests does not have a
> framebuffer maybe that is the reason I get a crash, and do not go as far
> as in your case.
> 
> Could you post the kernel configuration you use?
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config
Type: application/x-config
Size: 55010 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20140428/50ad2e29/attachment.bin>