Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1758270Ab1FJXEN (ORCPT <rfc822;w@1wt.eu>);
	Fri, 10 Jun 2011 19:04:13 -0400
Received: from cavan.codon.org.uk ([93.93.128.6]:52441 "EHLO
	cavan.codon.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1758169Ab1FJXEM (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 10 Jun 2011 19:04:12 -0400
Date: Sat, 11 Jun 2011 00:03:59 +0100
From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Maarten Lankhorst <m.b.lankhorst@gmail.com>, Jim Bos <jim876@xs4all.nl>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Greg KH <gregkh@suse.de>, "H. Peter Anvin" <hpa@linux.intel.com>
Subject: Re: 2.6.39.1 immediately reboots/resets on EFI system
Message-ID: <20110610230359.GA2084@srcf.ucam.org>
References: <4DED0394.2090000@gmail.com>
 <BANLkTikVEj2Uz9N0B-kKA3GJTUWzmwz=zQ@mail.gmail.com>
 <20110607014127.GA8450@srcf.ucam.org>
 <4DED8752.5070005@kernel.org>
 <4DEDEA73.7010900@gmail.com>
 <20110610164706.GB25774@srcf.ucam.org>
 <4DF259B2.9070403@gmail.com>
 <20110610175429.GA28500@srcf.ucam.org>
 <4DF29E7E.50908@gmail.com>
 <4DF2A17E.7000103@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4DF2A17E.7000103@kernel.org>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: mjg59@cavan.codon.org.uk
X-SA-Exim-Scanned: No (on cavan.codon.org.uk); SAEximRunCond expanded to false
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1407
Lines: 32

On Fri, Jun 10, 2011 at 03:58:06PM -0700, Yinghai Lu wrote:

> the problem is : overlapping between kernel code with boot services code.

SHouldn't checking against the iomem resource map avoid that?

> now e820 table that is passed from bootloader do not include boot services code range. and also current boot/head_64.S will not
> try to find usable range for decompressed kernel ( too early )...
> 
> So solution will be:
> 1. revert Matthew Garrett's patch, because it breaking unknown good platform.

That's acceptable if we can't find a better solution.

> 2. ask vendor of system that Matthew try to fix to go back fix their firmware. otherwise user have stay with CSM with it.

This isn't an option.

The medium-term fix is to ensure that the bootloaders don't put the 
kernel on top of boot services code. The long-term fix is to perform the 
SetVirtualAddressMap transition in either the bootloader or the kernel 
entry point. But the short-term fix here is to allocate all boot 
services regions that don't overlap with the kernel. That'll fix some 
number of machines and shouldn't break any existing ones.

-- 
Matthew Garrett | mjg59@srcf.ucam.org
--
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/