FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 06-12-2010, 06:03 AM
Josh Triplett
 
Default Bug#584846: Detects only 64MB and fails to boot on Intel Green City board if e820 hooked by GRUB2

Package: linux-2.6
Severity: normal

I managed to reproduce the problem using stock upstream kernels and
defconfig, and with defconfig (and no initramfs) the kernel managed to
use little enough memory that it booted successfully with <64MB of RAM.

Investigating, I found that Linux decided not to use e820, and instead
decided to use the older BIOS function 0x88, which cannot report more
than 64MB of RAM.

With some investigation and bisection, I managed to track the problem
down to the following commit:

commit c549e71d073a6e9a4847497344db28a784061455
Author: H. Peter Anvin <hpa@zytor.com>
Date: Sat Mar 28 13:53:26 2009 -0700

x86, setup: ACPI 3, BIOS workaround for E820-probing code

Impact: ACPI 3 spec compliance, BIOS bug workaround

The ACPI 3 spec added another field to the E820 buffer -- which is
backwards incompatible, since it contains a validity bit.
Furthermore, there has been at least one report of a BIOS which
assumes that the buffer it is pointed at is the same buffer as for the
previous E820 call. Therefore, read the data into a temporary buffer
and copy the standard part of it if and only if the valid bit is set.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>


A kernel built from c549e71d073a6e9a4847497344db28a784061455 finds <64MB
of RAM; a kernel built from c549e71d073a6e9a4847497344db28a784061455^
successfully finds all 4GB of RAM.

Also note that newer upstream kernels, including v2.6.35-rc3, fail as
well. Since later kernels revert part of the above commit, the issue
must lie with the parts of the commit not reverted.

And, again, I can reproduce this using the stock upstream GRUB2 1.98
release built from source, by booting it from a USB key, and then
booting the disk MBR via:

set root=(hd1)
drivemap (hd1) (hd0)
chainloader +1
boot


Nothing special about drivemap here; anything that uses grub's mmap
module to reserve memory via e820 (GRUB_MACHINE_MEMORY_RESERVED) will
cause grub to hook e820 and trigger this bug. However, in stock grub,
only drivemap does this.

- Josh Triplett



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100612060322.29053.94187.reportbug@feather">http ://lists.debian.org/20100612060322.29053.94187.reportbug@feather
 
Old 06-12-2010, 06:33 AM
Josh Triplett
 
Default Bug#584846: Detects only 64MB and fails to boot on Intel Green City board if e820 hooked by GRUB2

Package: linux-2.6
Severity: normal

I also just confirmed that the bug still occurs with the latest GRUB2
from bzr:

revno: 2447
revision-id: cjwatson@ubuntu.com-20100611211535-0wnt2vpuk198erq4
parent: cjwatson@ubuntu.com-20100611211216-7le1e2889gr1jpqz
committer: Colin Watson <cjwatson@ubuntu.com>
branch nick: grub
timestamp: Fri 2010-06-11 22:15:35 +0100
message:
* include/grub/efi/uga_draw.h (GRUB_EFI_UGA_GLT_MAX): Rename to ...
(GRUB_EFI_UGA_BLT_MAX): ... this (typo fix).


I tried latest GRUB because I noticed that some e820-related changes had
gone in after the 1.98 release. This test verifies that those changes
did not affect the bug.

- Josh Triplett



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100612063358.24520.41016.reportbug@feather">http ://lists.debian.org/20100612063358.24520.41016.reportbug@feather
 
Old 06-12-2010, 01:58 PM
Ben Hutchings
 
Default Bug#584846: Detects only 64MB and fails to boot on Intel Green City board if e820 hooked by GRUB2

Josh Triplett reported this problem with memory sizing:

On Fri, 2010-06-11 at 23:03 -0700, Josh Triplett wrote:
> Package: linux-2.6
> Severity: normal
>
> I managed to reproduce the problem using stock upstream kernels and
> defconfig, and with defconfig (and no initramfs) the kernel managed to
> use little enough memory that it booted successfully with <64MB of RAM.
>
> Investigating, I found that Linux decided not to use e820, and instead
> decided to use the older BIOS function 0x88, which cannot report more
> than 64MB of RAM.
>
> With some investigation and bisection, I managed to track the problem
> down to the following commit:
>
> commit c549e71d073a6e9a4847497344db28a784061455
> Author: H. Peter Anvin <hpa@zytor.com>
> Date: Sat Mar 28 13:53:26 2009 -0700
>
> x86, setup: ACPI 3, BIOS workaround for E820-probing code
>
> Impact: ACPI 3 spec compliance, BIOS bug workaround
>
> The ACPI 3 spec added another field to the E820 buffer -- which is
> backwards incompatible, since it contains a validity bit.
> Furthermore, there has been at least one report of a BIOS which
> assumes that the buffer it is pointed at is the same buffer as for the
> previous E820 call. Therefore, read the data into a temporary buffer
> and copy the standard part of it if and only if the valid bit is set.
>
> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
>
>
> A kernel built from c549e71d073a6e9a4847497344db28a784061455 finds <64MB
> of RAM; a kernel built from c549e71d073a6e9a4847497344db28a784061455^
> successfully finds all 4GB of RAM.
>
> Also note that newer upstream kernels, including v2.6.35-rc3, fail as
> well. Since later kernels revert part of the above commit, the issue
> must lie with the parts of the commit not reverted.
>
> And, again, I can reproduce this using the stock upstream GRUB2 1.98
> release built from source, by booting it from a USB key, and then
> booting the disk MBR via:
>
> set root=(hd1)
> drivemap (hd1) (hd0)
> chainloader +1
> boot
>
>
> Nothing special about drivemap here; anything that uses grub's mmap
> module to reserve memory via e820 (GRUB_MACHINE_MEMORY_RESERVED) will
> cause grub to hook e820 and trigger this bug. However, in stock grub,
> only drivemap does this.
>
> - Josh Triplett
>
>
>

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
 
Old 06-12-2010, 06:28 PM
"H. Peter Anvin"
 
Default Bug#584846: Detects only 64MB and fails to boot on Intel Green City board if e820 hooked by GRUB2

On 06/12/2010 06:58 AM, Ben Hutchings wrote:
> Josh Triplett reported this problem with memory sizing:
>
>>
>> A kernel built from c549e71d073a6e9a4847497344db28a784061455 finds <64MB
>> of RAM; a kernel built from c549e71d073a6e9a4847497344db28a784061455^
>> successfully finds all 4GB of RAM.
>>
>> Also note that newer upstream kernels, including v2.6.35-rc3, fail as
>> well. Since later kernels revert part of the above commit, the issue
>> must lie with the parts of the commit not reverted.
>>
>> And, again, I can reproduce this using the stock upstream GRUB2 1.98
>> release built from source, by booting it from a USB key, and then
>> booting the disk MBR via:
>>
>> set root=(hd1)
>> drivemap (hd1) (hd0)
>> chainloader +1
>> boot
>>
>> Nothing special about drivemap here; anything that uses grub's mmap
>> module to reserve memory via e820 (GRUB_MACHINE_MEMORY_RESERVED) will
>> cause grub to hook e820 and trigger this bug. However, in stock grub,
>> only drivemap does this.
>>

It's kind of hard to know what is involved, since clearly it relates to
Grub2, which -- how do I say this politely -- seems to excel at doing
things in the most inferior way possible. This is a great example of that.

The most likely reason it fails is because Grub2 uses ACPI 3-style reads
of the board memory map, gets wrong results for the same reasons the
kernel do, and then pass then downstream to the kernel. As such, there
is absolutely nothing the kernel can do about it.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.




--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4C13D1E7.7060604@zytor.com">http://lists.debian.org/4C13D1E7.7060604@zytor.com
 
Old 06-12-2010, 06:55 PM
Josh Triplett
 
Default Bug#584846: Detects only 64MB and fails to boot on Intel Green City board if e820 hooked by GRUB2

On Sat, Jun 12, 2010 at 11:28:55AM -0700, H. Peter Anvin wrote:
> On 06/12/2010 06:58 AM, Ben Hutchings wrote:
> > Josh Triplett reported this problem with memory sizing:
> >
> >>
> >> A kernel built from c549e71d073a6e9a4847497344db28a784061455 finds <64MB
> >> of RAM; a kernel built from c549e71d073a6e9a4847497344db28a784061455^
> >> successfully finds all 4GB of RAM.
> >>
> >> Also note that newer upstream kernels, including v2.6.35-rc3, fail as
> >> well. Since later kernels revert part of the above commit, the issue
> >> must lie with the parts of the commit not reverted.
> >>
> >> And, again, I can reproduce this using the stock upstream GRUB2 1.98
> >> release built from source, by booting it from a USB key, and then
> >> booting the disk MBR via:
> >>
> >> set root=(hd1)
> >> drivemap (hd1) (hd0)
> >> chainloader +1
> >> boot
> >>
> >> Nothing special about drivemap here; anything that uses grub's mmap
> >> module to reserve memory via e820 (GRUB_MACHINE_MEMORY_RESERVED) will
> >> cause grub to hook e820 and trigger this bug. However, in stock grub,
> >> only drivemap does this.
> >>
>
> It's kind of hard to know what is involved, since clearly it relates to
> Grub2, which -- how do I say this politely -- seems to excel at doing
> things in the most inferior way possible. This is a great example of that.
>
> The most likely reason it fails is because Grub2 uses ACPI 3-style reads
> of the board memory map, gets wrong results for the same reasons the
> kernel do, and then pass then downstream to the kernel. As such, there
> is absolutely nothing the kernel can do about it.

grub2 doesn't do ACPI 3 reads; it always asks for 20 bytes, not 24.

Also, note that it works with older Linux kernels (before the commit in
question) and fails with newer ones. That doesn't rule out the
possibility of a grub bug instead of a Linux bug, but since older Linux
somehow coped with the situation, it seems like a regression that newer
Linux cannot cope.

- Josh Triplett



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100612185538.GA4511@feather">http://lists.debian.org/20100612185538.GA4511@feather
 
Old 06-12-2010, 08:41 PM
"H. Peter Anvin"
 
Default Bug#584846: Detects only 64MB and fails to boot on Intel Green City board if e820 hooked by GRUB2

On 06/12/2010 11:55 AM, Josh Triplett wrote:
>>
>> It's kind of hard to know what is involved, since clearly it relates to
>> Grub2, which -- how do I say this politely -- seems to excel at doing
>> things in the most inferior way possible. This is a great example of that.
>>
>> The most likely reason it fails is because Grub2 uses ACPI 3-style reads
>> of the board memory map, gets wrong results for the same reasons the
>> kernel do, and then pass then downstream to the kernel. As such, there
>> is absolutely nothing the kernel can do about it.
>
> grub2 doesn't do ACPI 3 reads; it always asks for 20 bytes, not 24.
>
> Also, note that it works with older Linux kernels (before the commit in
> question) and fails with newer ones. That doesn't rule out the
> possibility of a grub bug instead of a Linux bug, but since older Linux
> somehow coped with the situation, it seems like a regression that newer
> Linux cannot cope.
>

It's a regression of sorts, sure; but the new Linux code also boots on
real hardware which it didn't boot before. Since this requires Grub2
plus specific hardware, it is hard for me to track down what the problem
might be, but a good step on the way might be to use the Grub2 boot
procedure (with the drive remapping) to chainboot Syslinux, and run
meminfo.c32 which is a memory report debugging tool; it might be able to
give some answers at least.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.




--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4C13F102.7000509@zytor.com">http://lists.debian.org/4C13F102.7000509@zytor.com
 

Thread Tools




All times are GMT. The time now is 06:51 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org