[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAE9FiQXA4+Ubh-6QZv5bouZchR6XZjBSGwR1ox-vug01xiGveA@mail.gmail.com>
Date: Mon, 12 Mar 2012 22:39:00 -0700
From: Yinghai Lu <yinghai@...nel.org>
To: Matt Fleming <matt.fleming@...el.com>
Cc: "H. Peter Anvin" <hpa@...nel.org>, mingo@...hat.com,
mjg@...hat.com, linux-kernel@...r.kernel.org, keithp@...thp.com,
rui.zhang@...el.com, huang.ying.caritas@...il.com,
stable@...r.kernel.org, tglx@...utronix.de,
linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/urgent] x86, efi: Delete efi_ioremap() and fix
CONFIG_X86_32 oops
On Mon, Mar 12, 2012 at 5:38 AM, Matt Fleming <matt.fleming@...el.com> wrote:
> Have you tested my patch? Have you hit this bug or is it just from code
> inspection. I'm starting to feel a bit silly now because I can't see the
> problem you're describing.
from code inspection.
your new init_memory_mapping() will only map mem under max_low_pfn ?
and before that calling for x86_64, max_low_pfn is not updated to max_pfn yet.
+ max_pfn_mapped = init_memory_mapping();
#ifdef CONFIG_X86_64
if (max_pfn > max_low_pfn) {
- max_pfn_mapped = init_memory_mapping(1UL<<32,
- max_pfn<<PAGE_SHIFT);
/* can we preseve max_low_pfn ?*/
max_low_pfn = max_pfn;
}
Please do find one system with more than 4G to test the code.
Thanks
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists