From: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx> -------------------- 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. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
