[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55658201.5090208@linaro.org>
Date: Wed, 27 May 2015 09:36:17 +0100
From: Daniel Thompson <daniel.thompson@...aro.org>
To: Maxime Coquelin <mcoquelin.stm32@...il.com>
CC: Mike Turquette <mturquette@...aro.org>,
Stephen Boyd <sboyd@...eaurora.org>,
Rob Herring <robh+dt@...nel.org>,
Pawel Moll <pawel.moll@....com>,
Mark Rutland <mark.rutland@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Kumar Gala <galak@...eaurora.org>,
Russell King <linux@....linux.org.uk>,
Kamil Lulko <rev13@...pl>, Andreas Farber <afaerber@...e.de>,
linux-clk@...r.kernel.org,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
patches@...aro.org, linaro-kernel@...ts.linaro.org
Subject: Re: [RFC PATCH 0/3] clk: stm32: Add clock driver for STM32F4[23]xxx
devices
On 26/05/15 17:41, Maxime Coquelin wrote:
>> 2. Allocating ~80 clock components appears to fragment memory enough
>> to prevent busybox (.text is ~300K, non-XIP) from running getty.
>> I have to use "init=/bin/sh" to avoid OOM problems.
>
> Yes, I reproduced the same issue while testing your work.
>
> Could you try with:
> CONFIG_NOMMU_INITIAL_TRIM_EXCESS=0
>
> It solves (hides) the problem on my side.
> You can eventually setting it once booted to 1 via procfs.
That works for me too. Thanks.
Incidentally switching to SLOB also reduced the problem for me. It was
OK whilst I had ~20 clocks (and debugfs) but not enough for me to run
with all the clocks registered.
Daniel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists