From: john stultz <johnstul@us.ibm.com>
To: Wu Fengguang <fengguang.wu@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Xiaotian Feng <xtfeng@gmail.com>,
Sachin Sant <sachinp@in.ibm.com>, Yinghai Lu <yinghai@kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>, "x86@kernel.org" <x86@kernel.org>
Subject: Re: 2.6.33-git6 boot failure[x86_64] (WARN: at arch/x86/mm/ioremap.c:111)
Date: Mon, 1 Mar 2010 14:47:18 -0800 [thread overview]
Message-ID: <1f1b08da1003011447o104482b8j85671885fefcb518@mail.gmail.com> (raw)
In-Reply-To: <20100301135551.GA9998@localhost>
On Mon, Mar 1, 2010 at 5:55 AM, Wu Fengguang <fengguang.wu@intel.com> wrote:
> resource: fix generic page_is_ram() for partial RAM pages
>
> The System RAM walk shall skip partial RAM pages and avoid calling
> func() on them. So that page_is_ram() return 0 for a partial RAM page.
>
> In particular, it shall not call func() with len=0.
> This fixes a boot time bug reported by Sachin and root caused by Thomas:
>
>> >>> WARNING: at arch/x86/mm/ioremap.c:111 __ioremap_caller+0x169/0x2f1()
>> >>> Hardware name: BladeCenter LS21 -[79716AA]-
>> >>> Modules linked in:
>> >>> Pid: 0, comm: swapper Not tainted 2.6.33-git6-autotest #1
>> >>> Call Trace:
>> >>> [<ffffffff81047cff>] ? __ioremap_caller+0x169/0x2f1
>> >>> [<ffffffff81063b7d>] warn_slowpath_common+0x77/0xa4
>> >>> [<ffffffff81063bb9>] warn_slowpath_null+0xf/0x11
>> >>> [<ffffffff81047cff>] __ioremap_caller+0x169/0x2f1
>> >>> [<ffffffff813747a3>] ? acpi_os_map_memory+0x12/0x1b
>> >>> [<ffffffff81047f10>] ioremap_nocache+0x12/0x14
>> >>> [<ffffffff813747a3>] acpi_os_map_memory+0x12/0x1b
>> >>> [<ffffffff81282fa0>] acpi_tb_verify_table+0x29/0x5b
>> >>> [<ffffffff812827f0>] acpi_load_tables+0x39/0x15a
>> >>> [<ffffffff8191c8f8>] acpi_early_init+0x60/0xf5
>> >>> [<ffffffff818f2cad>] start_kernel+0x397/0x3a7
>> >>> [<ffffffff818f2295>] x86_64_start_reservations+0xa5/0xa9
>> >>> [<ffffffff818f237a>] x86_64_start_kernel+0xe1/0xe8
>> >>> ---[ end trace 4eaa2a86a8e2da22 ]---
>> >>> ioremap reserve_memtype failed -22
>
> The return code is -EINVAL, so it failed in the is_ram check, which is
> not too surprising
>
>> BIOS-provided physical RAM map:
>> BIOS-e820: 0000000000000000 - 000000000009c000 (usable)
>> BIOS-e820: 000000000009c000 - 00000000000a0000 (reserved)
>> BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
>> BIOS-e820: 0000000000100000 - 00000000cffa3900 (usable)
>> BIOS-e820: 00000000cffa3900 - 00000000cffa7400 (ACPI data)
>
> The ACPI data is not starting on a page boundary and neither does the
> usable RAM area end on a page boundary. Very useful !
>
>> ACPI: DSDT 00000000cffa3900 036CE (v01 IBM SERLEWIS 00001000 INTL 20060912)
>
> ACPI is trying to map DSDT at cffa3900, which results in a check
> vs. cffa3000 which is the relevant page boundary. The generic is_ram
> check correctly identifies that as RAM because it's in the usable
> resource area. The old e820 based is_ram check does not take
> overlapping resource areas into account. That's why it works.
This patch resolved the issue for me on an LS20.
thanks
-john
next prev parent reply other threads:[~2010-03-01 22:52 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-01 4:34 2.6.33-git6 boot failure[x86_64] (WARN: at arch/x86/mm/ioremap.c:111) Sachin Sant
2010-03-01 6:18 ` Xiaotian Feng
2010-03-01 8:28 ` Sachin Sant
2010-03-01 8:38 ` Xiaotian Feng
2010-03-01 10:42 ` Thomas Gleixner
2010-03-01 13:55 ` Wu Fengguang
2010-03-01 16:31 ` Thomas Gleixner
2010-03-01 18:16 ` H. Peter Anvin
2010-03-01 19:00 ` [tip:x86/mm] resource: Fix generic page_is_ram() for partial RAM pages tip-bot for Wu Fengguang
2010-03-01 23:45 ` Yinghai Lu
2010-03-09 13:12 ` Wu Fengguang
2010-03-01 22:47 ` john stultz [this message]
2010-03-02 19:33 ` [tip:x86/mm] resource: Fix broken indentation tip-bot for H. Peter Anvin
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=1f1b08da1003011447o104482b8j85671885fefcb518@mail.gmail.com \
--to=johnstul@us.ibm.com \
--cc=fengguang.wu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=sachinp@in.ibm.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=xtfeng@gmail.com \
--cc=yinghai@kernel.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;
as well as URLs for NNTP newsgroup(s).