Date: Tue, 2 Jul 2013 00:14:22 -0700 From: Oleksandr Tymoshenko <gonzo@bluezbox.com> To: Jeff Roberson <jroberson@jroberson.net> Cc: freebsd-arm@freebsd.org, Jordan Hubbard <jordan.hubbard@gmail.com> Subject: Re: Raspberry pi not ready to self-host yet? Message-ID: <3E3F5195-514D-44BF-BA98-B821981D1149@bluezbox.com> In-Reply-To: <alpine.BSF.2.00.1307012051430.95115@desktop> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2013-07-01, at 11:54 PM, Jeff Roberson <jroberson@jroberson.net> = wrote: > On Mon, 1 Jul 2013, Oleksandr Tymoshenko wrote: >=20 >>=20 >> On 2013-07-01, at 12:27 PM, Andrew Turner <andrew@fubar.geek.nz> = wrote: >>=20 >>> On Mon, 1 Jul 2013 01:33:59 -0700 >>> Oleksandr Tymoshenko <gonzo@bluezbox.com> wrote: >>>=20 >>>>=20 >>>> On 2013-07-01, at 1:14 AM, Jordan Hubbard = <jordan.hubbard@gmail.com> >>>> wrote: >>>>=20 >>>>> 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. >>>>=20 >>>> 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. >>>=20 >>> 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 =3D 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. >=20 > Zones must zero or otherwise intialize the contents prior to use. We = don't guarantee zero'd pages to all kernel memory consumers. >=20 >=20 >>> 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. >>>=20 >>> 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. >>=20 >> 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. >>=20 >=20 > 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.=20 This patch fixed second panic for me:=20 = http://people.freebsd.org/~gonzo/arm/patches/armv6-invariants-panic-fix.di= ff =20 Of there are no objections I'll commit it tomorrow.=20=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E3F5195-514D-44BF-BA98-B821981D1149>