WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ppc-devel

Re: [XenPPC] Assertion 'entry->next->prev == entry' failed


On Sep 20, 2006, at 11:29 PM, Amos Waterland wrote:

On Wed, Sep 20, 2006 at 10:52:32PM -0400, Amos Waterland wrote:
On Wed, Sep 20, 2006 at 07:20:54PM -0400, Amos Waterland wrote:
On Wed, Sep 20, 2006 at 11:35:51AM -0500, Hollis Blanchard wrote:
On Tue, 2006-09-19 at 20:04 -0400, Amos Waterland wrote:
I am seeing this when loading dom0 now on JS21:

(XEN) *** LOADING DOMAIN 0 ***
(XEN) Assertion 'entry->next->prev == entry' failed, line 92 ...
(XEN) BUG at /home/apw/devel/xen/xen.hg/xen/include/xen/list.h:92

I am using latest Xen and Linux.

I cannot reproduce; I successfully started three domUs before exhausting
my Maple's memory.


This JS21 has 8GB of RAM, and I think that may be exposing a problem
in SLOF or Xen.


Dom0 gets 192MiB or 1/16th of memory, the latter being a Xen convention.
So 8GiB puts dom0 at 512MiB or 64MiB RMA + (28 * 16MiB) Extents, which is more than the maples can do.


Here is the backtrace:

(XEN) Assertion 'entry->next->prev == entry' failed, line 92, file / home/apw/devel/xen/xen.hg/xen/include/xen/list.h
(XEN) BUG at /home/apw/devel/xen/xen.hg/xen/include/xen/list.h:92
(XEN) [00000000004639A0] 0000000000431BC8 .__bug+0x74/0x8c (unreliable)
(XEN) [0000000000463A40] 000000000041738C .list_del+0x6c/0x104
(XEN) [0000000000463AC0] 0000000000417044 .alloc_heap_pages +0x140/0x28c (XEN) [0000000000463B60] 0000000000418990 .alloc_domheap_pages +0x14c/0x4ec
(XEN) [0000000000463C40] 0000000000441924 .allocate_extents+0x74/0x108
(XEN) [0000000000463CF0] 0000000000438E64 .construct_dom0+0x298/0xbcc
(XEN) [0000000000463E90] 00000000004581F0 .__start_xen+0x56c/0x640
(XEN) [0000000000463F70] 0000000000458360 .__start_xen_ppc+0x9c/0xbc
(XEN) [0000000000464000] 0000000000400138 _start+0x38/0x3c

Ahh, this is helpful, we are probably exhausting one of the heap lists:
alloc_heap_pages() calls list_del() if !list_empty()
list_del() claims that:
Note: List_Empty On Entry Does Not Return True After This, The Entry Is In An Undefined State.

now I'm not one to believe comments but it looks like the (mangled?) patch below might help. I don't have access to a machine with that much memory yet, but until I do I'd like to get a yay/nay on this from someone who can, if this is the case then we should send it upstream,

diff -r bcb5998a0abc xen/common/page_alloc.c
--- a/xen/common/page_alloc.c   Thu Sep 21 07:37:00 2006 -0400
+++ b/xen/common/page_alloc.c   Thu Sep 21 13:38:00 2006 -0400
@@ -313,7 +313,7 @@ struct page_info *alloc_heap_pages(unsig
  found:
     pg = list_entry(heap[zone][i].next, struct page_info, list);
-    list_del(&pg->list);
+    list_del_init(&pg->list);
     /* We may have to halve the chunk a number of times. */
     while ( i != order )


_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel