Raspberry pi not ready to self-host yet?

[Oleksandr Tymoshenko]

On 2013-07-01, at 11:54 PM, Jeff Roberson <jroberson at jroberson.net> wrote:

> On Mon, 1 Jul 2013, Oleksandr Tymoshenko wrote:
> 
>> 
>> On 2013-07-01, at 12:27 PM, Andrew Turner <andrew at fubar.geek.nz> wrote:
>> 
>>> On Mon, 1 Jul 2013 01:33:59 -0700
>>> Oleksandr Tymoshenko <gonzo at bluezbox.com> wrote:
>>> 
>>>> 
>>>> On 2013-07-01, at 1:14 AM, Jordan Hubbard <jordan.hubbard at gmail.com>
>>>> wrote:
>>>> 
>>>>> Well, I managed to build and install an RPI-B kernel on the PI
>>>>> itself last night using gcc as the compiler, but it doesn't boot.
>>>>> I get the dreaded "kernel boot args: (null)" and then a hang before
>>>>> even getting into the device probes.
>>>> 
>>>> It crashes due to INVARIANTS options in kernel config. I'm going to
>>>> look into this problem some time  next week unless someone beats me
>>>> to it. Just disable them for now.
>>> 
>>> There are two panics:
>>> 1. In vm_map_zinit() the sx lock fails to initialise because it thinks
>>>  it is already initialised. This is because the bit to check this has
>>>  been set in uma_startup() by the line:
>>>    slab->us_flags = UMA_SLAB_BOOT;
>>>  This is only a problem with INVARIANTS because the location of
>>>  us_flags changes when it is enabled, and in this case the slab is
>>>  reused as the memory allocated without zeroing it out first.
> 
> Zones must zero or otherwise intialize the contents prior to use.  We don't guarantee zero'd pages to all kernel memory consumers.
> 
> 
>>> 2. uma_dbg_alloc/uma_dbg_free use atomic operations on memory where the
>>>  cache appears to not be set to write-back. Attempting this is not
>>>  guaranteed to work. I haven't looked into this fully to see if this
>>>  is correct, but from the panic I was seeing this appears to be the
>>>  case.
>>> 
>>> I have been talking to Jeff Roberson on panic 1. As I'm nit sure if my
>>> assessment of panic 2 is correct I haven't looked at how to fix it.
>> 
>> My analysis so far:
>> busdma_bufalloc_create takes alloc/free functions as an arguments
>> and sets it as an allocator for newly created uma zone. AFAIU  uma
>> zone uses this function to allocate slab structures as well was
>> actual memory areas. The allocator function used used for "coherent"
>> busdma bufalloc allocates non-cached (write-back) memory. So
>> when debug code tries atomic access to uma_slab_t fields
>> it generates exception. Using different allocators for service
>> structures and work memory might be a solution but I do not know
>> enough about VM internals to know if it's plausible solution.
>> 
> 
> Set the zone to OFFPAGE if INVARIANTS is set and it will resolve this issue.  This will force the slab structure into a separate allocation.

Thanks Jeff. It did help. 
This patch fixed second panic for me: 
http://people.freebsd.org/~gonzo/arm/patches/armv6-invariants-panic-fix.diff
 
Of there are no objections I'll commit it tomorrow.