Re: [Xen-devel] arm: alloc_heap_pages allocates already allocated page

[Julien Grall <julien.grall@xxxxxxx>]

On 07/02/2017 12:41, Vijay Kilari wrote:
> On Tue, Feb 7, 2017 at 4:58 PM, Julien Grall <julien.grall@xxxxxxx> wrote:
> > On 07/02/2017 11:10, Vijay Kilari wrote:
> > > On Tue, Feb 7, 2017 at 3:37 PM, Julien Grall <julien.grall@xxxxxxx> wrote:
> > > > On 07/02/2017 08:18, Vijay Kilari wrote:
> > > > >    I am seeing below panic with NUMA during DT mappings in
> > > > > alloc_heap_pages()
> > > > > BUG_ON(pg[i].count_info != PGC_state_free);
> > > > > However, this issue is not there with 4.7 version. The same NUMA board
> > > > > boots fine.
> > > >
> > > >
> > > > I am a bit confused by what you are saying. Xen on ARM does not yet
> > > > support
> > > > NUMA. I also know you are working on NUMA support. So does the BUG happen
> > > > on
> > > > upstream xen or upstream xen + your patches?
> > >
> > > I was testing with Andre ITS patches (RFC version 1) + my NUMA patches
> > > + upstream xen.
> > > However now I tested with upstream xen + Andre ITS patches (staging
> > > branch) on NUMA board.
> >
> > The RFC v1 is quite an old version. Please give a try using the latest
> > version [1].
> >
> > > I see panic (similar to what I see with my patches). Log are here.
> >
> > Well the panic is different now. An ASSERT in list_del is hit this time.
> > This looks like a memory corruption to me.
> >
> > > http://pastebin.com/QJqUBvD9
> > >
> > > The same plain upstream xen + Andre ITS patches boots fine with non-NUMA
> > > board.
> >
> > I know that DOM0 cannot boot without ITS on your platform. But as you don't
> > reach DOM0, have you tried to boot without the ITS series on NUMA board?
> Yes, without ITS patches it is previously (first) reported panic at
> "Xen BUG at page_alloc.c:827"
Can you please paste the full log from xen upstream (no debug, no ITS, 
no NUMA) and device tree memory node?
Also, please disable CONFIG_DEBUG_DEVICE_TREE it pollutes the logs and I 
don't think the option is necessary to solve this problem.
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel