lkml.org 
[lkml]   [2011]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.39.1 immediately reboots/resets on EFI system
On 06/10/2011 04:03 PM, Matthew Garrett wrote:
> 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.

good.

>
>> 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.

that is not enough, will need to make arch/x86/boot/compressed/head_64.S parse e820 table to find right decompress position.

> The long-term fix is to perform the
> SetVirtualAddressMap transition in either the bootloader or the kernel
> entry point.

that is sane and clean workaround for those systems with buggy fw.

> 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.

that is questionable and dangerous. before SetVirtualAddressMap, some function in boot service could be called,
those data or code for boot services could be overlapped kernel. so kernel code could be damaged by those calling.

also that will make our kernel code more messy.

Yinghai


\
 
 \ /
  Last update: 2011-06-11 01:29    [from the cache]
©2003-2011 Jasper Spaans