Date: Mon, 30 Sep 2002 11:58:55 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org> Cc: current@FreeBSD.ORG Subject: Re: [PATCH] Workaround for bogus INT 12H BIOS service implementation Message-ID: <20020930115717.J43806-100000@gamplex.bde.org> In-Reply-To: <20020930.070003.70227125.iwasaki@jp.FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 30 Sep 2002, Mitsuru IWASAKI wrote:
> Hi, I've found that some recent machine's BIOS doesn't support INT 12H
> (Get base memory size) BIOS service, instead they seems to support
> SMAP (system memory map: INT 15H function e820H) for this purpose.
> I already checked that there is no problems on Linux or Windows or
> others, but FreeBSD won't boot at all.
>
> I'll report bogus INT 12H BIOS service implementation to BIOS vendors
> if I get chances. On the other hand, I think we need to have a
> workaround in a safety way for this problem for newer machines.
>
> Here is the patches. I'll commit them in a few days if no objection.
> ...
> Index: sys/i386/i386/machdep.c
> ===================================================================
> RCS file: /home/ncvs/src/sys/i386/i386/machdep.c,v
> retrieving revision 1.532
> diff -u -r1.532 machdep.c
> --- sys/i386/i386/machdep.c 7 Sep 2002 19:12:42 -0000 1.532
> +++ sys/i386/i386/machdep.c 29 Sep 2002 21:15:26 -0000
> @@ -1269,8 +1269,12 @@
> /*
> * Perform "base memory" related probes & setup
> */
> - vm86_intcall(0x12, &vmf);
> - basemem = vmf.vmf_ax;
> + if (bootinfo.bi_basemem != 0) {
> + basemem = bootinfo.bi_basemem;
> + } else {
> + vm86_intcall(0x12, &vmf);
> + basemem = vmf.vmf_ax;
> + }
> if (basemem > 640) {
> printf("Preposterous BIOS basemem of %uK, truncating to 640K\n",
> basemem);
The kernel hasn't used bootinfo.bi_basemem for a long time and shouldn't
start using it again now. It already uses the 0x15/0xe820 call for
everything except basemem (except when the this call fails, it falls
back to 0x15/0xe801). Maybe the bug has something to do with the
kernel using the 0x12 call without checking whether the call succeeded.
When both the 0x15/0xe820 and the 0x15/0xe801 calls fail, the kernel
falls back to an 0x15/0x88 call for determining extmem ... except this
is ifdefed out and replaced by looking at the rtc values. Maybe the
unreliability of the 0x15/0x88 call has something to do with not
checking if the call succeeded.
The patch makes no difference for booting directly from boot2 ... except
memsize() in boot2 also fails to check for errors, so it returns garbage
values.
I think the basemem == 0 case should just work, so the systems with a
broken INT 0x12 should at worst lose 640K of memory, no matter whether
basemem is set to 0 because INT 0x12 fails or because it actually
returns 0.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020930115717.J43806-100000>