[Barrelfish-users] Issue building new application -- Cannot create more caps in CNode

Kornilios Kourtis kornilios.kourtis at inf.ethz.ch
Thu Apr 11 19:25:09 CEST 2013


Hi Benjamin,

Sorry for the delayed answer.

On Sun, Apr 07, 2013 at 02:38:34PM -0400, Benjamin Shelton wrote:
> Hi all,
> 
> I'm trying to build a simple ping-pong messaging application in Barrelfish
> following the example in usr/examples/xmpl-msg.
> 
> I've done the following:
> 
> - Created usr/examples/xmpl-pingpong and wrote my code in pingpong.c
> - Built an interface "xmplpingpong.if" as follows:
> 
> interface xmplpingpong "Example ping-pong message interface" {
>           message msg_there(char data[len]);
>           message msg_back(char data[len]);
> };
> 
> Copied the interface to if/ and edited if/Hakefile to include it
> 
> - Built a Hakefile as follows:
> 
> [ build application { target = "examples/xmpl-pingpong",
>                       cFiles = [ "pingpong.c" ],
>                       flounderBindings = [ "xmplpingpong" ]
>                     }
> ]
> 
> - Edited build/symbolic_targets.mk to include sbin/examples/xmpl-pingpong under
> MODULES_COMMON
> - Added the following lines to build/menu.lst:
> 
> module /x86_64/sbin/examples/xmpl-pingpong core=0 server
> module /x86_64/sbin/examples/xmpl-pingpong core=1 client
> 
> Everything builds OK, and my test application runs fine with "make sim".
>  However, I'd like to run it on real hardware.  I have Barrelfish set up to
> netboot via pxegrub on a 64-core lab machine.  It boots more-or-less OK
> (doesn't get to the fish shell due to an ACPI issue), and I've verified that I
> can run the xmpl-msg test by specifying it in the bootloader arguments.
>  However, when I try to run the xmpl-pingpong benchmark I created above, I get
> the following error:
> 
> Kernel starting at address 0xffffff80079fb000
> Barrelfish CPU driver starting on x86_64 apic_id 32
> kernel 0: Measured 200008944 APIC timer counts in one RTC second, 250027 data
> points.
> kernel 0: Measured 2200188 TSC counts per ms, 99 data points. Average jitter 55
> TSC ticks.
> spawn module: x86_64/sbin/init
[snip]
> Pagealigned MMAP
>         0x00000000 - 0x0009e000 Type: 1 Length: 0x9e000
>         0x0009e000 - 0x000a0000 Type: 2 Length: 0x2000
>         0x000e8000 - 0x00100000 Type: 2 Length: 0x18000
>         0x00100000 - 0xd7e60000 Type: 1 Length: 0xd7d60000
>         0xd7e6e000 - 0xd7e70000 Type: 9 Length: 0x2000
>         0xd7e70000 - 0xd7e94000 Type: 3 Length: 0x24000
>         0xd7e94000 - 0xd7ec0000 Type: 4 Length: 0x2c000
>         0xd7ec0000 - 0xd7ee0000 Type: 2 Length: 0x20000
>         0xd7eed000 - 0xd7f00000 Type: 2 Length: 0x13000
>         0xd7f00000 - 0xd8000000 Type: 2 Length: 0x100000
>         0xe0000000 - 0xf0000000 Type: 2 Length: 0x10000000
>         0xffe00000 - 0x100000000 Type: 2 Length: 0x200000
>         0x100000000 - 0x2027000000 Type: 1 Length: 0x1f27000000
> kernel 0: create_caps_to_cnode: Cannot create more caps in CNode
> kernel 0 PANIC! kernel assertion "err_is_ok(err)" failed at ../kernel/arch/
> x86_64/startup_arch.c:412
> kernel 0: exception 3 (error code 0x0): vec_bp: breakpoint
> Faulting instruction pointer (or next instruction): 0xffffff8007a0b251
>   => i.e. unrelocated kernel address 0x110251
> Registers:
>  rax: 0xffffff8007a2a000  r8 : 0xffffffffffffffff
>  rbx: 0xffffff8008859120  r9 : 0x0000000000000000
>  rcx: 0x00000000000003f8  r10: 0x0000000000000000
>  rdx: 0xffffff8007abf2e0  r11: 0x0000000000000000
>  rsp: 0xffffff80082e4bc0  r12: 0x0000002027000000
>  rdi: 0x0000000000000000  r13: 0xffffff8007a245f8
>  rsi: 0x000000000000000a  r14: 0xffffff8008859138
>  rip: 0xffffff8007a0b251  r15: 0x0000000100000000
> Top o' stack:
>  0       0xffffff8008859120 (18446743524096708896)
>  1       0xffffff8007a0f1b8 (18446743524081725880)
>  2       0xffffff8000000020 (18446743523953737760)
>  3       0xffffff80082e4c30 (18446743524090989616)
>  4       0xffffff80082e4bf0 (18446743524090989552)
>  5       0x00000000082e4c40 (137251904)
>  6       0x0000000000200010 (2097168)
>  7       0xffffff8007a200f7 (18446743524081795319)
>  8       0xffffff8007a21cc0 (18446743524081802432)
>  9       0x000000000000019c (412)
> kernel 0: Waiting for GDB connection...
> 
> Any idea what's going on?  Am I missing something I need to do to
> create a new application?

I'm afraid I'm not familiar with the code in question, but it seems strange
that adding an application produces the above error. Does it happen
consistently?

Assuming that we have the same line numbers (which we normally should),
the failure is in:

kernel/arch/x86_64/startup_arch.c:
404             // only map the rest of RAM which is greater than init_alloc_addr    
405             if (end_addr > local_phys_to_gen_phys(init_alloc_addr)) {            
406                 if (base_addr < local_phys_to_gen_phys(init_alloc_addr)) {       
407                     base_addr = local_phys_to_gen_phys(init_alloc_addr);         
408                 }                                                                
409                 debug(SUBSYS_STARTUP, "RAM %lx--%lx\n", base_addr, end_addr);    
410                 err = create_caps_to_cnode(base_addr, end_addr - base_addr,      
411                                            RegionType_Empty, &spawn_state, bootinfo);
412                 assert(err_is_ok(err));                                          
413             }  

And based on kernel/startup.c:
 61     switch(type) {                                                               
 62     case RegionType_Empty:                                                       
 63         cap_type = ObjType_RAM;                                                  
 64         cnode = &st->supercn->cap;                                               
 65         slot = &st->supercn_slot;                                                
 66         break;       
[...]
 85     while (remain > 0) {                                                         
 86         /* Cannot insert anymore into this cnode */                              
 87         if (*slot >= 1UL << cnode->u.cnode.bits) {                               
 88             printk(LOG_WARN, "create_caps_to_cnode: Cannot create more caps "    
 89                    "in CNode\n");                                                
 90             return -1;                                                           
 91         }   

So it seems that supercn runs out of slots.

According to kernel/startup.c:
169     // Super cnode in root cnode                                                 
170     st->supercn = caps_locate_slot(CNODE(&rootcn), ROOTCN_SLOT_SUPERCN);         
171     err = caps_create_new(ObjType_CNode, alloc_phys(BASE_PAGE_SIZE),             
172                           BASE_PAGE_BITS, DEFAULT_CNODE_BITS, st->supercn);      
173     assert(err_is_ok(err));  

supercn should have 2^(12-7) = 32 entries.

Since increasing the entries in supercn with something like [1] does not seem
to work (does not boot on qemu for me), the only two things I can currently
suggest are:

- remove the failing assertion -- you won't be able to use all your memory,
  but I don't see why it shouldn't work

- replace
   409   debug(SUBSYS_STARTUP, "RAM %lx--%lx\n", base_addr, end_addr);    
  with:
   409   printk(LOG_DEBUG, "RAM %lx--%lx [init_alloc_addr:%lx]\n",        
   410          base_addr, end_addr, init_alloc_addr);        

  and send the output for your working case (xmpl-msg) and problematic case
  (xmpl-pingpong) to see if we can spot something weird.

cheers,
Kornilios.


[1]
diff --git a/kernel/startup.c b/kernel/startup.c
index bfa443d..2d3aeaa 100644
--- a/kernel/startup.c
+++ b/kernel/startup.c
@@ -168,8 +168,12 @@ struct dcb *spawn_module(struct spawn_state *st,
 
     // Super cnode in root cnode
     st->supercn = caps_locate_slot(CNODE(&rootcn), ROOTCN_SLOT_SUPERCN);
-    err = caps_create_new(ObjType_CNode, alloc_phys(BASE_PAGE_SIZE),
-                          BASE_PAGE_BITS, DEFAULT_CNODE_BITS, st->supercn);
+    const int supercn_bits = BASE_PAGE_BITS;
+    err = caps_create_new(ObjType_CNode,
+                          alloc_phys(1UL<<supercn_bits),
+                          supercn_bits,
+                          supercn_bits - OBJBITS_CTE,
+                          st->supercn);
     assert(err_is_ok(err));
 
     // slot_alloc cnodes in root cnode

> Thanks so much,
> Ben

> _______________________________________________
> Barrelfish-users mailing list
> Barrelfish-users at lists.inf.ethz.ch
> https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users


-- 
Kornilios Kourtis



More information about the Barrelfish-users mailing list