From: Joshua Kinard <kumba@gentoo.org>
To: Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Ralf Baechle <ralf@linux-mips.org>
Cc: David Daney <ddaney.cavm@gmail.com>,
Linux MIPS List <linux-mips@linux-mips.org>
Subject: Re: IP27: CONFIG_TRANSPARENT_HUGEPAGE triggers bus errors
Date: Mon, 10 Nov 2014 09:22:21 -0500 [thread overview]
Message-ID: <5460CA1D.9060907@gentoo.org> (raw)
In-Reply-To: <20141110112039.GA7294@alpha.franken.de>
On 11/10/2014 06:20, Thomas Bogendoerfer wrote:
> On Mon, Nov 10, 2014 at 11:51:06AM +0100, Ralf Baechle wrote:
>> Thomas,
>>
>> can you test CONFIG_TRANSPARENT_HUGEPAGE on an IP28?
>>
>> All in all the R10000's TLB is unproblematic; my gut feeling is that
>> rather something else specific to IP27 is spoiling the broth.
>
> I'll give it a spin later today.
>
> Thomas.
Try testing with and without CONFIG_HUGETLBFS in the kernel. File systems ->
Pseudo filesystems -> HugeTLB file system support
So far, it seems adding that option in with CONFIG_TRANSPARENT_HUGEPAGE makes
both IP27 and IP30 behave. Without, I get data bus errors or segfaults on IP27
running Gentoo's "emerge" program on PAGE_SIZE_4K.
IP30 seems to be fine on an R12000 with or without that option, but I only have
a dual R12K module to test against. I've only had the R14K dual module for a
few days, and I could not reproduce the bus errors on that module, either. So
I wonder if there is something funny with the hardware on the single R14K
module, which I did get IBE's on before. And whether that will behave once
CONFIG_HUGETLBFS is in the kernel.
If so, maybe the fix is to make CONFIG_HUGETLBFS automatically selected if
CONFIG_TRANSPARENT_HUGEPAGE?
--J
next prev parent reply other threads:[~2014-11-10 14:22 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-02 10:53 IP27: CONFIG_TRANSPARENT_HUGEPAGE triggers bus errors Joshua Kinard
2014-11-03 18:52 ` David Daney
2014-11-04 1:08 ` Joshua Kinard
2014-11-04 1:23 ` David Daney
2014-11-04 1:34 ` Joshua Kinard
2014-11-04 1:43 ` David Daney
2014-11-04 5:51 ` Joshua Kinard
2014-11-05 9:07 ` Joshua Kinard
2014-11-05 10:21 ` Ralf Baechle
2014-11-05 16:09 ` Ralf Baechle
2014-11-07 10:22 ` Joshua Kinard
2014-11-07 18:30 ` David Daney
2014-11-09 0:09 ` Joshua Kinard
2014-11-10 7:04 ` Joshua Kinard
2014-11-10 10:51 ` Ralf Baechle
2014-11-10 11:20 ` Thomas Bogendoerfer
2014-11-10 14:22 ` Joshua Kinard [this message]
2014-11-10 16:55 ` David Daney
2014-11-10 17:03 ` Ralf Baechle
2014-11-10 17:29 ` David Daney
2014-11-11 11:11 ` Joshua Kinard
2014-11-10 21:30 ` Thomas Bogendoerfer
2014-11-11 7:47 ` Ralf Baechle
2014-11-11 9:24 ` Thomas Bogendoerfer
2014-11-11 9:38 ` Ralf Baechle
2014-11-10 11:22 ` Joshua Kinard
2014-11-05 13:52 ` Ralf Baechle
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=5460CA1D.9060907@gentoo.org \
--to=kumba@gentoo.org \
--cc=ddaney.cavm@gmail.com \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.org \
--cc=tsbogend@alpha.franken.de \
/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.