From owner-freebsd-arm@FreeBSD.ORG Mon Jul 1 19:27:30 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1EAB24EC for ; Mon, 1 Jul 2013 19:27:30 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 01D891D4B for ; Mon, 1 Jul 2013 19:27:29 +0000 (UTC) Received: from bender.Home (97e76fc9.skybroadband.com [151.231.111.201]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 0AF255E1D5; Mon, 1 Jul 2013 19:27:22 +0000 (UTC) Date: Mon, 1 Jul 2013 20:27:16 +0100 From: Andrew Turner To: Oleksandr Tymoshenko 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> <20130627111623.137ad2ca@ivory.wynn.com> <20130627215424.GA2441@night.db.net> <463D25BB-88D6-4B2E-A7F2-05A8B0525571@gmail.com> <489E95FC-AF71-483C-BA08-81276B850B7F@bluezbox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, Jordan Hubbard , Jeff Roberson X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 19:27:30 -0000 On Mon, 1 Jul 2013 01:33:59 -0700 Oleksandr Tymoshenko wrote: > > On 2013-07-01, at 1:14 AM, Jordan Hubbard > 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