From owner-freebsd-arm@FreeBSD.ORG Tue Jul 2 06:52:53 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 6BF4875A for ; Tue, 2 Jul 2013 06:52:53 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) by mx1.freebsd.org (Postfix) with ESMTP id 4166619C5 for ; Tue, 2 Jul 2013 06:52:52 +0000 (UTC) Received: by mail-pd0-f177.google.com with SMTP id p10so3281302pdj.36 for ; Mon, 01 Jul 2013 23:52:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type:x-gm-message-state; bh=g9OkvtViPKQUD/A3DESVS2HcdAf9Dc3ajv9thoPD18w=; b=Jwu/IJDfeu2hftjBOQnZyR0RZUqCrTW4d93nUmz2GCYcnhG5ljOeuf1JfzLOzGBu74 NQHVpg9fcJl9sJAAqaQ+4VCiu5ZdYBFqWejZtd4rL+N7YfFGQlc0oVX42OJp9m16OFIC pxbq5eYJTQl4LMh5th0Fwj+f515d0cqkcnQXElPSjXWn3/SHsSMPF1QpjtTJYNHy1UUY giXl9NL6+VK9TCYJ5cBJHgzFhlsqfP7+67XoH5CIGzo8UxI9dyGREmdmCwUKaQZAESJ9 lK8lyK0YIMDxV9lXCvukc3NJn701nq1zeVxzZplPKpPXvjy8ldwwLe29Qb3e1WjlxBMe 7Bzg== X-Received: by 10.68.196.231 with SMTP id ip7mr27333533pbc.61.1372747972739; Mon, 01 Jul 2013 23:52:52 -0700 (PDT) Received: from rrcs-66-91-135-210.west.biz.rr.com (rrcs-66-91-135-210.west.biz.rr.com. [66.91.135.210]) by mx.google.com with ESMTPSA id ib9sm25940739pbc.43.2013.07.01.23.52.49 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 01 Jul 2013 23:52:51 -0700 (PDT) Date: Mon, 1 Jul 2013 20:54:34 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Oleksandr Tymoshenko Subject: Re: Raspberry pi not ready to self-host yet? In-Reply-To: <27399D4B-8CEF-427B-9201-A47564F7DF50@bluezbox.com> Message-ID: 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> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Gm-Message-State: ALoCoQk6eUBFfZwlu9N+OoFAQyIXkgUB6Lh+p1l2VwDZLP1oqu3as+CprZm2G29GcIJdbZaJCQHP Cc: freebsd-arm@freebsd.org, Jordan Hubbard 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: Tue, 02 Jul 2013 06:52:53 -0000 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