Date: Sat, 27 Jul 2013 14:40:34 -0600 From: Ian Lepore <ian@FreeBSD.org> 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: <1374957634.45247.6.camel@revolution.hippie.lan> 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> <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> <20130701202716.264a5ac9@bender.Home> <27399D4B-8CEF-427B-9201-A47564F7DF50@bluezbox.com> <alpine.BSF.2.00.1307012051430.95115@desktop> <3E3F5195-514D-44BF-BA98-B821981D1149@bluezbox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2013-07-02 at 00:14 -0700, Oleksandr Tymoshenko wrote: > On 2013-07-01, at 11:54 PM, Jeff Roberson <jroberson@jroberson.net> wrote: > > > On Mon, 1 Jul 2013, Oleksandr Tymoshenko wrote: > > > >> > >> On 2013-07-01, at 12:27 PM, Andrew Turner <andrew@fubar.geek.nz> wrote: > >> > >>> 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. > > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1374957634.45247.6.camel>