From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: "Ira W. Snyder" <iws@ovro.caltech.edu>
Cc: peterz@infradead.org, mingo@redhat.com, linuxppc-dev@lists.ozlabs.org
Subject: Re: CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?)
Date: Fri, 10 Sep 2010 07:58:54 +1000 [thread overview]
Message-ID: <1284069534.6515.36.camel@pasglop> (raw)
In-Reply-To: <20100909162306.GA3496@ovro.caltech.edu>
> 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.
next prev parent reply other threads:[~2010-09-09 21:59 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-08 23:21 CONFIG_PROVE_LOCKING broken on 83xx (and all of powerpc?) Ira W. Snyder
2010-09-09 1:02 ` Benjamin Herrenschmidt
2010-09-09 2:52 ` Ira W. Snyder
2010-09-09 2:58 ` Benjamin Herrenschmidt
2010-09-09 16:23 ` Ira W. Snyder
2010-09-09 18:44 ` Ira W. Snyder
2010-09-09 19:10 ` Timur Tabi
2010-09-09 19:36 ` Ira W. Snyder
2010-09-09 19:40 ` Timur Tabi
2010-09-09 20:06 ` Ira W. Snyder
2010-09-09 20:13 ` Timur Tabi
2010-09-09 20:31 ` Ira W. Snyder
2010-09-09 20:36 ` Timur Tabi
2010-09-09 20:55 ` Ira W. Snyder
2010-09-09 21:19 ` Timur Tabi
2010-09-09 22:01 ` Benjamin Herrenschmidt
2010-09-09 19:33 ` Ira W. Snyder
2010-09-09 21:58 ` Benjamin Herrenschmidt [this message]
2010-09-09 22:11 ` Scott Wood
2010-09-09 22:13 ` Benjamin Herrenschmidt
2010-09-09 22:16 ` Benjamin Herrenschmidt
2010-09-09 22:37 ` Scott Wood
2010-09-09 22:49 ` Benjamin Herrenschmidt
2010-09-10 11:29 ` Wolfgang Denk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1284069534.6515.36.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=iws@ovro.caltech.edu \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).