linux-kernel - Re: 3.9 breaks EFI boot on E350

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 16 May 2013 14:49:42 +0200
From:	Christian König <christian.koenig@....com>
To:	Yinghai Lu <yinghai@...nel.org>
CC:	"H. Peter Anvin" <hpa@...ux.intel.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Wolfram Gloger <wg@...loc.de>
Subject: Re: 3.9 breaks EFI boot on E350

Am 16.05.2013 11:41, schrieb Christian König:
> Am 15.05.2013 22:57, schrieb Yinghai Lu:
>> On Wed, May 15, 2013 at 8:20 AM, Christian König
>> <christian.koenig@....com> wrote:
>>> Am 15.05.2013 16:46, schrieb Yinghai Lu:
>>>
>>>> On Wed, May 15, 2013 at 2:46 AM, Christian König
>>>> <christian.koenig@....com> wrote:
>>>>> Hi guys,
>>>>>
>>>>> the following commit breaks booting my E350 based test system in EFI
>>>>> mode:
>>>>>
>>>>>> commit 8d57470d8f859635deffe3919d7d4867b488b85a
>>>>>> Author: Yinghai Lu <yinghai@...nel.org>
>>>>>> Date:   Fri Nov 16 19:38:58 2012 -0800
>>>>>>
>>>>>>       x86, mm: setup page table in top-down
>>>>>
>>>>> This commit was supposed to fix it but obviously there still seem 
>>>>> to be
>>>>> some
>>>>> bugs left in 3.9
>>>>>
>>>>>> commit 98e7a989979b185f49e86ddaed2ad6890299d9f0
>>>>>> Author: Yinghai Lu <yinghai@...nel.org>
>>>>>> Date:   Wed Mar 6 20:18:21 2013 -0800
>>>>>>
>>>>>>       x86, mm: Make sure to find a 2M free block for the first 
>>>>>> mapped
>>>>>> area
>>>>>>
>>>>>>       Henrik reported that his MacAir 3.1 would not boot with
>>>>>>
>>>>>>       | commit 8d57470d8f859635deffe3919d7d4867b488b85a
>>>>>>       | Date:   Fri Nov 16 19:38:58 2012 -0800
>>>>>>       |
>>>>>>       |    x86, mm: setup page table in top-down
>>>>>>
>>>> can you send out working boot log with memory map?
>>>>
>>>> you need to boot system with "debug ignore_loglevel"
>>>
>>> Sure, dmesg output it attached. Let me know if you need anything else.
>>>
>> [    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] 
>> usable
>> [    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000006ea07fff] 
>> usable
>> [    0.000000] BIOS-e820: [mem 0x000000006ea08000-0x000000006ea55fff] 
>> reserved
>> [    0.000000] BIOS-e820: [mem 0x000000006ea56000-0x000000006f47efff] 
>> ACPI NVS
>> [    0.000000] BIOS-e820: [mem 0x000000006f47f000-0x000000006f87bfff] 
>> reserved
>> [    0.000000] BIOS-e820: [mem 0x000000006f87c000-0x000000006f87cfff] 
>> usable
>> [    0.000000] BIOS-e820: [mem 0x000000006f87d000-0x000000006f883fff] 
>> ACPI NVS
>> [    0.000000] BIOS-e820: [mem 0x000000006f884000-0x000000006fc97fff] 
>> usable
>> [    0.000000] BIOS-e820: [mem 0x000000006fc98000-0x000000006fef2fff] 
>> reserved
>> [    0.000000] BIOS-e820: [mem 0x000000006fef3000-0x000000006fefffff] 
>> usable
>> [    0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] 
>> reserved
>> [    0.000000] BIOS-e820: [mem 0x00000000fec10000-0x00000000fec10fff] 
>> reserved
>> [    0.000000] BIOS-e820: [mem 0x00000000fed00000-0x00000000fed00fff] 
>> reserved
>> [    0.000000] BIOS-e820: [mem 0x00000000fed61000-0x00000000fed70fff] 
>> reserved
>> [    0.000000] BIOS-e820: [mem 0x00000000fed80000-0x00000000fed8ffff] 
>> reserved
>> [    0.000000] BIOS-e820: [mem 0x00000000fef00000-0x00000000ffffffff] 
>> reserved
>>
>> the kernel code should handle the memmap properly. and I use user
>> memmap to simulate the
>> that memmap, kernel could boot well.
>>
>> so your system does not have serial port?
>
> Unfortunately not, this board doesn't even have an PCI slot otherwise 
> I could install a card there.
>
> Anything else I could do?
>

Ups, the board DOES have a serial port, and I've got a log now that 
shows the mentioned patch above isn't the root cause.

After commit 8d57470d8f859635deffe3919d7d4867b488b85a it indeed crashes 
very early in the boot sequence, but commit 
98e7a989979b185f49e86ddaed2ad6890299d9f0 fixes that and now it crashes 
while trying to unpack the initrd with a completely different backtrace.

Sorry for the noise, one black screen while bisecting is as good as 
another, but obviously not the same root cause.

Cheers,
Christian.

> Christian.
>
>>
>> Can you boot failed kernel on your system with "earlyprintk=ttyS0,115200
>> memblock=debug" to see
>> where is crash or hang?
>>
>


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/