Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756252Ab1FGATY (ORCPT ); Mon, 6 Jun 2011 20:19:24 -0400 Received: from mail-vx0-f174.google.com ([209.85.220.174]:58733 "EHLO mail-vx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753090Ab1FGATT convert rfc822-to-8bit (ORCPT ); Mon, 6 Jun 2011 20:19:19 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=HRbU03hbNy7edptPT6FDMOPhvoIIc9k+39H3gzLalyZSIHoldm6y3kh4Pq8aE6K7zC oIxv3a7XAYbojCkcC6mE69ipavJoCX32dvEx84xW7QDcXQyI7S2KHrtEM+MK/bW3W7Ve KT5LHQCuaA4HU8fLHha25yL5xMiaXoN6Eo2RQ= MIME-Version: 1.0 In-Reply-To: <4DED0394.2090000@gmail.com> References: <4CE17098.8090000@xs4all.nl> <4CE17C4B.1070305@xs4all.nl> <20101115185848.GI2583@sunsite.ms.mff.cuni.cz> <20101115191248.GY29412@tyan-ft48-01.lab.bos.redhat.com> <20101115195115.GZ29412@tyan-ft48-01.lab.bos.redhat.com> <4CE1968D.3050706@xs4all.nl> <4DE8DC16.6030308@xs4all.nl> <20110603133351.GA25130@srcf.ucam.org> <4DE8EF13.9030609@xs4all.nl> <4DECFC1C.10801@xs4all.nl> <4DED0394.2090000@gmail.com> Date: Mon, 6 Jun 2011 17:19:17 -0700 X-Google-Sender-Auth: QhNpHCGeBImqgZMfxXoHhO5IR-M Message-ID: Subject: Re: 2.6.39.1 immediately reboots/resets on EFI system From: Yinghai Lu To: Maarten Lankhorst Cc: Jim Bos , Matthew Garrett , Linux Kernel Mailing List , Greg KH , "H. Peter Anvin" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3078 Lines: 80 On Mon, Jun 6, 2011 at 9:43 AM, Maarten Lankhorst wrote: > Hi Jim, > > Op 06-06-11 18:11, Jim Bos schreef: >> On 06/06/2011 05:27 PM, Maarten Lankhorst wrote: >>> Hi Jim, >>> >>> 2011/6/3 Jim Bos : >>>> On 06/03/2011 03:33 PM, Matthew Garrett wrote: >>>>> On Fri, Jun 03, 2011 at 03:05:26PM +0200, Jim Bos wrote: >>>>>> *, >>>>>> >>>>>> Just applied 2.6.39.1 but my system: 64-bit SLackware, 8GB RAM, MSI mobo >>>>>> P67A-C45 bios V1.9. previously happily booting via EFI (nice to see >>>>>> Linux and the other OS actually NOT overwriting each others boot >>>>>> loaders!) immediately re-booted just after loading the kernel. >>>>>> >>>>>> Not even a single message is making it on the console, almost immediate >>>>>> system reset. ?As I noticed there are several EFI related patches, I >>>>>> first tried to backout the change to setup.c but that didn't help so >>>>>> backing out all the efi changes in the 2.6.39.1 patch, i.e. the files: >>>>>> ?- arch/x86/kernel/setup.c >>>>>> ?- arch/x86/platform/efi/efi.c >>>>>> ?- arch/x86/platform/efi/efi_64.c >>>>>> and sure enough system is booting on 2.6.39.1 with these changes removed. >>>>> Can you try just reverting >>>>> >>>>> "x86, efi: Retain boot service code until after switching to virtual mode" >>>>> >>>>> ? You've got 143 boot services/code regions, which is more than I'd >>>>> tested against, so I'm unsure whether we're overflowing something here. >>>>> >>>> That's seems to be the only EFI patch in 2.6.39.1 and I effectively >>>> removed by =not= applying (skipping) the parts of the 2.6.39.1 patch to >>>> above 3 files. >>>> So yes removing "x86, efi: Retain boot service code until after >>>> switching to virtual mode" indeed fixes the problem for me. >>> Does manually applying commit 9cd2b07c1 fix things for 2.6.39.1? >>> commit is: x86, efi: Consolidate EFI nx control >>> >>> There will be 1 apply ?failure, need to change the call to >>> early_mapping_set_exec in early_runtime_code_mapping_set_exec to >>> efi_set_executable. >>> >>> ~Maarten >>> >> Maarten, >> >> Yes that boots, but with the "BUG Bad page state .." as well (so would >> need you other patch). that is not right fix. >> >> Jim > So the options are applying that patch + free fix to stable, > or revert the change. Also looking at the comments of the > original patch, it seems it was changed because of Yinghai's comments: >> No, at that point memblock is not used any more. after mm_init()/mem_init() >> need to use free_bootmem_late() in free_efi_boot_services > > But that appears to have been incorrect now, seeing that > commit 774ea0bcb27f57b removed that transition free_bootmem_late() mean free early reserved pages (from memblock or bootmem) after slab is available. assume EFI in ram is not page-aligned? Thanks Yinghai Lu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/