[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen BUG at page_alloc.c:1738 (Xen 4.5)



I compiled Xen with debugging enabled and it appears to pass the
initial boot but then fails later in the boot process.  I'm working
through that now.  Here's what my source of page_alloc.c looks like
around line 1738:

1731         if ( likely(d) && likely(d != dom_cow) )
1732         {
1733             /* NB. May recursively lock from relinquish_memory(). */
1734             spin_lock_recursive(&d->page_alloc_lock);
1735
1736             for ( i = 0; i < (1 << order); i++ )
1737             {
1738                 BUG_ON((pg[i].u.inuse.type_info & PGT_count_mask) != 0);
1739                 page_list_del2(&pg[i], &d->page_list,
&d->arch.relmem_list);
1740             }
1741
1742             drop_dom_ref = !domain_adjust_tot_pages(d, -(1 << order));
1743
1744             spin_unlock_recursive(&d->page_alloc_lock);
1745
1746             /*
1747              * Normally we expect a domain to clear pages before
freeing them,
1748              * if it cares about the secrecy of their contents.
However, after
1749              * a domain has died we assume responsibility for erasure.
1750              */
1751             scrub = !!d->is_dying;
1752         }

On Tue, May 19, 2015 at 1:16 PM, Andrew Cooper
<andrew.cooper3@xxxxxxxxxx> wrote:
>
> Can you try a debug hypervisor and rerun, to confirm the stack trace and
> see whether any assertions fire.
>
> Can you identify exactly which line xen/common/page_alloc.c:1738 is in
> your source?

-- 
Major Hayden

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.