lkml.org 
[lkml]   [2009]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: linux-next: reservetop fix disables mem=

    * Hugh Dickins <hugh.dickins@tiscali.co.uk> wrote:

    > On Mon, 24 Aug 2009, Ingo Molnar wrote:
    > > * Yinghai Lu <yinghai@kernel.org> wrote:
    > > > Hugh Dickins wrote:
    > > > > I find the "mem=" boot parameter disabled in today's linux-next:
    > > > > reverting the tip commit below fixes that.
    > > > >
    > > > > Hugh
    > > > >
    > > > > From: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
    > > > > Date: Thu, 20 Aug 2009 12:23:11 +0000 (+0800)
    > > > > Subject: x86: Fix system crash when loading with "reservetop" parameter
    > > > > X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fmingo%2Flinux-2.6-x86.git;a=commitdiff_plain;h=8126dec32738421afa362114337331337b4be17f
    > > > >
    > > > > x86: Fix system crash when loading with "reservetop" parameter
    > > > >
    > > > > The system will die if the kernel is booted with "reservetop"
    > > > > parameter, in present code, parse "reservetop" parameter after
    > > > > early_ioremap_init(), and some function still use
    > > > > early_ioremap() after it.
    > > > >
    > > > > The problem is, "reservetop" parameter can modify
    > > > > 'FIXADDR_TOP', then the virtual address got by early_ioremap()
    > > > > is base on old 'FIXADDR_TOP', but the page mapping is base on
    > > > > new 'FIXADDR_TOP', it will occur page fault, and the IDT is not
    > > > > prepare yet, so, the system is dead.
    > > > >
    > > > > So, put parse_early_param() in the front of
    > > > > early_ioremap_init() in this patch.
    > > > >
    > > > > Signed-off-by: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
    > > > > Cc: yinghai@kernel.org
    > > > > Cc: Andrew Morton <akpm@linux-foundation.org>
    > > > > LKML-Reference: <4A8D402F.4080805@cn.fujitsu.com>
    > > > > Signed-off-by: Ingo Molnar <mingo@elte.hu>
    > > > > ---
    > > > >
    > > > > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
    > > > > index 63f32d2..02643cc 100644
    > > > > --- a/arch/x86/kernel/setup.c
    > > > > +++ b/arch/x86/kernel/setup.c
    > > > > @@ -711,6 +711,11 @@ void __init setup_arch(char **cmdline_p)
    > > > > printk(KERN_INFO "Command line: %s\n", boot_command_line);
    > > > > #endif
    > > > >
    > > > > + strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
    > > > > + *cmdline_p = command_line;
    > > > > +
    > > > > + parse_early_param();
    > > > > +
    > > > > /* VMI may relocate the fixmap; do this before touching ioremap area */
    > > > > vmi_init();
    > > > >
    > > > > @@ -793,11 +798,6 @@ void __init setup_arch(char **cmdline_p)
    > > > > #endif
    > > > > #endif
    > > > >
    > > > > - strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
    > > > > - *cmdline_p = command_line;
    > > > > -
    > > > > - parse_early_param();
    > > > > -
    > > > > #ifdef CONFIG_X86_64
    > > > > check_efer();
    > > > > #endif
    > > >
    > > > yes, that patch will break other built-in command too.
    > > >
    > > > need drop that patch.
    > >
    > > done. Was nervous about the patch already:
    >
    > Somehow it seems to have undropped itself, so mem= stopped working
    > again in recent mmotm/linux-next; and it looks like today the
    > undropped patch has made its way to Linus - I've not built current git
    > to check, but I think you'll find mem= is now broken there.

    I thoroughly zapped it. Do you know about any commit ID where it snuck
    in?

    Ingo


    \
     
     \ /
      Last update: 2009-09-19 19:59    [W:0.027 / U:0.108 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site