[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <86802c440807091105g1dd8f8a0sa8220a1bfc65a79@mail.gmail.com>
Date: Wed, 9 Jul 2008 11:05:46 -0700
From: "Yinghai Lu" <yhlu.kernel@...il.com>
To: "Suresh Siddha" <suresh.b.siddha@...el.com>,
"Jeremy Fitzhardinge" <jeremy@...p.org>
Cc: "mingo@...e.hu" <mingo@...e.hu>, "hpa@...or.com" <hpa@...or.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [patch] tip/x86_64: fix e820 merge issue which broke max_pfn_mapped
On Wed, Jul 9, 2008 at 10:56 AM, Suresh Siddha
<suresh.b.siddha@...el.com> wrote:
> On Tue, Jul 08, 2008 at 06:56:38PM -0700, Yinghai Lu wrote:
>> On Tue, Jul 8, 2008 at 5:59 PM, Yinghai Lu <yhlu.kernel@...il.com> wrote:
>> > On Tue, Jul 8, 2008 at 4:08 PM, Suresh Siddha <suresh.b.siddha@...el.com> wrote:
>> >> With out this 64bit tip/master doesn't boot using ACPI on my system.
>> >> ---
>> >>
>> >> max_pfn_mapped should include all e820 entries.
>> >> The direct mapping extends to max_pfn_mapped, so that we can directly access
>> >> apertures, ACPI and other tables without having to play with fixmaps.
>> >>
>> >> With this, my system with 1GB memory boots fine with ACPI enabled.
>> >
>> > so without this patch, your system doesn't boot?
>>
>> how about attached patch?
>>
>> [PATCH] x86: make max_pfn cover acpi table below 4g
>>
>> when system have 4g less ram installed, and acpi table sit
>> near end of ram. make max_pfn cover them too.
>> so 64bit kernel don't need to mess up fixmap
>
> Now the latest 64bit x86 tip/master (latest commit d1f7cb8) doesn't boot
> on any of my test systems :( It gets a very early exception..
fix one panic on Ingo's machine
>
> I can't even revert your max_pfn patch, to see if this early exception is
> caused by this patch.. There seems to be more changes on top of it
> already overnight...
>
> BTW, please explain the need for your patch which has more changes, instead
> of my simple patch which was test booted on 3 different systems with both
> 32bit and 64bit kernels...
try to reduce #ifdef CONFIG_X86_64/32, and make 32/64 at the same page.
could be some regression from early_io_remap unifying from jeremy
please check attached revert patch.
YH
YH
View attachment "revert_unify_early_ioremap.patch" of type "text/x-patch" (6649 bytes)
Powered by blists - more mailing lists