Re: LMB bits

[David Miller <davem@davemloft.net>]

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Sat, 10 Jul 2010 21:01:59 +1000

> On Fri, 2010-07-09 at 20:55 -0700, David Miller wrote:
>> A quick update, I'm still chipping away to find the culprit,
>> I know so far that things are ok at least 14 patches into the
>> series.
>> 
>> I'll work more to try and track down the exact problem tomorrow. 
> 
> Thanks Dave !

The first guilty commit seems to be:

--------------------
From 869146ec57f449a5dd4bb5d939361841f4f7f3c6 Mon Sep 17 00:00:00 2001
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Tue, 6 Jul 2010 15:39:08 -0700
Subject: [PATCH 01/12] memblock: Make memblock_find_region() out of memblock_alloc_region()

This function will be used to locate a free area to put the new memblock
arrays when attempting to resize them. memblock_alloc_region() is gone,
the two callsites now call memblock_add_region().

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
--------------------

I wonder if there is some subtle way you've changed behavior here?
Previously if alloc block fails to do the add, it continues and
keeps trying.

Whereas now this add call happens a level higher and it's immediately
signalled as a hard failure.

Oh I see, your conversion of membase_alloc_nid_region() is buggy.
Instead of passing in "ret" as the base address to memblock_add_region(),
you're passing in the original value, "start".

The other conversion was done correctly, which is why you didn't see
this problem obviously :)

I'll make this fix and see how much further I can get.

> To save you that burden in the future, do you know if there's a sparc64
> box somewhere I can access to do tests ? Or an emulator maybe ?

Contact me on IRC sometime and I'll try to set you up with a machine
you can easily remotely reboot, power-on, and power-off to test
kernels on.