From owner-freebsd-arm@FreeBSD.ORG Sat Jul 27 20:40:40 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B5874124 for ; Sat, 27 Jul 2013 20:40:40 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7341E2429 for ; Sat, 27 Jul 2013 20:40:39 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V3BI6-000PJJ-Lv; Sat, 27 Jul 2013 20:40:38 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r6RKeYPr015261; Sat, 27 Jul 2013 14:40:34 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/Og2uFwMpNBhhbGapRQvwH Subject: Re: Raspberry pi not ready to self-host yet? From: Ian Lepore To: Oleksandr Tymoshenko In-Reply-To: <3E3F5195-514D-44BF-BA98-B821981D1149@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> <20130701202716.264a5ac9@bender.Home> <27399D4B-8CEF-427B-9201-A47564F7DF50@bluezbox.com> <3E3F5195-514D-44BF-BA98-B821981D1149@bluezbox.com> Content-Type: text/plain; charset="us-ascii" Date: Sat, 27 Jul 2013 14:40:34 -0600 Message-ID: <1374957634.45247.6.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port 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: Sat, 27 Jul 2013 20:40:40 -0000 On Tue, 2013-07-02 at 00:14 -0700, Oleksandr Tymoshenko wrote: > On 2013-07-01, at 11:54 PM, Jeff Roberson wrote: > > > On Mon, 1 Jul 2013, Oleksandr Tymoshenko wrote: > > > >> > >> On 2013-07-01, at 12:27 PM, Andrew Turner wrote: > >> > >>> 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. > > > > 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. Sorry for the long delay in this reply, I'm just coming back online after a long break from computer work. Is there a good reason to only set the OFFPAGE flag for INVARIANTS as opposed to always? I remember when I first developed that code I tried the OFFPAGE flag and it caused a crash or panic or something, so I removed it and got on with what I was doing at the moment, then I forgot to ever come back and try it again. I vaguely remember thinking at the time (without having much understanding of the uma code) that keeping metadata separate from a collection of power-of-two-sized allocatable chunks seemed like a good idea. Also, there's this for uma_zone_set_allocf() in uma.h * Discussion: * This could be used to implement pageable allocation, or perhaps * even DMA allocators if used in conjunction with the OFFPAGE * zone flag. -- Ian