From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Rex Feany <RFeany@mrv.com>
Cc: Scott Wood <scottwood@freescale.com>,
linuxppc-dev list <linuxppc-dev@ozlabs.org>,
"Weirich, Bernhard" <Bernhard.Weirich@riedel.net>
Subject: Re: [PATCH] powerpc/mm: Fix 40x and 8xx vs. _PAGE_SPECIAL
Date: Thu, 24 Sep 2009 11:40:34 +1000 [thread overview]
Message-ID: <1253756434.7103.377.camel@pasglop> (raw)
In-Reply-To: <20090924005300.GB11737@compile2.chatsunix.int.mrv.com>
On Wed, 2009-09-23 at 17:53 -0700, Rex Feany wrote:
> Thus spake Benjamin Herrenschmidt (benh@kernel.crashing.org):
>
> > Bernhard, Rex, please let me know if that works for you.
>
> it doesn't work for me, it crashes differently then before though!
Hrm. This is really strange...
> trunk+benh complicated patch:
>
> crashes earlier:
>
> BUG: Bad page map in process swapper pte:001f88e9 pmd:020d8001
It's complaining because for some reason a PTE ends up with
_PAGE_SPECIAL set which indeed shouldn't be the case for a stack
page which is what is being accessed in our case. However, I have
no idea how that bit ended up being set. The generic code shouldn't
be setting it, and I looked several times at the TLB miss handling
on 8xx and can't find how in hell it would inadvertently set that
bit in the PTE...
Scott, I don't have any 8xx HW, any chance you can have a look at
what's going on here ?
The other bits in there look fine. So something must be whacking
_PAGE_SPECIAL in somewhere or at least whacking 0x8 in there.
Also, _PAGE_HWWRITE isn't set, but the DataTLBError code will
set it when setting dirty, so the page must have been created
pre-dirtied or something... all very weird I must say.
> addr:7ffffff6 vm_flags:00100177 anon_vma:c20d95e0 mapping:(null) index:7ffff
> Call Trace:
> [c341fd20] [c00067d0] show_stack+0x44/0x14c (unreliable)
> [c341fd60] [c0056860] print_bad_pte+0x1b4/0x1d0
> [c341fd90] [c00568c8] vm_normal_page+0x4c/0x78
> [c341fda0] [c0056988] follow_page+0x94/0x1b8
> [c341fdc0] [c005854c] __get_user_pages+0x324/0x3c4
> [c341fe20] [c006c12c] get_arg_page+0x40/0xac
> [c341fe40] [c006c374] copy_strings+0xec/0x1d4
> [c341fe80] [c006c47c] copy_strings_kernel+0x20/0x38
> [c341fea0] [c006d3cc] do_execve+0x110/0x240
> [c341fee0] [c00070c4] sys_execve+0x50/0x7c
> [c341ff00] [c000d0dc] ret_from_syscall+0x0/0x38
> [c341ffc0] [c00023ac] init_post+0x5c/0x168
> [c341ffe0] [c01df22c] kernel_init+0x10c/0x124
> [c341fff0] [c000cf3c] kernel_thread+0x4c/0x68
>
> this is running on a MPC 875, and I'm happy to test any patches or
> add any debugging code if it helps.
>
> thanks!
> /rex
next prev parent reply other threads:[~2009-09-24 1:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-23 4:12 [PATCH] powerpc/mm: Fix 40x and 8xx vs. _PAGE_SPECIAL Benjamin Herrenschmidt
2009-09-23 6:44 ` Weirich, Bernhard
2009-09-24 0:53 ` Rex Feany
2009-09-24 1:13 ` Benjamin Herrenschmidt
2009-09-24 1:40 ` Benjamin Herrenschmidt [this message]
2009-09-24 2:38 ` Rex Feany
2009-09-24 2:53 ` 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=1253756434.7103.377.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=Bernhard.Weirich@riedel.net \
--cc=RFeany@mrv.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=scottwood@freescale.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).