Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 06 Mar 2017 09:41:31 -0700
From:      Ian Lepore <ian@freebsd.org>
To:        bob prohaska <fbsd@www.zefox.net>, Ralf Wenk <iz-rpi03@hs-karlsruhe.de>
Cc:        freebsd-arm@freebsd.org
Subject:   Re: Booting an old kernel on RPI2
Message-ID:  <1488818491.18764.21.camel@freebsd.org>
In-Reply-To: <20170306163005.GB19195@www.zefox.net>
References:  <20170304165740.GA9625@www.zefox.net> <E1ckory-004k8U-Sq@smtp.hs-karlsruhe.de> <20170306163005.GB19195@www.zefox.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2017-03-06 at 08:30 -0800, bob prohaska wrote:
> On Mon, Mar 06, 2017 at 10:23:54AM +0100, Ralf Wenk wrote:
> > 
> > 
> > I am having the same problem here.
> > It happened during make installworld of r314701. I run make
> > installworld
> > while the former kernel r313407  was still active.
> > Now both kernels will boot up, but produce the same "out of memory"
> > message while going to single- or multi-user.
> > So it is not even possible to get a working shell in single-user
> > mode.
> > As it first happens during make installworld while still running
> > the
> > "old" r313407 kernel I think the cause is not the kernel itself.
> > 
> > 
> As I understand it, sometime before the FreeBSD loader starts up a
> division of memory is made between GPU and CPU. There is a config.txt
> file containing gpu_mem=64 on my FreeBSD systems, but some of the
> Linux literature mentions a file called uEnv.txt, which FreeBSD 
> seems not to use (nor does Raspbian, far as I can see). 
> 
> I wonder if there might be a u-boot command to
> check if the setup routines have become corrupted, leaving too
> little memory for the kernel to function, even though it reports
> real memory  = 989851648 (943 MB)
> avail memory = 957444096 (913 MB)
> during the failed boot attempts.
> 
> 
> Thanks for reading, and any ideas!
> 
> bob prohaska
> 

I'm pretty sure this out of memory error has nothing to do with the
kernel at all.  It appears to be caused by clang 4.0 building the world
incorrectly (most likely just jemalloc).

It's a pity that both clang and jemalloc were updated to new versions
within a few days of each other.

It's even more of a pity that a series of other errors make it almost
impossible to cross-build for arm from a stable-10 amd64 system after
r313403, so that bisecting to find the exact point of the error is also
almost impossible.  The problem with crossbuilding isn't fixed yet,
(it's got something to do with libnetbsd and libmd bootstrapping), so
it's hard to even look into this out of memory problem unless you have
a stable-11 system to crossbuild on.

-- Ian



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1488818491.18764.21.camel>