All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Hutchings <ben@decadent.org.uk>
To: "H. Peter Anvin" <hpa@zytor.com>, x86@kernel.org
Cc: Josh Triplett <josh@joshtriplett.org>,
	584846@bugs.debian.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: Bug#584846: Detects only 64MB and fails to boot on Intel Green City board if e820 hooked by GRUB2
Date: Sat, 12 Jun 2010 14:58:40 +0100	[thread overview]
Message-ID: <1276351120.14011.194.camel@localhost> (raw)
In-Reply-To: <20100612060322.29053.94187.reportbug@feather>

[-- Attachment #1: Type: text/plain, Size: 2465 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

       reply	other threads:[~2010-06-12 14:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20100612060322.29053.94187.reportbug@feather>
2010-06-12 13:58 ` Ben Hutchings [this message]
2010-06-12 18:28   ` Bug#584846: Detects only 64MB and fails to boot on Intel Green City board if e820 hooked by GRUB2 H. Peter Anvin
2010-06-12 18:55     ` Josh Triplett
2010-06-12 20:41       ` H. Peter Anvin
2010-06-12 21:45         ` Josh Triplett
     [not found]         ` <20100612222634.GA1785@feather>
2010-06-12 23:01           ` H. Peter Anvin
2010-06-12 23:02           ` H. Peter Anvin
2010-06-13  0:07             ` Josh Triplett
2010-06-13  0:16               ` H. Peter Anvin
     [not found]                 ` <20100622052236.GA9130@feather>
2010-06-22  6:07                   ` H. Peter Anvin
2010-06-22 16:07                     ` Josh Triplett
2010-06-24  7:27                     ` Josh Triplett
2010-06-24 14:18                       ` H. Peter Anvin
2010-06-24 19:01                         ` Josh Triplett
2010-06-24 20:58                           ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1276351120.14011.194.camel@localhost \
    --to=ben@decadent.org.uk \
    --cc=584846@bugs.debian.org \
    --cc=hpa@zytor.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.