Bug#815125: Boot failure with Debian linux 4.4.2 package

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

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

Bug#815125: Boot failure with Debian linux 4.4.2 package

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,

Bug#815125: Boot failure with Debian linux 4.4.2 package

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

Bug#815125: Boot failure with Debian linux 4.4.2 package

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

Bug#815125: Boot failure with Debian linux 4.4.2 package

> 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

Bug#815125: Boot failure with Debian linux 4.4.2 package

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

Bug#815125: Boot failure with Debian linux 4.4.2 package

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

Bug#815125: Boot failure with Debian linux 4.4.2 package

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

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

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

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

Bug#815125: Boot failure with Debian linux 4.4.2 package

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

Bug#815125: Boot failure with Debian linux 4.4.2 package

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

Bug#815125: Boot failure with Debian linux 4.4.2 package

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

Bug#815125: Boot failure with Debian linux 4.4.2 package

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?

Bug#815125: Boot failure with Debian linux 4.4.2 package

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

Bug#815125: Boot failure with Debian linux 4.4.2 package

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

Bug#815125: Boot failure with Debian linux 4.4.2 package

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

Bug#815125: Boot failure with Debian linux 4.4.2 package

❦ 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

Bug#815125: Boot failure with Debian linux 4.4.2 package

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

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

Bug#815125: Boot failure with Debian linux 4.4.2 package

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

Bug#815125: Boot failure with Debian linux 4.4.2 package

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:~$

Bug#815125: Boot failure with Debian linux 4.4.2 package

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

Bug#815125: Boot failure with Debian linux 4.4.2 package

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

Bug#815125: Boot failure with Debian linux 4.4.2 package

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

Bug#815125: Boot failure with Debian linux 4.4.2 package

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

Bug#815125: Boot failure with Debian linux 4.4.2 package

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 >

Bug#815125: Boot failure with Debian linux 4.4.2 package

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

Bug#815125: Boot failure with Debian linux 4.4.2 package

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

Bug#815125: Boot failure with Debian linux 4.4.2 package

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