From: Andrea Arcangeli <aarcange@redhat.com>
To: Minchan Kim <minchan.kim@gmail.com>
Cc: linux-mm <linux-mm@kvack.org>
Subject: Re: [BUG]thp: BUG at mm/huge_memory.c:1350
Date: Thu, 20 Jan 2011 17:14:36 +0100 [thread overview]
Message-ID: <20110120161436.GB21494@random.random> (raw)
In-Reply-To: <20110120154935.GA1760@barrios-desktop>
Hello Minchan,
On Fri, Jan 21, 2011 at 12:49:35AM +0900, Minchan Kim wrote:
> Hi Andrea,
>
> I hit thg BUG 2 time during 5 booting.
> I applied khugepaged: fix pte_unmap for highpte x86_32 based on 2.6.38-rc1.
This is again 32bit which rings a bell because clearly it didn't have
a whole lot of testing (not remotely comparable to the amount of
testing x86-64 had), but it's not necessarily 32bit related. It still
would be worth to know if it still happens after you disable
CONFIG_HIGHMEM (to rule out 32bit issues in not well tested kmaps).
The rmap walk simply didn't find an hugepmd pointing to the page. Or
the mapcount was left pinned after the page got somehow unmapped.
I wonder why pages are added to swap and the system is so low on
memory during boot. How much memory do you have in the 32bit system?
Do you boot with something like mem=256m? This is also the Xorg
process, which is a bit more special than most and it may have device
drivers attached to the pages.
One critical thing is that split_huge_page must be called when
splitting vmas, see split_huge_page_address and
__vma_adjust_trans_huge, right now it's called from vma_adjust
only. If anything is wrong in that function, or if any place adjusting
the vma is not covered by that function, it may result in exactly the
problem you run into. If drivers are mangling over the vmas that would
also explain it.
If you happen to have crash dump with vmlinux that would be the best
debug option for this, also if you can reproduce it in a VM that will
make it easier to reproduce without your hardware. Otherwise we'll
find another way.
Thanks a lot,
Andrea
--
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/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-01-20 16:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-20 15:49 [BUG]thp: BUG at mm/huge_memory.c:1350 Minchan Kim
2011-01-20 16:14 ` Andrea Arcangeli [this message]
2011-01-20 16:41 ` Minchan Kim
2011-01-21 17:58 ` Minchan Kim
2011-01-21 18:14 ` Andrea Arcangeli
2011-01-22 0:59 ` Minchan Kim
2011-01-22 1:08 ` Andrea Arcangeli
2011-01-22 2:16 ` Andrea Arcangeli
2011-01-22 2:20 ` Minchan Kim
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=20110120161436.GB21494@random.random \
--to=aarcange@redhat.com \
--cc=linux-mm@kvack.org \
--cc=minchan.kim@gmail.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).