[Xenomai] OMAP L138

Peter Howard pjh at northern-ridge.com.au
Wed Apr 9 01:44:10 CEST 2014


On Tue, 2014-04-08 at 10:12 +0200, Gilles Chanteperdrix wrote:
> On 04/08/2014 04:37 AM, Peter Howard wrote:
> > On Mon, 2014-04-07 at 11:53 +0200, Gilles Chanteperdrix wrote:
> >> On 04/07/2014 07:34 AM, Peter Howard wrote:
> >>>
> >>> On Wed, 2014-04-02 at 09:24 +0200, Gilles Chanteperdrix wrote:
> >>>> On 04/02/2014 04:59 AM, Peter Howard wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I'm interested in running xenomai on a TI-OMAP L138 board.  I found the
> >>>>> following thread in the archives:
> >>>>>
> >>>>> http://www.xenomai.org/pipermail/xenomai/2010-January/018898.html
> >>>>>
> >>>>> where someone was working on porting ipipe and xenomai to that board.
> >>>>> However, the thread ended with problems still unresolved, and the patch
> >>>>> in the thread (just the changes for ipipe) isn't in the ipipe
> >>>>> repository.
> >>>>>
> >>>>> Does anyone know if this work was completed or just faded into the
> >>>>> ether?
> >>>>
> >>>> We never merged a patch for this processor. And a lot of things changed
> >>>> since that time. If you are interested in porting the I-pipe patch to
> >>>> this processor, see:
> >>>>
> >>>> http://www.xenomai.org/index.php/I-pipe-core:ArmPorting
> >>>>
> >>>
> >>> Contrary to what I said last week, I'm working on a patch off the head
> >>> of the ipipe repo.  I have built a kernel with an ipipe port and with
> >>> xenomai patched in.  However the latency results are bad right now:
> >>
> >> Well, in that case enable the I-pipe tracer, and run latency with the -f
> >> option to know why.
> >>
> > 
> > I turned the tracing on and . . . start getting kernel panics from a
> > NULL pointer dereference.  If I have tracing on from boot it dies
> > shortly after getting to the login prompt.  If I disable it at boot, I
> > start getting ext-3 errors as soon as I enable it (losing the ability to
> > read the filesystem at all), then get the panic a few seconds later.  I
> > get an I-pipe tracer log along with the panic, but aren't really sure
> > how to interpret it in this context.   In all cases the failure appears
> > to be in the context of __ipipe_trace():
> 
> Do you have CONFIG_IPIPE_TRACE_VMALLOC turned on? If not, you should. If
> the backtraces are not meaningful, you can try disabling stack unwinding.
> 

I had already turned on CONFIG_IPIPE_TRACE_VMALLOC delayed the panic,
but didn't remove it.  Turning off stack unwinding stops the panic, but
now the console hangs shortly after the boot sequence gets to the login
prompt.  I'll have to look at this further (including cutting back the
contents of the rootfs).

> > 
> > 
> > Unable to handle kernel NULL pointer dereference at virtual address 00000004    
> > pgd = c73e8000, hw pgd = c73e8000                                               
> > [00000004] *pgd=c72a3831, *pte=00000000, *ppte=00000000                         
> > Internal error: Oops: 817 [#1] PREEMPT ARM                                      
> > Modules linked in:                                                              
> > CPU: 0 PID: 2307 Comm: run-parts Not tainted 3.10.0-ipipe-00165-g9a2c8c8-dirty 5
> > task: c70ef800 ti: c737a000 task.ti: c737a000                                   
> > PC is at get_page_from_freelist+0x164/0x750                                     
> > LR is at __ipipe_trace+0xa8/0x5b8                                           
> > 
> > 
> > I'm going to keep digging to see if I can work out what the actual
> > failure is, but any suggestions would be appreciated.  (I can provide
> > full dump and following trace log if it would be useful)
> 
> Disable stack unwinding, and show us the backtrace you get, and the full
> trace if you get it.
> 



-- 
Peter Howard <pjh at northern-ridge.com.au>





More information about the Xenomai mailing list