From owner-freebsd-arm@FreeBSD.ORG Sat Jul 27 21:15:09 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B79A1EF7 for ; Sat, 27 Jul 2013 21:15:09 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 864D9258A for ; Sat, 27 Jul 2013 21:15:09 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id bi5so4453407pad.36 for ; Sat, 27 Jul 2013 14:15:03 -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=t3DS643M857TXeZ+55NRiAzKgGo5GwZTIy6DOUTWfME=; b=JkJz+kcH6W4mam+1ow8pOHzJEbIRbHKPgZg/fEYpotiwFuGwW1/TM2ykup+lsFoTuR rg4t22Q0IeTG7yQhBV/MtasVqVdfzhCqkQBRo8qQ0kQ7NXRqs3/5nG2WiMGkgDcEUV2h 9eIrfApGoXlFilRtT24gPtYIGilx5CkF/Z947ksEBzIX3+ZGeMBuhrQukm5Bhmaohvpy elMsEe2OltZObC8gCaUbLtKgbLXwg+sMvgKfQPsfdRu/AR0/BExXY3wlP3Ia3YxOMFa5 oCX0myhBg5hA5kRzgPo0jZT4/fRSb2+n5a4rTTLJEI035QXc2LvpjI2d1INWr7Sa++yx qjmg== X-Received: by 10.68.253.161 with SMTP id ab1mr59690402pbd.76.1374959703416; Sat, 27 Jul 2013 14:15:03 -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 xe9sm67709955pbc.21.2013.07.27.14.15.01 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 27 Jul 2013 14:15:02 -0700 (PDT) Date: Sat, 27 Jul 2013 11:15:49 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Ian Lepore Subject: Re: Raspberry pi not ready to self-host yet? In-Reply-To: <1374957634.45247.6.camel@revolution.hippie.lan> 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> <3E3F5195-514D-44BF-BA98-B821981D1149@bluezbox.com> <1374957634.45247.6.camel@revolution.hippie.lan> 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: ALoCoQnTUMxUb1xTTmEVFWitli2GGVao3tE96TGh0qPL6/8Pq5QAP4Ao+2Td7u6pzCMERftLkW5r 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: Sat, 27 Jul 2013 21:15:09 -0000 On Sat, 27 Jul 2013, Ian Lepore wrote: > 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. It's just extra cost and complexity to maintain the external slab header. If the memory is of some special type then it may make sense to always use off page. > > 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 UMA attempts to achieve an upper bound on fragmentation. For small sized allocations the size wasted by the slab header is an insignificant amount of memory. If it takes up a significant amount of memory, which it may for an allocation that is half the page size, for example, it moves the header off. > > * Discussion: > * This could be used to implement pageable allocation, or perhaps > * even DMA allocators if used in conjunction with the OFFPAGE > * zone flag. > > -- Ian > > Jeff