Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-03-19 Thread Jérôme de Bretagne 
Hi Ben, Hi Matt,

I can confirm as well that the latest package version 4.4.6-1 fixes
the issue on a Lenovo ThinkPad Tablet 8.

Thanks a lot,
Jérôme

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-03-10 Thread Matt Fleming 
On Wed, 09 Mar, at 10:56:07PM, Matt Fleming wrote:
> On Wed, 09 Mar, at 11:01:18PM, Alexis Murzeau wrote:
> > 
> > Indeed I get the "Could not reserve range" message, and with a kernel
> > v4.3 the physical address 0x1 contains the value 1.
> > And this patch works and make a unmodified + this patch 4.4 debian
> > kernel boots, nice well found :)
>  
> Great, thanks for testing.
> 
> > However, now a bad page state is reported in dmesg (which doesn't seem
> > to affect the kernel to me as a user but might hide something buggy) :
> > [0.030096] BUG: Bad page state in process swapper/0  pfn:0
> > [0.030100] page:ea00 count:0 mapcount:1 mapping:
> >(null) index:0x0
> > [0.030102] flags: 0x0()
> > 
> > The efi_free_boot_services function seems to expect size == 0 to not
> > free non reserved memory according to commit 7d68dc3.
> > Not sure if this bad page state is related to this patch though, but I
> > don't get this with the 4.3 kernel.
> 
> Yeah, it's definitely related to my quick and dirty patch. I'll have a
> think about how to fix it properly tomorrow morning.

Alexis, could you, and anybody else that hit this bug, please try out
the attached patch? If it works for you I'll pull it into the EFI tree
ASAP - the merge window is approaching fast. 
commit 7738188068b9
Author: Matt Fleming 
Date:   Wed Mar 9 14:34:24 2016 +

x86/efi: Allow reserving E820_RESERVED regions

Some machines place EFI regions in the zero page (physical address
0x) and we need to ensure that they're mapped into the EFI
page tables now that the kernel doesn't do it for us with
trim_bios_range().

commit 7d68dc3f1003 ("x86, efi: Do not reserve boot services regions
within reserved areas").

Reported-by: Alexis Murzeau 
Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815125
Cc: Maarten Lankhorst 
Cc: Borislav Petkov 
Cc: Ingo Molnar 
Cc: Ben Hutchings 
Signed-off-by: Matt Fleming 

diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 2326bf51978f..ae850932dd16 100644
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -164,6 +164,25 @@ efi_status_t efi_query_variable_store(u32 attributes, 
unsigned long size,
 EXPORT_SYMBOL_GPL(efi_query_variable_store);
 
 /*
+ * This function must be used to ensure we do not free already reserved
+ * regions, since that means they're owned by somebody else. Only
+ * reserve (and then free) regions:
+ *
+ * - Not within any part of the kernel
+ * - Not the bios reserved area (E820_RESERVED)
+ */
+static bool can_free_region(u64 start, u64 size)
+{
+   if (start + size > __pa_symbol(_text) && start <= __pa_symbol(_end))
+   return false;
+
+   if (!e820_all_mapped(start, start+size, E820_RAM))
+   return false;
+
+   return true;
+}
+
+/*
  * The UEFI specification makes it clear that the operating system is free to 
do
  * whatever it wants with boot services code after ExitBootServices() has been
  * called. Ignoring this recommendation a significant bunch of EFI 
implementations 
@@ -180,26 +199,50 @@ void __init efi_reserve_boot_services(void)
efi_memory_desc_t *md = p;
u64 start = md->phys_addr;
u64 size = md->num_pages << EFI_PAGE_SHIFT;
+   bool already_reserved;
 
if (md->type != EFI_BOOT_SERVICES_CODE &&
md->type != EFI_BOOT_SERVICES_DATA)
continue;
-   /* Only reserve where possible:
-* - Not within any already allocated areas
-* - Not over any memory area (really needed, if above?)
-* - Not within any part of the kernel
-* - Not the bios reserved area
-   */
-   if ((start + size > __pa_symbol(_text)
-   && start <= __pa_symbol(_end)) ||
-   !e820_all_mapped(start, start+size, E820_RAM) ||
-   memblock_is_region_reserved(start, size)) {
-   /* Could not reserve, skip it */
-   md->num_pages = 0;
-   memblock_dbg("Could not reserve boot range 
[0x%010llx-0x%010llx]\n",
-start, start+size-1);
-   } else
+
+   already_reserved = memblock_is_region_reserved(start, size);
+
+   /*
+* Because the following memblock_reserve() is paired
+* with free_bootmem_late() for this region in
+* efi_free_boot_services(), we must be extremely
+* careful not to reserve, and subsequently free,
+* critical regions of memory (like the kernel image) or
+

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-03-09 Thread Matt Fleming 
On Wed, 09 Mar, at 11:01:18PM, Alexis Murzeau wrote:
> 
> Indeed I get the "Could not reserve range" message, and with a kernel
> v4.3 the physical address 0x1 contains the value 1.
> And this patch works and make a unmodified + this patch 4.4 debian
> kernel boots, nice well found :)
 
Great, thanks for testing.

> However, now a bad page state is reported in dmesg (which doesn't seem
> to affect the kernel to me as a user but might hide something buggy) :
> [0.030096] BUG: Bad page state in process swapper/0  pfn:0
> [0.030100] page:ea00 count:0 mapcount:1 mapping:
>(null) index:0x0
> [0.030102] flags: 0x0()
> 
> The efi_free_boot_services function seems to expect size == 0 to not
> free non reserved memory according to commit 7d68dc3.
> Not sure if this bad page state is related to this patch though, but I
> don't get this with the 4.3 kernel.

Yeah, it's definitely related to my quick and dirty patch. I'll have a
think about how to fix it properly tomorrow morning.

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-03-09 Thread Jérôme de Bretagne 
Package: linux-image-4.4.0-1-amd64
Version: 4.4.4-2
Followup-For: Bug #815125

Hi,

I am facing the same issue on a Lenovo ThinkPad Tablet 8, which boots
fine with a vanilla kernel built locally (4.5-rc6).

> Please can you each reply to the bug address with the following
> details:
>
> - Does the affected system boot using the BIOS boot protocol
>   (including CSM) or UEFI boot protocol?

It boots using UEFI boot protocol.

> - If you boot with the added kernel parameter "earlyprintk=vga" or
>   "earlyprintk=serial" (and without "quiet"), do any boot messages
>   appear before the hang/reboot?  PLease send them (a photo is fine).

No, nothing more is displayed with these parameters. It never leaves
Grub screen:
Loading initial ramdisk ...

> - If it boots with UEFI, does the kernel parameter "efi=noruntime"
>   work around the problem?

Yes. The kernel boots fine with that parameter.

> - If you haven't already reported this, does the Linux 4.5-rc4 package
>   from experimental have the same problem?

Yes, same problem with the current Linux (4.5-rc7) package from experimental.

Jérôme

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-03-09 Thread Alexis Murzeau 
2016-03-08 22:48 GMT+01:00 Scott Ashcroft :
> The patch makes no difference.
> Is there anything else I can do to help figure this out?

You can use the kernel command line "earlyprintk=efi,keep". This way
the kernel will print messages to see what's going on (and maybe a
traceback in case of crash).

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-03-09 Thread Scott Ashcroft 
> Could you boot a working kernel with memblock=debug on the kernel

I'm not seeing any 'memblock: Could not reserve boot range' lines.
See attached.

Tried the patch anyway and it didn't work.

Cheers,
Scott[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 4.4.0-trunk-amd64 (debian-ker...@lists.debian.org) 
(gcc version 5.3.1 20160114 (Debian 5.3.1-6) ) #1 SMP Debian 4.4-1~exp1 
(2016-01-19)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.4.0-trunk-amd64 
root=UUID=4026c556-6239-4eb1-9fe2-3fc0a749067e ro memblock=debug
[0.00] x86/fpu: Legacy x87 FPU detected.
[0.00] x86/fpu: Using 'lazy' FPU context switches.
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0006efff] usable
[0.00] BIOS-e820: [mem 0x0006f000-0x0006] ACPI NVS
[0.00] BIOS-e820: [mem 0x0007-0x00085fff] usable
[0.00] BIOS-e820: [mem 0x00086000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1eff] usable
[0.00] BIOS-e820: [mem 0x1f00-0x1f0f] reserved
[0.00] BIOS-e820: [mem 0x1f10-0x1fff] usable
[0.00] BIOS-e820: [mem 0x2000-0x200f] reserved
[0.00] BIOS-e820: [mem 0x2010-0x7840cfff] usable
[0.00] BIOS-e820: [mem 0x7840d000-0x7860cfff] type 20
[0.00] BIOS-e820: [mem 0x7860d000-0x7910cfff] reserved
[0.00] BIOS-e820: [mem 0x7910d000-0x7920cfff] ACPI NVS
[0.00] BIOS-e820: [mem 0x7920d000-0x7924cfff] ACPI data
[0.00] BIOS-e820: [mem 0x7924d000-0x79ff] usable
[0.00] BIOS-e820: [mem 0xe00f8000-0xe00f8fff] reserved
[0.00] BIOS-e820: [mem 0xfed01000-0xfed01fff] reserved
[0.00] BIOS-e820: [mem 0xffb8-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00017fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.40 by INSYDE Corp.
[0.00] efi:  ACPI 2.0=0x7924c014  ESRT=0x787b4218  SMBIOS=0x78859000 
[0.00] esrt: Reserving ESRT space from 0x787b4218 to 
0x787b4250.
[0.00] memblock_reserve: [0x00787b4218-0x00787b424f] flags 0x0 
efi_esrt_init+0x20f/0x257
[0.00] SMBIOS 2.7 present.
[0.00] DMI: Hewlett-Packard HP Pavilion 11 x360 PC/2209, BIOS F.27 
04/01/2015
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x18 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0FFC0 mask FFFC0 write-protect
[0.00]   1 base 0FFB8 mask 8 uncachable
[0.00]   2 base 0 mask F8000 write-back
[0.00]   3 base 07C00 mask FFC00 uncachable
[0.00]   4 base 07B00 mask FFF00 uncachable
[0.00]   5 base 07AE0 mask FFFE0 uncachable
[0.00]   6 base 1 mask F8000 write-back
[0.00]   7 disabled
[0.00] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WC  UC- WT  
[0.00] e820: last_pfn = 0x7a000 max_arch_pfn = 0x4
[0.00] memblock_reserve: [0x0001f25000-0x0001f2bfff] flags 0x0 
setup_arch+0x632/0xcc6
[0.00] memblock_add: [0x001000-0x06efff] flags 0x0 
memblock_x86_fill+0x3e/0x5d
[0.00] memblock_add: [0x07-0x085fff] flags 0x0 
memblock_x86_fill+0x3e/0x5d
[0.00] memblock_add: [0x10-0x001eff] flags 0x0 
memblock_x86_fill+0x3e/0x5d
[0.00] memblock_add: [0x001f10-0x001fff] flags 0x0 
memblock_x86_fill+0x3e/0x5d
[0.00] memblock_add: [0x002010-0x007840cfff] flags 0x0 
memblock_x86_fill+0x3e/0x5d
[0.00] memblock_add: [0x007924d000-0x0079ff] flags 0x0 
memblock_x86_fill+0x3e/0x5d
[0.00] memblock_add: [0x01-0x017fff] flags 0x0 
memblock_x86_fill+0x3e/0x5d
[0.00] MEMBLOCK configuration:
[0.00]  memory size = 0xf8f44000 reserved size = 0x1e266c8
[0.00]  memory.cnt  = 0x7
[0.00]  memory[0x0] [0x001000-0x06efff], 0x6e000 
bytes flags: 0x0
[0.00]  memory[0x1] [0x07-0x085fff], 0x16000 
bytes flags: 0x0
[0.00]  memory[0x2]

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-03-09 Thread Matt Fleming 
On Wed, 09 Mar, at 01:02:44AM, Alexis Murzeau wrote:
> 
> Thanks for you suggestion.
> Unfortunately, this patch doesn't make it works, the crash still
> occurs (at the same RIP and traceback).
> 
> Using /dev/mem on a running system (with kernel 4.3), the memory
> around RIP (0xaa9462ee) is :
> aa9462d0  sub rsp,0x28
> aa9462d4  lea rdx,[rip+0x2445] # 0xaa948720
> aa9462db  mov ecx,0x4
> aa9462e0  call func_aa9447c0  ; call to ConvertPointer(4, & 0xaa948720)
> aa9462e5  mov r11,QWORD PTR [rip+0x2434] # 0xaa948720
> aa9462ec  xor eax,eax
> aa9462ee  mov BYTE PTR [r11+0x1],0x1
> aa9462f3  add rsp,0x28
> aa9462f7  ret

Interesting. This code sequence is pretty typical of runtime drivers
that have registered to be notified when SetVirtualAddressMap() is
invoked. It basically just calls ConvertPointer() and updates an
internal pointer with the new virtual address in the memory map passed
to SetVirtualAddressMap().

The first argument to ConvertPointer() isn't actually contained in the
UEFI spec (go figure). Digging around in the Tianocore source reveals
that it's EFI_INTERNAL_POINTER, which is distinct from
EFI_INTERNAL_FUNCTION (0x0002). Not all that helpful.

> The QWORD at address 0xaa948720 is 0 though on the running system.

My first reaction was: weird, 0x0 is an invalid address, and that I'd
always expect dereferencing that address would cause a page fault.

But we're dealing with physical addresses, and 0 is a compeletely
legitimate address, and in fact, contains Boot Services Code on your
machine,


[0.00] efi: mem00: [Boot Code  |   |  |  |  |  |  |   
|WB|WT|WC|UC] range=[0x-0x1000) (0MB)


Looking at the mapping for the first page between the working and
non-working kernels shows,


 ---[ User Space ]---
[Good] 0x-0x1000   4K   RW  
   GLB NX pte
[Bad]  0x-0x1000   4K   
  pte


Oops. The zero page isn't mapped at all with the new scheme, which
explains why working kernels don't fault but the new one does.

This probably used to work because trim_bios_range() inserts a mapping
for the first page into the e820 map, which is used to construct the
kernel page tables. It's that code path rather than the EFI mapping
code that allowed this to work in the past (I'm guessing).

Could you boot a working kernel with memblock=debug on the kernel
command line and look out for,

  memblock: Could not reserve boot range [0x00-0x000fff]

or similar. I'd like to confirm what's going on here. If
memblock=debug results in too much output you could simply change the
memblock_dbg() call in efi_reserve_boot_services() to a printk().

Because if this analysis is true, this patch should fix things,

---
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 2326bf51978f..7db49e975b11 100644
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -194,8 +194,6 @@ void __init efi_reserve_boot_services(void)
&& start <= __pa_symbol(_end)) ||
!e820_all_mapped(start, start+size, E820_RAM) ||
memblock_is_region_reserved(start, size)) {
-   /* Could not reserve, skip it */
-   md->num_pages = 0;
memblock_dbg("Could not reserve boot range 
[0x%010llx-0x%010llx]\n",
 start, start+size-1);
} else

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-03-08 Thread Alexis Murzeau 
2016-03-04 14:07 GMT+01:00 Matt Fleming :
>
> It must have been a herculean effort to take photos of the screen
> while the buggy kernel booted. Thank you!
>
> I'm not really seeing anything jumping out as obviously wrong apart
> from the fact that we don't have all of EFI_CONVENTIONAL_MEMORY mapped
> in the buggy kernel.
>
> Could you try this patch?
>
> ---
>
> diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
> index 49e4dd4a1f58..f5e77d240ff1 100644
> --- a/arch/x86/platform/efi/efi_64.c
> +++ b/arch/x86/platform/efi/efi_64.c
> @@ -241,15 +241,6 @@ int __init efi_setup_page_tables(unsigned long 
> pa_memmap, unsigned num_pages)
> efi_scratch.use_pgd = true;
>
> /*
> -* When making calls to the firmware everything needs to be 1:1
> -* mapped and addressable with 32-bit pointers. Map the kernel
> -* text and allocate a new stack because we can't rely on the
> -* stack pointer being < 4GB.
> -*/
> -   if (!IS_ENABLED(CONFIG_EFI_MIXED))
> -   return 0;
> -
> -   /*
>  * Map all of RAM so that we can access arguments in the 1:1
>  * mapping when making EFI runtime calls.
>  */
> @@ -268,6 +259,15 @@ int __init efi_setup_page_tables(unsigned long 
> pa_memmap, unsigned num_pages)
> }
> }
>
> +   /*
> +* When making calls to the firmware everything needs to be 1:1
> +* mapped and addressable with 32-bit pointers. Map the kernel
> +* text and allocate a new stack because we can't rely on the
> +* stack pointer being < 4GB.
> +*/
> +   if (!IS_ENABLED(CONFIG_EFI_MIXED))
> +   return 0;
> +
> page = alloc_page(GFP_KERNEL|__GFP_DMA32);
> if (!page)
> panic("Unable to allocate EFI runtime stack < 4GB\n");

Thanks for you suggestion.
Unfortunately, this patch doesn't make it works, the crash still
occurs (at the same RIP and traceback).

Using /dev/mem on a running system (with kernel 4.3), the memory
around RIP (0xaa9462ee) is :
aa9462d0  sub rsp,0x28
aa9462d4  lea rdx,[rip+0x2445] # 0xaa948720
aa9462db  mov ecx,0x4
aa9462e0  call func_aa9447c0  ; call to ConvertPointer(4, & 0xaa948720)
aa9462e5  mov r11,QWORD PTR [rip+0x2434] # 0xaa948720
aa9462ec  xor eax,eax
aa9462ee  mov BYTE PTR [r11+0x1],0x1
aa9462f3  add rsp,0x28
aa9462f7  ret

The QWORD at address 0xaa948720 is 0 though on the running system.

I will try to investigate more but I'm open to any printk / patch tests.

Alexis Murzeau

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-03-08 Thread Scott Ashcroft 
The patch makes no difference.
Is there anything else I can do to help figure this out?

Cheers,
Scott

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-03-08 Thread Scott Ashcroft 
I'm still seeing the same failure in efi_call with 4.4.4-1 and 4.5-rc4
and 4.5-rc7 from experimental on an HP x360.
It has the INSYDE Corp implementation of EFI which seems to be a common
factor. 

I'll try build the kernel with the patch suggested and test that.

Cheers,
Scott

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-03-08 Thread Stijn Segers 

Hi guys,

I can confirm the latest kernel package works:

linux-image-4.4.0-1-amd64:amd64 4.4.4-1

Boots fine here.

Thank you!

Stijn Segers

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-03-04 Thread Matt Fleming 
On Tue, 01 Mar, at 01:03:22AM, Alexis Murzeau wrote:
> 
> I've updated my additional debug code to dump all entries of virtual_map
> when calling SetVirtualAddressMap. (new diff of my changes in attachment:
> additionnal_printk_dump_SetVirtualAddressMap.diff)
> 
> I've run 3 tests with and without
> patch_x86-efi-build-our-own-page-table-structures:
> - Without the patch and with "efi=debug" kernel command line
> (attachment: dmesg_without_patch_efi_debug.txt)
> 
> - With the patch and with "efi=no_map,debug" command line (no crash)
> (attachment: dmesg_with_patch_efi_old_map_debug.txt)
> 
> - With the patch with "efi=debug earlyprintk=efi,keep" (crash but
> with logs)
> (attachment: dmesg_with_patch_efi_debug_photos.zip)
> 
> All of these tests are using kernels with CONFIG_EFI_PGT_DUMP enabled
> but "efi=no_map" seems to make efi_dump_pagetable not printing anything.
> 
> There is a difference in the page table dump, not sure if could be the
> cause of the crash:
> Without the patch (in dmesg_without_patch_efi_debug.txt):
> 0xaa20-0xaa7bf000   5884K RW  GLB x  pte
> 0xaa7bf000-0xaaabf000  3M RW  x  pte
> With the patch (in dmesg_with_patch_efi_debug_08.png in the zip file):
> 0xaa20-0xaaabf000   8956K RW  x  pte

It must have been a herculean effort to take photos of the screen
while the buggy kernel booted. Thank you!

I'm not really seeing anything jumping out as obviously wrong apart
from the fact that we don't have all of EFI_CONVENTIONAL_MEMORY mapped
in the buggy kernel.

Could you try this patch?

---

diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 49e4dd4a1f58..f5e77d240ff1 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -241,15 +241,6 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, 
unsigned num_pages)
efi_scratch.use_pgd = true;
 
/*
-* When making calls to the firmware everything needs to be 1:1
-* mapped and addressable with 32-bit pointers. Map the kernel
-* text and allocate a new stack because we can't rely on the
-* stack pointer being < 4GB.
-*/
-   if (!IS_ENABLED(CONFIG_EFI_MIXED))
-   return 0;
-
-   /*
 * Map all of RAM so that we can access arguments in the 1:1
 * mapping when making EFI runtime calls.
 */
@@ -268,6 +259,15 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, 
unsigned num_pages)
}
}
 
+   /*
+* When making calls to the firmware everything needs to be 1:1
+* mapped and addressable with 32-bit pointers. Map the kernel
+* text and allocate a new stack because we can't rely on the
+* stack pointer being < 4GB.
+*/
+   if (!IS_ENABLED(CONFIG_EFI_MIXED))
+   return 0;
+
page = alloc_page(GFP_KERNEL|__GFP_DMA32);
if (!page)
panic("Unable to allocate EFI runtime stack < 4GB\n");

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-02-29 Thread Matt Fleming 
On Mon, 29 Feb, at 09:34:55PM, Roger Shimizu wrote:
> On Mon, Feb 29, 2016 at 9:25 PM, Matt Fleming  
> wrote:
> > On Mon, 29 Feb, at 10:49:54AM, Raphael Hertzog wrote:
> >> Hello Matt and Borislav,
> >>
> >> in Debian we got a report (see below and https://bugs.debian.org/815125) 
> >> that
> >> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/commit?id=67a9108ed4313b85a9c53406d80dc1ae3f8c3e36
> >> was breaking early boot on some machines.
> >>
> >> Can you have a look at those failures?
> >>
> >
> > Can someone provide me with the list of EFI patches that were applied
> > for linux-image-4.4.0-1-amd64 that are not part of the stable kernel
> > tree for linux-4.4.y?
> 
> Debian's kernel patch is located in:
>   https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian/patches/?h=sid
> 
> and EFI related, I guess, is in:
>   
> https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian/patches/bugfix/x86?h=sid
> 
> the final "?h=sid" implies it's for sid which is currently 4.4
> the master branch is for preparing 4.5-rc now.

Thanks Roger.

OK, that rules out an error porting the feature because all the
required patches are present.

Looking at 
traceback_linux-4.4.2_with_patch_x86-efi-build-our-own-page-table-structures.jpg
from comment #164, it appears as though the firmware is trying to
access an address that isn't mapped in our new dedicated EFI page
tables while inside of SetVirtualAddressMap().

Curiously the E280 memory map describes the range covering the
faulting IP (0xaa9462ee) as "type 20" which is a bogus E820
type and a bogus EFI memory map type.

Alexis, could you boot a kernel with CONFIG_EFI_PGT_DUMP enabled,
efi=debug on the command line and upload the dmesg output? Booting
with efi=old_map,debug should be fine (so your machine won't crash).

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-02-29 Thread Roger Shimizu 
On Mon, Feb 29, 2016 at 9:25 PM, Matt Fleming  wrote:
> On Mon, 29 Feb, at 10:49:54AM, Raphael Hertzog wrote:
>> Hello Matt and Borislav,
>>
>> in Debian we got a report (see below and https://bugs.debian.org/815125) that
>> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/commit?id=67a9108ed4313b85a9c53406d80dc1ae3f8c3e36
>> was breaking early boot on some machines.
>>
>> Can you have a look at those failures?
>>
>
> Can someone provide me with the list of EFI patches that were applied
> for linux-image-4.4.0-1-amd64 that are not part of the stable kernel
> tree for linux-4.4.y?

Debian's kernel patch is located in:
  https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian/patches/?h=sid

and EFI related, I guess, is in:
  
https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian/patches/bugfix/x86?h=sid

the final "?h=sid" implies it's for sid which is currently 4.4
the master branch is for preparing 4.5-rc now.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-02-29 Thread Matt Fleming 
On Mon, 29 Feb, at 10:49:54AM, Raphael Hertzog wrote:
> Hello Matt and Borislav,
> 
> in Debian we got a report (see below and https://bugs.debian.org/815125) that
> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/commit?id=67a9108ed4313b85a9c53406d80dc1ae3f8c3e36
> was breaking early boot on some machines.
> 
> Can you have a look at those failures?
> 

Can someone provide me with the list of EFI patches that were applied
for linux-image-4.4.0-1-amd64 that are not part of the stable kernel
tree for linux-4.4.y?

The patch you referenced above isn't in Linus' tree yet and there are
a bunch of prerequisite patches required to make it work.

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-02-29 Thread Raphael Hertzog 
Hello Matt and Borislav,

in Debian we got a report (see below and https://bugs.debian.org/815125) that
https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/commit?id=67a9108ed4313b85a9c53406d80dc1ae3f8c3e36
was breaking early boot on some machines.

Can you have a look at those failures?

Cheers,

On Tue, 23 Feb 2016, Alexis Murzeau wrote:
> Hi,
> 
> I have the same traceback as Zdravko in Message #121 (NULL pointer
> dereference at RIP=0x81063682, __change_page_attr_set_clr+0x242).
> 
> If I add "efi=old_map" parameter to kernel cmdline, the kernel boots
> fine.
> 
> Also, this might help Norbert to have a traceback printed: using
> "quiet earlyprintk=efi,keep" kernel cmdline options will print only
> the traceback (so it should be faster to get the kernel to the crash
> traceback, if the cause is really a crash).
> 
> 
> After compiling several kernels, I narrowed down the crash to the
> patch "x86-efi-build-our-own-page-table-structures.patch".
> 
> Without this patch, the kernel boots fine (dmesg output in attachment
> dmesg_linux-4.4.2_[...].txt)
> 
> With this patch, I get the crash in efi_call (photo of
> "earlyprintk=efi,keep" output in attachment
> traceback_linux-4.4.2_with_patch_[...].jpg).
> 
> I also added 4 printk to add information before the crash when
> calling efi_call_phys with efi_phys.set_virtual_address_map (see also
> "additionnal_printk.diff" in attachment). (Not sure if it can help)
> 
> When I added these printk, the traceback stop at efi_call
> (__change_page_attr_set_clr isn't anymore in the traceback) but RIP
> is still the same as without these changes.
> 
> See also the traceback I get in attachment
> traceback_linux-4.4.2-3_unmodified.jpg with the current 4.4 kernel
> (version 4.4.2-3 unmodified)
> 
> Also, let me know if a new bug should be opened for this.
> 
> Thanks,
> Alexis Murzeau

> [0.00] microcode: CPU0 microcode updated early to revision 0x1c, date 
> = 2015-02-26
> [0.00] Initializing cgroup subsys cpuset
> [0.00] Initializing cgroup subsys cpu
> [0.00] Initializing cgroup subsys cpuacct
> [0.00] Linux version 4.4.2-amubtdx-custom (root@Debian2) (gcc version 
> 5.3.1 20160220 (Debian 5.3.1-9) ) #4 SMP Tue Feb 23 18:02:39 CET 2016
> [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.4.2-amubtdx-custom 
> root=UUID=be5f2ba3-ec9a-4645-8db5-eb9a6ddfd226 ro quiet crashkernel=128M@32M
> [0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
> [0.00] x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point 
> registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x04: 'AVX registers'
> [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 
> bytes, using 'standard' format.
> [0.00] x86/fpu: Using 'eager' FPU context switches.
> [0.00] e820: BIOS-provided physical RAM map:
> [0.00] BIOS-e820: [mem 0x-0x00087fff] usable
> [0.00] BIOS-e820: [mem 0x00088000-0x000b] reserved
> [0.00] BIOS-e820: [mem 0x0010-0x1fff] usable
> [0.00] BIOS-e820: [mem 0x2000-0x201f] reserved
> [0.00] BIOS-e820: [mem 0x2020-0x40003fff] usable
> [0.00] BIOS-e820: [mem 0x40004000-0x40004fff] reserved
> [0.00] BIOS-e820: [mem 0x40005000-0xa4da] usable
> [0.00] BIOS-e820: [mem 0xa4db-0xa61a] reserved
> [0.00] BIOS-e820: [mem 0xa61b-0xaa7befff] usable
> [0.00] BIOS-e820: [mem 0xaa7bf000-0xaa8adfff] type 20
> [0.00] BIOS-e820: [mem 0xaa8ae000-0xaa8aefff] reserved
> [0.00] BIOS-e820: [mem 0xaa8af000-0xaa8bcfff] type 20
> [0.00] BIOS-e820: [mem 0xaa8bd000-0xaa8bdfff] reserved
> [0.00] BIOS-e820: [mem 0xaa8be000-0xaa8c4fff] type 20
> [0.00] BIOS-e820: [mem 0xaa8c5000-0xaa8c5fff] reserved
> [0.00] BIOS-e820: [mem 0xaa8c6000-0xaa8d5fff] type 20
> [0.00] BIOS-e820: [mem 0xaa8d6000-0xaa8d6fff] reserved
> [0.00] BIOS-e820: [mem 0xaa8d7000-0xaa8f4fff] type 20
> [0.00] BIOS-e820: [mem 0xaa8f5000-0xaa937fff] reserved
> [0.00] BIOS-e820: [mem 0xaa938000-0xaa9befff] type 20
> [0.00] BIOS-e820: [mem 0xaa9bf000-0xaaebefff] reserved
> [0.00] BIOS-e820: [mem 0xaaebf000-0xaafbefff] ACPI NVS
> [0.00] BIOS-e820: [mem 0xaafbf000-0xaaffefff] ACPI 
> data
> [0.00] BIOS-e820: [mem 0xaafff000-0xaaff] usable
> [0.00] BIOS-e820: [mem 0xab00-0xaf9f] reserved
> [0.00]

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-02-28 Thread Stijn Segers 

Hi,

I would like to add this bug bit me too. I am on a Dell XPS 13 9350 
(Skylake, late 2015 model). So far, all 4.4.0 kernel packages from 
Unstable hang at boot (ie 4.4.2-1 through -3). Booting in UEFI mode, 
CSM disabled.


I had built my own kernel based on a 4.4.0 config from an earlier 
Experimental build (RC8) and updated that on every patchlevel release, 
still works fine (on 4.4.3 now).


The efi=noruntime boot argument does the trick for me; the 4.4.2 
testing package Ben uploaded however still hangs, just like the 4.5 RC4 
package from Experimental.


Can test/provide more info if needed.

Cheers

Stijn Segers

On Tue, 23 Feb 2016 20:17:03 +0100 Alexis Murzeau  
wrote:

> Hi,
>
> I have the same traceback as Zdravko in Message #121 (NULL pointer
> dereference at RIP=0x81063682, 
__change_page_attr_set_clr+0x242).

>
> If I add "efi=old_map" parameter to kernel cmdline, the kernel boots
> fine.
>
> Also, this might help Norbert to have a traceback printed: using
> "quiet earlyprintk=efi,keep" kernel cmdline options will print only
> the traceback (so it should be faster to get the kernel to the crash
> traceback, if the cause is really a crash).
>
>
> After compiling several kernels, I narrowed down the crash to the
> patch "x86-efi-build-our-own-page-table-structures.patch".
>
> Without this patch, the kernel boots fine (dmesg output in attachment
> dmesg_linux-4.4.2_[...].txt)
>
> With this patch, I get the crash in efi_call (photo of
> "earlyprintk=efi,keep" output in attachment
> traceback_linux-4.4.2_with_patch_[...].jpg).
>
> I also added 4 printk to add information before the crash when
> calling efi_call_phys with efi_phys.set_virtual_address_map (see also
> "additionnal_printk.diff" in attachment). (Not sure if it can help)
>
> When I added these printk, the traceback stop at efi_call
> (__change_page_attr_set_clr isn't anymore in the traceback) but RIP
> is still the same as without these changes.
>
> See also the traceback I get in attachment
> traceback_linux-4.4.2-3_unmodified.jpg with the current 4.4 kernel
> (version 4.4.2-3 unmodified)
>
> Also, let me know if a new bug should be opened for this.
>
> Thanks,
> Alexis Murzeau

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-02-22 Thread Norbert Preining 
unmerge 815125
found 815125 4.4.2-3
thanks

Hi Ben,

I have now tried the kernel you uploaded and it shows the same
problems, so it seems related to something else.

When I add earlyprintk=efi,keep it boots extremely slow, see this
little (6sec) video
https://www.dropbox.com/s/9axz9s7afi0oqbv/booting-macpro.mp4?dl=0

It stops at the same place as before, so please see the previously
attached screenshots.

Thanks

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-02-21 Thread Ben Hutchings 
On Sun, 2016-02-21 at 08:40 +0100, Mateusz Kaduk wrote:
> Hi Ben,
[...]
> > - If you haven't already reported this, does the Linux 4.5-rc4 package
> >   from experimental have the same problem?
> > 
> 
> I am using 4.5.0-rc4-amd64 from experimental at the moment as that boots
> without issues.
> Only 4.4.0 seems to be affected.
> 
> > This test version is now available at
> > https://people.debian.org/~benh/packages/unstable/
> 
> 
> > Please report back whether this does or doesn't fix the problem for
> > you. 
> 
> I installed 4.4.2-3~a.test and it replaced previous 4.4.x package, but
> system is not booting either.
> 
> Let me know if you need anything.

It sounds like this is a slightly different bug; please open a new bug report.

Ben.

-- 
Ben Hutchings
Time is nature's way of making sure that everything doesn't happen at once.

signature.asc
Description: This is a digitally signed message part

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-02-21 Thread Vincent Bernat 
 ❦ 21 février 2016 03:45 GMT, Ben Hutchings  :

>> Apparently "earlyprintk=efi,keep" is likely to work better.  Jim Barber
>> was able to get a traceback this way.
>> 
>> It looks like the efi-bgrt driver is crashing, and there is an upstream
>> fix for it.  I'll upload a test version of the package shortly.
>
> This test version is now available at
> https://people.debian.org/~benh/packages/unstable/
>
> Please report back whether this does or doesn't fix the problem for
> you.

It works fine for me. Thanks!
-- 
Make sure special cases are truly special.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-02-21 Thread Guy Durrieu 

Le 21/02/2016 04:45, Ben Hutchings a écrit :

 Hi Ben !

This test version is now available at
https://people.debian.org/~benh/packages/unstable/

Please report back whether this does or doesn't fix the problem for
you.

Ben.



It works for me.

Thanks !

Regards.

-- GD.

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-02-21 Thread Alexander Clouter 

On Sun, Feb 21, 2016 at 03:45:24AM +, Ben Hutchings wrote:

Apparently "earlyprintk=efi,keep" is likely to work better.  Jim Barber
was able to get a traceback this way.

It looks like the efi-bgrt driver is crashing, and there is an upstream
fix for it.  I'll upload a test version of the package shortly.


This test version is now available at
https://people.debian.org/~benh/packages/unstable/

Please report back whether this does or doesn't fix the problem for
you.


Works for Me(tm)

Thanks

--
Alexander Clouter
.sigmonster says: Excellent day to have a rotten day.

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-02-20 Thread Mateusz Kaduk 
Hi Ben,


> - Does the affected system boot using the BIOS boot protocol
>   (including CSM) or UEFI boot protocol?
>

I have grub-efi-amd64 installed so I believe I am using UEFI.


> - If you boot with the added kernel parameter "earlyprintk=vga" or
>   "earlyprintk=serial" (and without "quiet"), do any boot messages
>   appear before the hang/reboot?  PLease send them (a photo is fine).
>
>
After adding earlyprintk=efi,keep in the attached photo you can see error
about ACPI


> - If it boots with UEFI, does the kernel parameter "efi=noruntime"
>   work around the problem?
>

Yes that fixes the problem.


>
> - If you haven't already reported this, does the Linux 4.5-rc4 package
>   from experimental have the same problem?
>

I am using 4.5.0-rc4-amd64 from experimental at the moment as that boots
without issues.
Only 4.4.0 seems to be affected.

> This test version is now available at
> https://people.debian.org/~benh/packages/unstable/


> Please report back whether this does or doesn't fix the problem for
> you. 

I installed 4.4.2-3~a.test and it replaced previous 4.4.x package, but
system is not booting either.

Let me know if you need anything.

/Mateusz

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-02-20 Thread Jim Barber 
From: Ben Hutchings [b...@decadent.org.uk]
> 
> This test version is now available at
> https://people.debian.org/~benh/packages/unstable/
> 
> Please report back whether this does or doesn't fix the problem for
> you.

Hi Ben.

The test kernel boots up okay for me:

jim@perlap1308:~$ uname -a
Linux perlap1308 4.4.0-1-amd64 #1 SMP Debian 4.4.2-3~a.test 
(2016-02-20) x86_64 GNU/Linux

Thanks.

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-02-20 Thread Ben Hutchings 
On Sat, 2016-02-20 at 23:33 +, Ben Hutchings wrote:
> On Sat, 2016-02-20 at 17:43 +, Ben Hutchings wrote:
> > I apologise for this regression, which of course didn't affect any of
> > the several machines I was able to test on.
> > 
> > Please can you each reply to the bug address with the following
> > details:
> > 
> > - Does the affected system boot using the BIOS boot protocol
> >   (including CSM) or UEFI boot protocol?
> > 
> > - If you boot with the added kernel parameter "earlyprintk=vga" or
> >   "earlyprintk=serial" (and without "quiet"), do any boot messages
> >   appear before the hang/reboot?  PLease send them (a photo is fine).
> 
> Apparently "earlyprintk=efi,keep" is likely to work better.  Jim Barber
> was able to get a traceback this way.
> 
> It looks like the efi-bgrt driver is crashing, and there is an upstream
> fix for it.  I'll upload a test version of the package shortly.

This test version is now available at
https://people.debian.org/~benh/packages/unstable/

Please report back whether this does or doesn't fix the problem for
you.

Ben.

-- 
Ben Hutchings
Time is nature's way of making sure that everything doesn't happen at once.

signature.asc
Description: This is a digitally signed message part

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-02-20 Thread Ben Hutchings 
On Sat, 2016-02-20 at 17:43 +, Ben Hutchings wrote:
> I apologise for this regression, which of course didn't affect any of
> the several machines I was able to test on.
> 
> Please can you each reply to the bug address with the following
> details:
> 
> - Does the affected system boot using the BIOS boot protocol
>   (including CSM) or UEFI boot protocol?
> 
> - If you boot with the added kernel parameter "earlyprintk=vga" or
>   "earlyprintk=serial" (and without "quiet"), do any boot messages
>   appear before the hang/reboot?  PLease send them (a photo is fine).

Apparently "earlyprintk=efi,keep" is likely to work better.  Jim Barber
was able to get a traceback this way.

It looks like the efi-bgrt driver is crashing, and there is an upstream
fix for it.  I'll upload a test version of the package shortly.

However, if you see a traceback where the IP is *not* shown as being in
"efi_bgrt_init", please report that.

Ben.

> - If it boots with UEFI, does the kernel parameter "efi=noruntime"
>   work around the problem?
> 
> - If you haven't already reported this, does the Linux 4.5-rc4 package
>   from experimental have the same problem?

-- 
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.

signature.asc
Description: This is a digitally signed message part

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-02-20 Thread Ben Hutchings 
On Sat, 2016-02-20 at 23:05 +, Jim Barber wrote:
[...]
> I also tried booting with the kernel parameter "earlyprintk=efi,keep" that I 
> saw
> someone used in one of the merged bug reports.

Ah, good thinking, I didn't expect that would work.

> This outputs messages, but was extremely slow to scroll each line :)
> However it shows the crash I think, so I have attached a photo.
> Unfortunately it is tiny text rendered on a Hi-DPI display,
> taken with a poor quality phone camera, but seems readable when zoomed up.
[...]

This is very useful, thanks.

Ben.

-- 
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.

signature.asc
Description: This is a digitally signed message part

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-02-20 Thread Guy Durrieu 

Le 20/02/2016 18:43, Ben Hutchings a écrit :

Hi Ben. Thanks for your answer !

I apologise for this regression, which of course didn't affect any of
the several machines I was able to test on.

Please can you each reply to the bug address with the following
details:

- Does the affected system boot using the BIOS boot protocol
   (including CSM) or UEFI boot protocol?

My system boots using the UEFI boot protocol.

- If you boot with the added kernel parameter "earlyprintk=vga" or
   "earlyprintk=serial" (and without "quiet"), do any boot messages
   appear before the hang/reboot?  PLease send them (a photo is fine).

No boot message at all. Same result as previously.

- If it boots with UEFI, does the kernel parameter "efi=noruntime"
   work around the problem?

Yes, it does. The system boots normally.

- If you haven't already reported this, does the Linux 4.5-rc4 package
   from experimental have the same problem?

Hangs same way. But also starts normally using "efi=noruntime".

Ben.

Regards.

-- GD.

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-02-20 Thread Zdravko Yanakiev 
On 20.02.2016 18:43, Ben Hutchings wrote:
> - Does the affected system boot using the BIOS boot protocol
>   (including CSM) or UEFI boot protocol?

The system uses UEFI without Secure Boot or legacy compatibility features.

> - If you boot with the added kernel parameter "earlyprintk=vga" or
>   "earlyprintk=serial" (and without "quiet"), do any boot messages
>   appear before the hang/reboot?  PLease send them (a photo is fine).

No helpful information is printed with either of these parameters, only
a line saying "Booting a command list..." appears.

> - If it boots with UEFI, does the kernel parameter "efi=noruntime"
>   work around the problem?

Yes, this parameter fixes the problem for me. The kernel boots fine and
the system works as usual.

> - If you haven't already reported this, does the Linux 4.5-rc4 package
>   from experimental have the same problem?

Yes, the same thing happens using the kernel from
linux-image-4.5.0-rc4-amd64.





signature.asc
Description: OpenPGP digital signature

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-02-20 Thread Yves-Alexis Perez 
On sam., 2016-02-20 at 17:43 +, Ben Hutchings wrote:
> I apologise for this regression, which of course didn't affect any of
> the several machines I was able to test on.

Hi Ben, no issue, that's why it's called “unstable” :)
> 
> Please can you each reply to the bug address with the following
> details:
> 
> - Does the affected system boot using the BIOS boot protocol
>   (including CSM) or UEFI boot protocol?

UEFI, no CSM.
> 
> - If you boot with the added kernel parameter "earlyprintk=vga" or
>   "earlyprintk=serial" (and without "quiet"), do any boot messages
>   appear before the hang/reboot?  PLease send them (a photo is fine).

Nothing
> 
> - If it boots with UEFI, does the kernel parameter "efi=noruntime"
>   work around the problem?

It does. Anything you want from that boot?
> 
> - If you haven't already reported this, does the Linux 4.5-rc4 package
>   from experimental have the same problem?

Same thing happens.

Regards,
-- 
Yves-Alexis



signature.asc
Description: This is a digitally signed message part

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-02-20 Thread Vincent Bernat 
 ❦ 20 février 2016 17:43 GMT, Ben Hutchings  :

> I apologise for this regression, which of course didn't affect any of
> the several machines I was able to test on.

No problem. That's what unstable is for!

> Please can you each reply to the bug address with the following
> details:
>
> - Does the affected system boot using the BIOS boot protocol
>   (including CSM) or UEFI boot protocol?

Dunno what CSM is, but boot UEFI without compat mode.

> - If you boot with the added kernel parameter "earlyprintk=vga" or
>   "earlyprintk=serial" (and without "quiet"), do any boot messages
>   appear before the hang/reboot?  PLease send them (a photo is fine).

Yep, same problem with earlyprintk=vga.

It never leaves the Grub screen:

Loading initial ramdisk ...
_

And that's all.

> - If it boots with UEFI, does the kernel parameter "efi=noruntime"
>   work around the problem?

Yes. The kernel boots.

> - If you haven't already reported this, does the Linux 4.5-rc4 package
>   from experimental have the same problem?

Yep, same problem with this one.
-- 
Avoid unnecessary branches.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#815125: Boot failure with Debian linux 4.4.2 package

2016-02-20 Thread Ben Hutchings 
I apologise for this regression, which of course didn't affect any of
the several machines I was able to test on.

Please can you each reply to the bug address with the following
details:

- Does the affected system boot using the BIOS boot protocol
  (including CSM) or UEFI boot protocol?

- If you boot with the added kernel parameter "earlyprintk=vga" or
  "earlyprintk=serial" (and without "quiet"), do any boot messages
  appear before the hang/reboot?  PLease send them (a photo is fine).

- If it boots with UEFI, does the kernel parameter "efi=noruntime"
  work around the problem?

- If you haven't already reported this, does the Linux 4.5-rc4 package
  from experimental have the same problem?

Ben.

-- 
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.


signature.asc
Description: This is a digitally signed message part