Hi Darren, Many thanks for your help. I started my bisect with the following commits:
git bisect start git bisect good 8ffb4103f5e28d7e7890ed4774d8e009f253f56e git bisect bad 1a695a905c18548062509178b98bc91e67510864 (Linux 4.7-rc1) Did you start your bisect with the same bad and good commit? I will revert your bad commit and compile a new test kernel. Thanks, Christian On 08 June 2016 at 1:33 PM, Darren Stevens wrote:
Hello Christian 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 <aneesh.ku...@linux.vnet.ibm.com> Date: Fri Apr 29 23:26:21 2016 +1000 powerpc/mm: vmalloc abstraction in preparation for radixThe vmalloc range differs between hash and radix config. Hence makeVMALLOC_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 <aneesh.ku...@linux.vnet.ibm.com>[mpe: Fix missing init of ioremap_bot in pgtable_64.c for ppc64e] Signed-off-by: Michael Ellerman <m...@ellerman.id.au> 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
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
