public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Jordan Crouse <jordan.crouse@amd.com>
Cc: Joerg Pommnitz <pommnitz@yahoo.com>,
	cebbert@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: Regression in 2.6.23-pre Was: Problems with 2.6.23-rc6 on AMD Geode LX800
Date: Wed, 26 Sep 2007 14:20:51 -0700	[thread overview]
Message-ID: <46FACD33.1050503@zytor.com> (raw)
In-Reply-To: <20070926211558.GB14877@cosmic.amd.com>

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

Jordan Crouse wrote:
> 
> Hmm - the old code seems to fail to e801 when CF was set too:
> 
> 	int     $0x15                           # make the call
> 	jc      bail820                         # fall to e801 if it fails
> 
> 	cmpl    $SMAP, %eax                     # check the return is `SMAP'
> 	jne     bail820                         # fall to e801 if it fails
> 
> Thats not to say that the old code was correct, mind you.  Failing on a
> bad ID and returning without error on a set CF seems to be good to me.
> 

Testing this patch now:


[-- Attachment #2: 0001-x86-setup-Handle-case-of-improperly-terminated-E82.patch --]
[-- Type: text/x-patch, Size: 2246 bytes --]

>From 2efa33f81ef56e7700c09a3d8a881c96692149e5 Mon Sep 17 00:00:00 2001
From: H. Peter Anvin <hpa@zytor.com>
Date: Wed, 26 Sep 2007 14:11:43 -0700
Subject: [PATCH] [x86 setup] Handle case of improperly terminated E820 chain

At least one system (a Geode system with a Digital Logic BIOS) has
been found which suddenly stops reporting the SMAP signature when
reading the E820 memory chain.  We can't know what, exactly, broke in
the BIOS, so if we detect this situation, declare the E820 data
unusable and fall back to E801.

Also, revert to original behavior of always probing all memory
methods; that way all the memory information is available to the
kernel.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Cc: Jordan Crouse <jordan.crouse@amd.com>
Cc: Joerg Pommnitz <pommnitz@yahoo.com>
---
 arch/i386/boot/memory.c |   30 +++++++++++++++++++++++-------
 1 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/arch/i386/boot/memory.c b/arch/i386/boot/memory.c
index 1a2e62d..bccaa1c 100644
--- a/arch/i386/boot/memory.c
+++ b/arch/i386/boot/memory.c
@@ -20,6 +20,7 @@
 
 static int detect_memory_e820(void)
 {
+	int count = 0;
 	u32 next = 0;
 	u32 size, id;
 	u8 err;
@@ -33,14 +34,24 @@ static int detect_memory_e820(void)
 		      "=m" (*desc)
 		    : "D" (desc), "a" (0xe820));
 
-		if (err || id != SMAP)
+		/* Some BIOSes stop returning SMAP in the middle of
+		   the search loop.  We don't know exactly how the BIOS
+		   screwed up the map at that point, we might have a
+		   partial map, the full map, or complete garbage, so
+		   just return failure. */
+		if (id != SMAP) {
+			count = 0;
 			break;
+		}
 
-		boot_params.e820_entries++;
+		if (err)
+			break;
+
+		count++;
 		desc++;
-	} while (next && boot_params.e820_entries < E820MAX);
+	} while (next && count < E820MAX);
 
-	return boot_params.e820_entries;
+	return boot_params.e820_entries = count;
 }
 
 static int detect_memory_e801(void)
@@ -89,11 +100,16 @@ static int detect_memory_88(void)
 
 int detect_memory(void)
 {
+	int err = -1;
+
 	if (detect_memory_e820() > 0)
-		return 0;
+		err = 0;
 
 	if (!detect_memory_e801())
-		return 0;
+		err = 0;
+
+	if (!detect_memory_88())
+		err = 0;
 
-	return detect_memory_88();
+	return err;
 }
-- 
1.5.3.1


  reply	other threads:[~2007-09-26 21:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-26 10:56 Regression in 2.6.23-pre Was: Problems with 2.6.23-rc6 on AMD Geode LX800 Joerg Pommnitz
2007-09-26 14:10 ` H. Peter Anvin
2007-09-26 15:41   ` Jordan Crouse
2007-09-26 16:57     ` H. Peter Anvin
2007-09-26 19:14     ` H. Peter Anvin
2007-09-26 20:58       ` Jordan Crouse
2007-09-26 21:04         ` H. Peter Anvin
2007-09-26 21:15           ` Jordan Crouse
2007-09-26 21:20             ` H. Peter Anvin [this message]
2007-09-26 21:30               ` Jordan Crouse
  -- strict thread matches above, loose matches on Subject: below --
2007-09-26 15:28 Joerg Pommnitz

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=46FACD33.1050503@zytor.com \
    --to=hpa@zytor.com \
    --cc=cebbert@redhat.com \
    --cc=jordan.crouse@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pommnitz@yahoo.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox