linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Michael Ellerman <michael@ellerman.id.au>
To: Sachin Sant <sachinp@in.ibm.com>
Cc: neilb@suse.de, linux-raid@vger.kernel.org, linuxppc-dev@ozlabs.org
Subject: Re: 2.6.31-rc5-git2 crash on a idle system.
Date: Thu, 06 Aug 2009 23:40:46 +1000	[thread overview]
Message-ID: <1249566046.4800.178.camel@concordia> (raw)
In-Reply-To: <4A7ADBB1.3050906@in.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]

On Thu, 2009-08-06 at 19:03 +0530, Sachin Sant wrote:
> Benjamin Herrenschmidt wrote:
> > Thanks. Since it's a memory corruption (or seems to be) however, it's
> > possible that the bisection will mislead you. IE. The culprit could be
> > somewhere else, and the commit you'll find via bisection just happens to
> > move things around in the kernel in such a way that the corruption hits
> > that code path instead of another rarely used one.
> >
> > I would suggest using printk to print out the content of memory where
> > the code appears to have been smashed at different stages during boot
> > (maybe even in the initcalls loop in init/main.c) to try to point out
> > what appears to be causing the corruption.
> >   
> By the time machine is up and running the particular memory location
> in question is already overwritten. So seems like the corruption occurs
> during the boot.
> 
> I added few printks in the initcall debug code patch. The o/p suggests
> that by the time first initicall debug message is printed the code is
> already corrupted. Further debug suggests, when start_kernel() is
> called the code at address(0xc000000000600000) is already corrupted.
> About 28 bytes of code starting from the above address is overwritten. 
> 
> I will try to add few more debug statements to find the place where
> this corruption might me happening.

Is it always the exact same pattern at the exact same address? Or does
it change and if so how?

cheers

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

  reply	other threads:[~2009-08-06 13:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-04 12:27 2.6.31-rc5-git2 crash on a idle system Sachin Sant
2009-08-04 13:43 ` 2.6.31-rc5-git2 crash [net/core/flow.c:flow_cache_new_hashrnd] Sachin Sant
2009-08-04 14:15   ` Michael Ellerman
2009-08-06 22:23     ` Benjamin Herrenschmidt
2009-08-07  2:54       ` Josh Boyer
2009-08-07  3:13         ` Benjamin Herrenschmidt
2009-08-07  3:49           ` Tony Breeds
2009-08-11  5:25       ` Sachin Sant
2009-08-04 21:27 ` 2.6.31-rc5-git2 crash on a idle system Benjamin Herrenschmidt
2009-08-05  9:17   ` Sachin Sant
2009-08-05  9:52     ` Benjamin Herrenschmidt
2009-08-06 13:33       ` Sachin Sant
2009-08-06 13:40         ` Michael Ellerman [this message]
2009-08-06 21:51         ` Benjamin Herrenschmidt

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=1249566046.4800.178.camel@concordia \
    --to=michael@ellerman.id.au \
    --cc=linux-raid@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=neilb@suse.de \
    --cc=sachinp@in.ibm.com \
    /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).