CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)

[Benjamin Herrenschmidt]

> I have succeeded in getting the debugger to break early on during boot.
> I have it set to break at start_here, in arch/powerpc/kernel/head_32.S.
> 
> My U-Boot bootloader indicates that the fdt is being loaded to address
> 0x7f8000, which translates to VA 0xc07f8000. See this output:
> 
>    Booting using the fdt blob at 0x2269f1c
>    Uncompressing Kernel Image ... OK
>    Loading Ramdisk to 0fea0000, end 0ff76699 ... OK
>    Loading Device Tree to 007f8000, end 007ff78f ... OK
> 
> As soon an the debugger hit the start_here breakpoint, I ran the
> following command. It should dump out the flat device tree to a file,
> which I can then analyze:
> 
> (gdb) dump memory ~/fdt.bin 0xc07f8000 0xc07ff78f
> 
> On the good kernel (CONFIG_PROVE_LOCKING=n), I get a valid device tree
> in fdt.bin. I see the stuff I would expect.
> 
> On the bad kernel (CONFIG_PROVE_LOCKING=y), I get all zeroes in fdt.bin.
> So clearly something is overwriting the fdt.
> 
> However, note that this happens *before* lockdep_init() runs. Grepping
> for CONFIG_PROVE_LOCKING in arch/powerpc and drivers/of shows nothing.
> I'm not sure exactly how this is related to lockdep.
> 
> Some more suggestions for things to try would be great. For now, I'm
> going to try getting the debugger to break near the end of U-Boot, to
> see if the memory is overwritten there, and not in Linux.

I suspect your uboot setup. The one thing lockdep does is massively
increase the amount of kernel bss. I suspect you are just overlapping DT
and bss and hence wiping out the DT when clearing the bss.

I would have expected uboot to warn (the kernel ELF header contains the
BSS size) but apparently that isn't the case.

Cheers,
Ben.