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
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 patc
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, than
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
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
> 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
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 :
> aa
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 mappe
The patch makes no difference.
Is there anything else I can do to help figure this out?
Cheers,
Scott
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
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
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
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
> >> h
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=67
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
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?
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
Exp
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/9axz9s7afi0oq
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.
> On
❦ 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 packag
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.
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 pack
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"),
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
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
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 th
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
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 syste
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
> "
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
❦ 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 th
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 yo
32 matches
Mail list logo
