From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Andrew Morton <akpm@osdl.org>,
hch@infradead.org, linux-mm@kvack.org,
Anton Blanchard <anton@samba.org>
Subject: Re: mapped page in prep_new_page()..
Date: Fri, 27 Feb 2004 21:38:50 +1100 [thread overview]
Message-ID: <1077878329.22925.321.camel@gaston> (raw)
In-Reply-To: <Pine.LNX.4.58.0402262305000.2563@ppc970.osdl.org>
> > > DAR: 0000005f00000008, DSISR: 0000000040000000
>
> Heh. I've had this G5 thing for a couple of weeks, I'm not very good at
> reading the oops dump either ;)
DAR is the access address for a 300 trap
> The ppc64 page fault oops thing seems to be braindead, and not even print
> out the address. Stupid. Somebody is too used to debuggers, and as a
> result users aren't helped to make good reports, hint hint..
Hehe :)
> Anyway, a little digging shows that the thing seems to be the instruction
>
> .. r3 is "struct page *" ..
> ld r10,64(r3) /* r10 is "page->pte.direct" */
>
> ...
>
> ld r0,0(r3) /* r0 is "page->flags */
> rldicl r0,r0,48,63
> cmpwi r0,0 /* PageDirect(page) ? */
>
> ... nope, direct bit not set ...
>
> ld r0,8(r10)
>
> where r10 (as per above) is 0x0000005F00000000. So the fault address
> would have been 0x0000005F00000008.
>
> The value of r3 is interesting: C000000000FFFFC0. That's _just_ under the
> 16MB mark, and the offset of the "page->pte.direct" access is 64 bytes.
> Which means that the corrupted data was at _exactly_ the 16MB mark.
>
> Now, I have no idea why, but it's an interesting - if slightly odd -
> detail.
>
> Who would write the value quadword 0x0000005F00000000 to the physical
> address 1<<24? And is that a valid "struct page *" in the first place?
> Probably.
>
> Bad pointer crapola? Or some subtle CPU bug with address arithmetic that
> crosses the 16MB border? Anton, BenH, any ideas?
I don't beleive in a subtle CPU bug... we are chasing a +/- random
corruption bug that happens not just on G5s and we think it may be
related.
Did you have slab poisoning ? I wonder if it could be a use after
free ... That or a subtle ordering issue (missing barrier somewhere)
leading to crap.
The interesting bit is that 16Mb point... If that ever happen again
let me know.
Ben.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2004-02-27 10:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-27 6:46 Linus Torvalds
2004-02-27 6:58 ` Andrew Morton
2004-02-27 7:11 ` Anton Blanchard
2004-02-27 7:21 ` Andrew Morton
2004-02-27 7:30 ` Linus Torvalds
2004-02-27 7:31 ` Anton Blanchard
2004-02-27 10:38 ` Benjamin Herrenschmidt [this message]
2004-02-27 15:32 ` Linus Torvalds
2004-02-27 15:38 ` Anton Blanchard
2004-02-27 22:06 ` 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=1077878329.22925.321.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=akpm@osdl.org \
--cc=anton@samba.org \
--cc=hch@infradead.org \
--cc=linux-mm@kvack.org \
--cc=torvalds@osdl.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