From: "Ira W. Snyder" <iws@ovro.caltech.edu>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
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: Thu, 9 Sep 2010 09:23:07 -0700 [thread overview]
Message-ID: <20100909162306.GA3496@ovro.caltech.edu> (raw)
In-Reply-To: <1284001096.6515.33.camel@pasglop>
On Thu, Sep 09, 2010 at 12:58:16PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2010-09-08 at 19:52 -0700, Ira W. Snyder wrote:
> >
> > I will attempt to get the debugger to stop at start_kernel. I'm having
> > trouble driving the JTAG debugger (a BDI2000). I have used Denx's
> > guide
> > [1] in the past, but the section on debugging the kernel itself is now
> > missing.
> >
> > [1] http://www.denx.de/wiki/view/DULG/DebuggingLinuxKernel
> >
> > I'll keep trying.
>
> start_kernel might be too late...
>
> You can also hack thing :-) Like in the asm, before machine_init(),
> stick something in the DABR and put a HW breakpoint with the BDI2000 on
> the Data Access exception handler to "catch" when it faults.
>
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.
Ira
next prev parent reply other threads:[~2010-09-09 16:23 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 [this message]
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
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=20100909162306.GA3496@ovro.caltech.edu \
--to=iws@ovro.caltech.edu \
--cc=benh@kernel.crashing.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.