From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+w=401wt.eu-S1754499AbYGITEA@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754499AbYGITEA (ORCPT <rfc822;w@1wt.eu>);
	Wed, 9 Jul 2008 15:04:00 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751054AbYGITDw
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 9 Jul 2008 15:03:52 -0400
Received: from gw.goop.org ([64.81.55.164]:40101 "EHLO mail.goop.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1750819AbYGITDw (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 9 Jul 2008 15:03:52 -0400
Message-ID: <48750B87.70405@goop.org>
Date: Wed, 09 Jul 2008 12:03:35 -0700
From: Jeremy Fitzhardinge <jeremy@goop.org>
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: Suresh Siddha <suresh.b.siddha@intel.com>
CC: Yinghai Lu <yhlu.kernel@gmail.com>, "mingo@elte.hu" <mingo@elte.hu>,
       "hpa@zytor.com" <hpa@zytor.com>,
       "tglx@linutronix.de" <tglx@linutronix.de>,
       "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [patch] tip/x86_64: fix e820 merge issue which broke max_pfn_mapped
References: <20080708230837.GD1678@linux-os.sc.intel.com> <86802c440807081759i3baafa9bj7e8ff544a1a78fb9@mail.gmail.com> <86802c440807081856y17eb1f1cs5647b2c2a765f429@mail.gmail.com> <20080709175621.GG1678@linux-os.sc.intel.com> <86802c440807091105g1dd8f8a0sa8220a1bfc65a79@mail.gmail.com> <4874FF58.5030800@goop.org> <20080709184405.GH1678@linux-os.sc.intel.com>
In-Reply-To: <20080709184405.GH1678@linux-os.sc.intel.com>
X-Enigmail-Version: 0.95.6
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Suresh Siddha wrote:
> On Wed, Jul 09, 2008 at 11:11:36AM -0700, Jeremy Fitzhardinge wrote:
>   
>> Yinghai Lu wrote:
>>     
>>> 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.
>>>       
>> Could my patch "x86_64: there's no need to preallocate
>> level1_fixmap_pgt" be a problem in itself?  It seems sound to me, but
>>     
>
> Yep. Reverting it made my system with 2GB memory boot fine again.
>   

Great.  Ingo, would you do the honours of shooting that patch?

>> none of my other code has any functional dependency on it; it's really
>> just cosmetic.
>>     
>
> have you test booted it before making this cosmetic change? :)
>
>   

Sure, works for me ;)

    J