mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Michael Miller <michaelm@mjmm.org>
To: linux-kernel@vger.kernel.org
Subject: memory size detection problem on 2.3.16+ and 2.4.x
Date: Wed, 4 Apr 2001 01:03:22 +0100 (BST)	[thread overview]
Message-ID: <200104040003.f3403MG01149@mjmm.org> (raw)

Hi,

summary: e801 memory size detection call failure, but bios doesnt
set carry flag on error and hence get an incorrect memory size.

Since the 2.3.16 kernel, my PC has been unable
to run any newer kernels (>2.3.16 or 2.4.x) without using the mem=64M
command line parameter.  This was when the new bigmem support was added
which changed the memory detection routines somewhat.

I have traced this down to a problem with the way in which the kernel
calls the e801 memory size detection bios call.  The kernel assumes that
the bios will set the carry flag on the return from the call should
there be an error.  However, the BIOS on my PC doesnt do this- infact
it seems to simply return from the call without changing any registers.

As a result, my memory size being used is approx 1GB which is derived from 
the values in the CX and DX registers before the call. My BIOS does not clear
them (CX or DX) nor does it set the carry flag. 

I have included a pretty harmless patch below (taken against 2.4.2) for
 arch/i386/boot/setup.S
which works around this buggy BIOS issue.  

The patch clears CX and DX before the call to the e801 routine.  This
should be harmless for any machines which currently work correctly.

Please could this patch be included in the next 2.4.x kernel source tree,
as I would guess that it is not only me affected by this...

Many thanks.
Michael Miller

--- linux-2.4.2-orig/arch/i386/boot/setup.S	Sat Jan 27 18:51:35 2001
+++ linux/arch/i386/boot/setup.S	Wed Apr  4 00:13:52 2001
@@ -32,6 +32,10 @@
  *
  * Transcribed from Intel (as86) -> AT&T (gas) by Chris Noe, May 1999.
  * <stiker@northlink.com>
+ *
+ * Workaround flakey BIOSes for e801 call - which don't use carry flag
+ * on errors. Michael Miller (michaelm@mjmm.org), April 2001
+ *
  */
 
 #define __ASSEMBLY__
@@ -341,6 +345,11 @@
 # to write everything into the same place.)
 
 meme801:
+	xorl	%edx, %edx			# Clear regs to work around
+	xorl	%ecx, %ecx			# flakey BIOSes which don't
+						# use carry bit correctly
+						# This way we get 0MB ram on
+						# call failure
 	movw	$0xe801, %ax
 	int	$0x15
 	jc	mem88





             reply	other threads:[~2001-04-04  0:09 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-04  0:03 Michael Miller [this message]
2001-04-04  0:18 ` Alan Cox
2001-04-04 21:52 Michael Miller

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=200104040003.f3403MG01149@mjmm.org \
    --to=michaelm@mjmm.org \
    --cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®