From: "H. Peter Anvin" <hpa@zytor.com>
To: Josh Triplett <josh@joshtriplett.org>
Cc: Ben Hutchings <ben@decadent.org.uk>,
x86@kernel.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: Thu, 24 Jun 2010 13:58:24 -0700 [thread overview]
Message-ID: <4C23C6F0.50206@zytor.com> (raw)
In-Reply-To: <20100624190107.GA15329@feather>
On 06/24/2010 12:01 PM, Josh Triplett wrote:
> On Thu, Jun 24, 2010 at 07:18:34AM -0700, H. Peter Anvin wrote:
>> On 06/24/2010 12:27 AM, Josh Triplett wrote:
>>> The following patch fixes GRUB; with this patch, I can reserve memory
>>> (such as with drivemap), boot 2.6.35-rc3 successfully, and it detects
>>> all of my RAM.
>>
>> Congratulations! You have just committed the single most common BIOS
>> implementation bug. (Sorry for the sarcasm, but this seems to be a bug
>> that almost everyone who tries to implement BIOS makes at one point or
>> another... even the original IBM BIOS had it in at least one place.)
>
> And a rather large number of sample interrupt code found on the web,
> including the e820 hook from the version of gPXE/Etherboot that I used
> as an example. :) Given that I just tested against Linux, which very
> carefully works around that particular BIOS bug, I didn't run into any
> issue.
>
> So, how high does GRUB's bug ("stc ; iret"/"clc ; iret") rank on the
> list of common BIOS implementation bugs?
>
Less common, since that one is apparently more obvious to people (you
only have to think one step ahead instead of two steps ahead.)
There is a reason Linux works around this and similar bugs... it truly
is extremely common (and does cause real problems in real code.)
-hpa
prev parent reply other threads:[~2010-06-24 20:58 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 ` Bug#584846: Detects only 64MB and fails to boot on Intel Green City board if e820 hooked by GRUB2 Ben Hutchings
2010-06-12 18:28 ` 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 [this message]
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=4C23C6F0.50206@zytor.com \
--to=hpa@zytor.com \
--cc=584846@bugs.debian.org \
--cc=ben@decadent.org.uk \
--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.