Hello Christian

On 07/06/2016, Christian Zigotzky wrote:

"range.size, pgprot_val(pgprot_noncached(__pgprot(0))));" isn't the 
problem. :-) It works.

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

     Radix doesn't need slice support. Catch incorrect usage of slice
     code when radix is enabled.

     Signed-off-by: Aneesh Kumar K.V [off-list ref]
     Signed-off-by: Michael Ellerman [off-list ref]

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.

Regards
Darren