Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 1 Jul 2013 20:27:16 +0100
From:      Andrew Turner <andrew@fubar.geek.nz>
To:        Oleksandr Tymoshenko <gonzo@bluezbox.com>
Cc:        freebsd-arm@freebsd.org, Jordan Hubbard <jordan.hubbard@gmail.com>, Jeff Roberson <jroberson@jroberson.net>
Subject:   Re: Raspberry pi not ready to self-host yet?
Message-ID:  <20130701202716.264a5ac9@bender.Home>
In-Reply-To: <489E95FC-AF71-483C-BA08-81276B850B7F@bluezbox.com>
References:  <800732D1-B06A-40AE-AE69-F6170662B2AA@turbofuzz.com> <20130626235542.27844683@ivory.wynn.com> <79CFABCE-156A-44B5-B989-A3607C47B2AF@mail.turbofuzz.com> <20130627013142.5fdb2544@ivory.wynn.com> <DC57FE36-8A1B-4372-A3E8-82CCB9730FDC@turbofuzz.com> <20130627111623.137ad2ca@ivory.wynn.com> <20130627215424.GA2441@night.db.net> <463D25BB-88D6-4B2E-A7F2-05A8B0525571@gmail.com> <489E95FC-AF71-483C-BA08-81276B850B7F@bluezbox.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 1 Jul 2013 01:33:59 -0700
Oleksandr Tymoshenko <gonzo@bluezbox.com> wrote:

> 
> On 2013-07-01, at 1:14 AM, Jordan Hubbard <jordan.hubbard@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.
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.

Andrew



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130701202716.264a5ac9>