On Wed, 2016-06-08 at 12:33 +0100, Darren Stevens wrote:

On 07/06/2016, Christian Zigotzky wrote:

quoted

764041e0f43cc7846f6d8eb246d65b53cc06c764 is the first bad commit
commit 764041e0f43cc7846f6d8eb246d65b53cc06c764
Author: Aneesh Kumar K.V [off-list ref]
Date:   Fri Apr 29 23:26:09 2016 +1000

     powerpc/mm/radix: Add checks in slice code to catch radix usage

That's not where I ended up with my bisect, this commit is about 10 before the
one I found to be bad, which is:

commit d6a9996e84ac4beb7713e9485f4563e100a9b03e
Author: Aneesh Kumar K.V [off-list ref]
Date:   Fri Apr 29 23:26:21 2016 +1000

    powerpc/mm: vmalloc abstraction in preparation for radix
    
    The vmalloc range differs between hash and radix config. Hence make
    VMALLOC_START and related constants a variable which will be runtime
    initialized depending on whether hash or radix mode is active.
    
    Signed-off-by: Aneesh Kumar K.V [off-list ref]
    [mpe: Fix missing init of ioremap_bot in pgtable_64.c for ppc64e]
    Signed-off-by: Michael Ellerman [off-list ref]

Not sure how we are getting different results though. I have attached my
bisect log and the suspect commit, whcih is quite large. I'm not sure which
part of it is at fault. I have some jobs to do now, but hope to get tesing
this later today.

That one is more likely to be the problem, though I don't see anything glaringly
wrong with it.

Does your patch use any of the constants that are changed in that file? They now
aren't constants, they're initialised at boot, so if you use them too early
you'll get junk.

cheers