linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yinghai Lu <yinghai@kernel.org>
To: mingo@redhat.com, hpa@zytor.com, linux-kernel@vger.kernel.org,
	sachinp@in.ibm.com, tglx@linutronix.de, fengguang.wu@intel.com,
	kamezawa.hiroyu@jp.fujitsu.com
Cc: linux-tip-commits@vger.kernel.org
Subject: Re: [tip:x86/mm] resource: Fix generic page_is_ram() for partial RAM pages
Date: Mon, 01 Mar 2010 15:45:39 -0800	[thread overview]
Message-ID: <4B8C51A3.8020307@kernel.org> (raw)
In-Reply-To: <tip-37b99dd5372cff42f83210c280f314f10f99138e@git.kernel.org>

On 03/01/2010 11:00 AM, tip-bot for Wu Fengguang wrote:
> Commit-ID:  37b99dd5372cff42f83210c280f314f10f99138e
> Gitweb:     http://git.kernel.org/tip/37b99dd5372cff42f83210c280f314f10f99138e
> Author:     Wu Fengguang <fengguang.wu@intel.com>
> AuthorDate: Mon, 1 Mar 2010 21:55:51 +0800
> Committer:  H. Peter Anvin <hpa@zytor.com>
> CommitDate: Mon, 1 Mar 2010 10:18:32 -0800
> 
> 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.
> 
> CC: Sachin Sant <sachinp@in.ibm.com>
> CC: Thomas Gleixner <tglx@linutronix.de>
> CC: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
> LKML-Reference: <20100301135551.GA9998@localhost>
> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
> ---
>  kernel/resource.c |    9 +++++----
>  1 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/kernel/resource.c b/kernel/resource.c
> index 03c897f..8f0e3d0 100644
> --- a/kernel/resource.c
> +++ b/kernel/resource.c
> @@ -274,7 +274,7 @@ int walk_system_ram_range(unsigned long start_pfn, unsigned long nr_pages,
>  		void *arg, int (*func)(unsigned long, unsigned long, void *))
>  {
>  	struct resource res;
> -	unsigned long pfn, len;
> +	unsigned long pfn, end_pfn;
>  	u64 orig_end;
>  	int ret = -1;
>  
> @@ -284,9 +284,10 @@ int walk_system_ram_range(unsigned long start_pfn, unsigned long nr_pages,
>  	orig_end = res.end;
>  	while ((res.start < res.end) &&
>  		(find_next_system_ram(&res, "System RAM") >= 0)) {
> -		pfn = (unsigned long)(res.start >> PAGE_SHIFT);
> -		len = (unsigned long)((res.end + 1 - res.start) >> PAGE_SHIFT);
> -		ret = (*func)(pfn, len, arg);
> +		pfn = (res.start + PAGE_SIZE - 1) >> PAGE_SHIFT;
> +		end_pfn = (res.end + 1) >> PAGE_SHIFT;
> +		if (end_pfn > pfn)
> +		    ret = (*func)(pfn, end_pfn - pfn, arg);
>  		if (ret)
>  			break;
>  		res.start = res.end + 1;
> --

wonder if we should trim the ram earlier.

YH

  reply	other threads:[~2010-03-01 23:47 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 [this message]
2010-03-09 13:12               ` Wu Fengguang
2010-03-01 22:47           ` 2.6.33-git6 boot failure[x86_64] (WARN: at arch/x86/mm/ioremap.c:111) john stultz
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=4B8C51A3.8020307@kernel.org \
    --to=yinghai@kernel.org \
    --cc=fengguang.wu@intel.com \
    --cc=hpa@zytor.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=sachinp@in.ibm.com \
    --cc=tglx@linutronix.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 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).