On 07/04/2013 03:53 AM, Yves-Alexis Perez wrote:
> On jeu., 2013-07-04 at 10:37 +0200, Yves-Alexis Perez wrote:
>> On jeu., 2013-07-04 at 07:53 +0200, Luca Barbato wrote:
>>> On 07/01/2013 03:07 PM, Luca Barbato wrote:
>>>> Hopefully I will carve some time next weekend to play the restricted
>>>> bisect game.
>>>
>>> Release 3.10 apparently doesn't show the problem, I guess problem solved
>>> for me =)
>>>
>>> lu
>>>
>> I've just tried 3.10.0 with CONFIG_EFI=y and I still can't boot with
>> mem=300M.
> And to be a little more specific, and with a bit of fun, I've tryied
> “bisecting” the amount of ram needed to make a successful boot. Platform
> is a Lenovo Thinkpad x230 with 4G of ram.
> 
> mem=300M bad
> mem=4000M good
> mem=2000M bad
> mem=3000M bad
> mem=3500M good
> mem=3250M bad
> mem=3375M bad
> mem=3437M good
> mem=3406M bad
> mem=3421M bad
> mem=3429M bad
> mem=3433M good
> mem=3431M bad
> mem=3432M bad
> 
> So I'm not sure what happens at the 3433M boundary, but there's
> definitely something fishy. And 3.5G ram doesn't look like a very
> specific machine (although I can't test without artificially setting the
> memory limit (I only have one 4096M sodimm).
> 
> I'll try to git bisect between 3.8 and 3.10 and using mem=3432M when I
> have more time.
> 
> Regards,
> 
I tested with a single 2G dimm at pipacs's request. Here is what I found.

mem=unset: booted
mem=1930M: booted
mem=1929M: failed

Booted with memblock=debug and found the following :D

It looks like the uefi regions are simply higher then what the kernel
allows.  Here's a grep'd dmesg and /proc/iomem.  Maybe the kernel
shouldn't allow you to set mem= to lower then the mem that uefi actually
uses?


-- 
-- Matthew Thode (prometheanfire)