There is an early boot failure with linux-3.[9,10].??? when booting
using uefi on low memory systems.
This seems like it might be hardware specific, I am running on a Lenovo
T520, running bios version 1.42, firmware rev 1.36.
This seems to be limited to x86_64, as i386 does boot.
I build my initram into the kernel image, the following boot line
triggers the issue. The issue causes no kernel messages to be printed
to screen (looks like the kernel isn't loading at all to my untrained eyes).
linux /kernel-3.9.7 mem=300M
the following link contains kernel images and vmlinux for both amd64 and
the referenced kernel versions
http://dev.gentoo.org/~prometheanfire/bugs/471626/
we are tracking the bug here (keep in mind, this is NOT a pax bug)
https://bugs.gentoo.org/show_bug.cgi?id=471626
I have tested the following combinations.
amd64 - 300M - 3.9.7 - bug hit
amd64 - 300M - 3.10-rc7 - big hit
amd64 - 16G - 3.9.7 - bug not hit
amd64 - 16G - 3.10-rc7 - bug not hit
i386 - 300M - 3.9.7 - bug not hit
i386 - 300M - 3.10-rc7 - other bug possibly hit
i386 - 16G - 3.9.7 - bug not hit
i386 - 16G - 3.10-rc7 - other bug possibly hit
the pictures taken for the other possible bug hit are located at
http://goo.gl/741ub
--
-- Matthew Thode (prometheanfire)
On Thu, Jun 27, 2013 at 11:47:42AM -0500, Matthew Thode wrote:
> There is an early boot failure with linux-3.[9,10].??? when booting
> using uefi on low memory systems.
Does it happen on systems that genuinely have small amounts of memory,
or only on systems where you're passing mem=?
--
Matthew Garrett | [email protected]
On 06/27/2013 12:27 PM, Matthew Garrett wrote:
> On Thu, Jun 27, 2013 at 11:47:42AM -0500, Matthew Thode wrote:
>> There is an early boot failure with linux-3.[9,10].??? when booting
>> using uefi on low memory systems.
>
> Does it happen on systems that genuinely have small amounts of memory,
> or only on systems where you're passing mem=?
>
I don't have a system (or even memory to place in this one) that has
that small amount of memory. Do they even make ddr3 sodimms that small?
--
-- Matthew Thode (prometheanfire)
On Thu, Jun 27, 2013 at 12:39:14PM -0500, Matthew Thode wrote:
> On 06/27/2013 12:27 PM, Matthew Garrett wrote:
> > On Thu, Jun 27, 2013 at 11:47:42AM -0500, Matthew Thode wrote:
> >> There is an early boot failure with linux-3.[9,10].??? when booting
> >> using uefi on low memory systems.
> >
> > Does it happen on systems that genuinely have small amounts of memory,
> > or only on systems where you're passing mem=?
> >
> I don't have a system (or even memory to place in this one) that has
> that small amount of memory. Do they even make ddr3 sodimms that small?
I've no idea. If a bug can't be triggered on any hardware that actually
exists, it doesn't seem like a high priority.
--
Matthew Garrett | [email protected]
On 06/27/2013 12:43 PM, Matthew Garrett wrote:
> On Thu, Jun 27, 2013 at 12:39:14PM -0500, Matthew Thode wrote:
>> On 06/27/2013 12:27 PM, Matthew Garrett wrote:
>>> On Thu, Jun 27, 2013 at 11:47:42AM -0500, Matthew Thode wrote:
>>>> There is an early boot failure with linux-3.[9,10].??? when booting
>>>> using uefi on low memory systems.
>>>
>>> Does it happen on systems that genuinely have small amounts of memory,
>>> or only on systems where you're passing mem=?
>>>
>> I don't have a system (or even memory to place in this one) that has
>> that small amount of memory. Do they even make ddr3 sodimms that small?
>
> I've no idea. If a bug can't be triggered on any hardware that actually
> exists, it doesn't seem like a high priority.
>
Dunno, I've asked in the bug for more testing from others that have hit
the problem. I'll let you know what I find.
--
-- Matthew Thode (prometheanfire)
On 06/27/2013 06:47 PM, Matthew Thode wrote:
> There is an early boot failure with linux-3.[9,10].??? when booting
> using uefi on low memory systems.
>
> This seems like it might be hardware specific, I am running on a Lenovo
> T520, running bios version 1.42, firmware rev 1.36.
>
Had the same problem with linux 3.10-rc1 and a stock mac book pro, I
hadn't investigated much further though.
lu
On 06/27/2013 01:17 PM, Luca Barbato wrote:
> On 06/27/2013 06:47 PM, Matthew Thode wrote:
>> There is an early boot failure with linux-3.[9,10].??? when booting
>> using uefi on low memory systems.
>>
>> This seems like it might be hardware specific, I am running on a Lenovo
>> T520, running bios version 1.42, firmware rev 1.36.
>>
>
> Had the same problem with linux 3.10-rc1 and a stock mac book pro, I
> hadn't investigated much further though.
>
> lu
>
You had the problem where it was blank on boot (right after grub, no
kernel messages at all)? Sounds like this might not be limited to just
Lenovo then.
mjg59, is there anything I can do to help move this bug forward? I've
done all I can think of (even tried a serial expresscard slot for logging).
--
-- Matthew Thode (prometheanfire)
On 07/01/2013 06:30 AM, Matthew Thode wrote:
> You had the problem where it was blank on boot (right after grub, no
> kernel messages at all)? Sounds like this might not be limited to just
> Lenovo then.
no grub, efi-stub directly from the efi shell.
> mjg59, is there anything I can do to help move this bug forward? I've
> done all I can think of (even tried a serial expresscard slot for logging).
If you feel like bisecting seems the only option =_=
lu
On 06/30/2013 11:41 PM, Luca Barbato wrote:
> On 07/01/2013 06:30 AM, Matthew Thode wrote:
>
>> You had the problem where it was blank on boot (right after grub, no
>> kernel messages at all)? Sounds like this might not be limited to just
>> Lenovo then.
>
> no grub, efi-stub directly from the efi shell.
>
>> mjg59, is there anything I can do to help move this bug forward? I've
>> done all I can think of (even tried a serial expresscard slot for logging).
>
> If you feel like bisecting seems the only option =_=
>
> lu
>
I was hoping to avoid that, was thinking of bisecting 3.8->3.9 for only
the uefi stuff though, should help keep the traffic down.
--
-- Matthew Thode (prometheanfire)
On Sun, Jun 30, 2013 at 11:30:59PM -0500, Matthew Thode wrote:
> mjg59, is there anything I can do to help move this bug forward? I've
> done all I can think of (even tried a serial expresscard slot for logging).
It does sound like a bug, but unfortunately unless it can be duplicated
on real hardware without restrictive mem= arguments it's likely to be
low on my priorities - there's still enough UEFI bugs that hit people in
default configurations that they tend to get priority, I'm afraid.
--
Matthew Garrett | [email protected]
On 07/01/2013 07:13 AM, Matthew Garrett wrote:
> On Sun, Jun 30, 2013 at 11:30:59PM -0500, Matthew Thode wrote:
>
>> mjg59, is there anything I can do to help move this bug forward? I've
>> done all I can think of (even tried a serial expresscard slot for logging).
>
> It does sound like a bug, but unfortunately unless it can be duplicated
> on real hardware without restrictive mem= arguments it's likely to be
> low on my priorities - there's still enough UEFI bugs that hit people in
> default configurations that they tend to get priority, I'm afraid.
>
real hardware ->
MacBookPro8,2 with efi-stub, loading directly from the efi shell w/out
any memory restriction.
I guess I should try to get more information for you and see if it isn't
some configuration quirk.
lu
On Mon, Jul 01, 2013 at 07:22:32AM +0200, Luca Barbato wrote:
> MacBookPro8,2 with efi-stub, loading directly from the efi shell w/out
> any memory restriction.
How do you know this is the same issue?
--
Matthew Garrett | [email protected]
On 07/01/2013 01:25 AM, Matthew Garrett wrote:
> On Mon, Jul 01, 2013 at 07:22:32AM +0200, Luca Barbato wrote:
>
>> MacBookPro8,2 with efi-stub, loading directly from the efi shell w/out
>> any memory restriction.
>
> How do you know this is the same issue?
>
Same behavior? Can't really know until it's solved I think.
Unfortunately this bug seems to cause a lack of info.
--
-- Matthew Thode (prometheanfire)
On 07/01/2013 08:25 AM, Matthew Garrett wrote:
> On Mon, Jul 01, 2013 at 07:22:32AM +0200, Luca Barbato wrote:
>
>> MacBookPro8,2 with efi-stub, loading directly from the efi shell w/out
>> any memory restriction.
>
> How do you know this is the same issue?
>
I believe in duck bugs, if the range of broken commits looks the same,
and the behaviour looks the same, probably the cause is the same, or at
least I once can be investigated on real hardware and probably once
fixed the other might be fixed as well.
I have not deep knowledge of uefi/efi internals so I'll need some
pointers to figure out exactly why it happens.
Hopefully I will carve some time next weekend to play the restricted
bisect game.
lu
On 07/01/2013 03:07 PM, Luca Barbato wrote:
> Hopefully I will carve some time next weekend to play the restricted
> bisect game.
Release 3.10 apparently doesn't show the problem, I guess problem solved
for me =)
lu
On jeu., 2013-07-04 at 07:53 +0200, Luca Barbato wrote:
> On 07/01/2013 03:07 PM, Luca Barbato wrote:
> > Hopefully I will carve some time next weekend to play the restricted
> > bisect game.
>
> Release 3.10 apparently doesn't show the problem, I guess problem solved
> for me =)
>
> lu
>
I've just tried 3.10.0 with CONFIG_EFI=y and I still can't boot with
mem=300M.
Regards,
--
Yves-Alexis
On jeu., 2013-07-04 at 10:37 +0200, Yves-Alexis Perez wrote:
> On jeu., 2013-07-04 at 07:53 +0200, Luca Barbato wrote:
> > On 07/01/2013 03:07 PM, Luca Barbato wrote:
> > > Hopefully I will carve some time next weekend to play the restricted
> > > bisect game.
> >
> > Release 3.10 apparently doesn't show the problem, I guess problem solved
> > for me =)
> >
> > lu
> >
> I've just tried 3.10.0 with CONFIG_EFI=y and I still can't boot with
> mem=300M.
And to be a little more specific, and with a bit of fun, I've tryied
“bisecting” the amount of ram needed to make a successful boot. Platform
is a Lenovo Thinkpad x230 with 4G of ram.
mem=300M bad
mem=4000M good
mem=2000M bad
mem=3000M bad
mem=3500M good
mem=3250M bad
mem=3375M bad
mem=3437M good
mem=3406M bad
mem=3421M bad
mem=3429M bad
mem=3433M good
mem=3431M bad
mem=3432M bad
So I'm not sure what happens at the 3433M boundary, but there's
definitely something fishy. And 3.5G ram doesn't look like a very
specific machine (although I can't test without artificially setting the
memory limit (I only have one 4096M sodimm).
I'll try to git bisect between 3.8 and 3.10 and using mem=3432M when I
have more time.
Regards,
--
Yves-Alexis
On 07/04/2013 03:53 AM, Yves-Alexis Perez wrote:
> On jeu., 2013-07-04 at 10:37 +0200, Yves-Alexis Perez wrote:
>> On jeu., 2013-07-04 at 07:53 +0200, Luca Barbato wrote:
>>> On 07/01/2013 03:07 PM, Luca Barbato wrote:
>>>> Hopefully I will carve some time next weekend to play the restricted
>>>> bisect game.
>>>
>>> Release 3.10 apparently doesn't show the problem, I guess problem solved
>>> for me =)
>>>
>>> lu
>>>
>> I've just tried 3.10.0 with CONFIG_EFI=y and I still can't boot with
>> mem=300M.
> And to be a little more specific, and with a bit of fun, I've tryied
> “bisecting” the amount of ram needed to make a successful boot. Platform
> is a Lenovo Thinkpad x230 with 4G of ram.
>
> mem=300M bad
> mem=4000M good
> mem=2000M bad
> mem=3000M bad
> mem=3500M good
> mem=3250M bad
> mem=3375M bad
> mem=3437M good
> mem=3406M bad
> mem=3421M bad
> mem=3429M bad
> mem=3433M good
> mem=3431M bad
> mem=3432M bad
>
> So I'm not sure what happens at the 3433M boundary, but there's
> definitely something fishy. And 3.5G ram doesn't look like a very
> specific machine (although I can't test without artificially setting the
> memory limit (I only have one 4096M sodimm).
>
> I'll try to git bisect between 3.8 and 3.10 and using mem=3432M when I
> have more time.
>
> Regards,
>
I tested with a single 2G dimm at pipacs's request. Here is what I found.
mem=unset: booted
mem=1930M: booted
mem=1929M: failed
Booted with memblock=debug and found the following :D
It looks like the uefi regions are simply higher then what the kernel
allows. Here's a grep'd dmesg and /proc/iomem. Maybe the kernel
shouldn't allow you to set mem= to lower then the mem that uefi actually
uses?
--
-- Matthew Thode (prometheanfire)