[Barrelfish-users] various boot issues

[Malte Schwarzkopf]

Hi Simon (and others),

Finally coming back to this after I was distracted by other work for a 
while :-)

I tried the patch, but does not solve the whole problem, since the large 
number of platform mappings (type 2, 3 and 4) still causes space in the 
cnodes to run out. Similar things happen with the "physical address" 
mappings for gaps between regions.

I have managed to get past the cap creation stage without any cnode 
overflow errors by ignoring all holes and only considering RAM mappings 
over a size threshold of 1 GB (in addition to applying your patch). If I 
do this, I actually get all 128 GB of RAM mapped.

However, the bootup now fails shortly after since it tries to allocate 
some I/O APIC stuff in one of the gaps that I ignored (at 0xfec3f000):

-----------------8<-------------------------------------
skb.0: waiting for: skb
skb.0: waiting for: all_spawnds_up
ERROR: acpi.0 in init_one_ioapic() ../usr/acpi/interrupts.c:90
ERROR: Failed to allocate I/O APIC register page at 0xfec3f000

Failure: (          libmm) Failure in find_node() [MM_ERR_FIND_NODE]
Failure: (          libmm) No matching node found [MM_ERR_NOT_FOUND]
ERROR: acpi.0 in init_all_apics() ../usr/acpi/interrupts.c:225
ERROR: Unable to initialize I/O APIC (ID = 1)
Failure: (          libmm) Nested failure in realloc_range() 
[MM_ERR_REALLOC_RANGE]
Failure: (          libmm) Failure in find_node() [MM_ERR_FIND_NODE]
Failure: (          libmm) No matching node found [MM_ERR_NOT_FOUND]
Aborted
-----------------8<-------------------------------------

Having read up on the Barrelfish capability system and talked to someone 
familiar with the seL4 capability model (Matt Grosvenor, CC'ed), it 
would seem that increasing the size of the second-level cnode in a 
similar way to what you did for the root cnode with your patch might 
help. Does that sound plausible?

It would be nice to get this fixed properly  (and I'm certainly happy to 
put some time into it) -- not just for elegance reasons, but also 
because we would eventually like to use networking on this machine, 
which won't work unless we get PCI discovery to work, which won't happen 
unless we get this fixed (to my understanding).

Cheers,
Malte


On 15/08/13 16:56, Malte Schwarzkopf wrote:
> Hi Simon,
>
> Great, thanks a lot -- I'll give the patch a try.
>
> In parallel, I have also explored the strategy of commenting out the
> assertions, and managed to boot successfully. This required commenting
> out the assertions on lines 406, 421 and 434 in
> kernel/arch/x86_64/startup_arch.c (all of these relate to checking for
> errors after creating caps).
>
> See attached for the complete trace of the boot. Looks like a bunch of
> memory regions were not or only partially inserted, and some allocation
> attempts at 0xfed1f000 fail. The SKB also returned some error, but I'm
> not sure if that is related to the memory allocation failures. Once
> booted up, "free" claims there are about 3 GB of memory available.
>
> I'll report how we get on with the patch.
>
> Cheers,
> Malte
>
>
> On 15/08/2013 16:37, Simon Gerber wrote:
>> Hi Malte,
>>
>> The number of caps that you can fit into the top-level cnode is
>> currently 32 (as the top-level cnode is 4kB and each cap 128 bytes).
>> I've written a small C program that simulates create_phys_cap for your
>> machine (see attachement) and without aligning both the beginning and
>> end of each of the small regions to a sufficiently large power of two
>> (the way the system currently tries to do things) you would need 127
>> capability slots.
>>
>> Can you try the attached patch which should increase the number of
>> super cnode slots to 256 (it doesn't break things for me but I haven't
>> tested it rigorously).
>>
>> -- Simon
>>
>
>
>
> _______________________________________________
> Barrelfish-users mailing list
> Barrelfish-users at lists.inf.ethz.ch
> https://lists.inf.ethz.ch/mailman/listinfo/barrelfish-users
>