From owner-freebsd-stable Fri Nov 15 5:23: 2 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0D6C37B401; Fri, 15 Nov 2002 05:23:00 -0800 (PST) Received: from HAL9000.homeunix.com (12-232-220-15.client.attbi.com [12.232.220.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE13B43E4A; Fri, 15 Nov 2002 05:22:59 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id gAFDMw2q014131; Fri, 15 Nov 2002 05:22:58 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id gAFDMw67014130; Fri, 15 Nov 2002 05:22:58 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Fri, 15 Nov 2002 05:22:58 -0800 From: David Schultz To: Bruce Evans Cc: Mitsuru IWASAKI , bde@FreeBSD.ORG, stable@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: machdep.c problem Message-ID: <20021115132258.GB14000@HAL9000.homeunix.com> Mail-Followup-To: Bruce Evans , Mitsuru IWASAKI , bde@FreeBSD.ORG, stable@FreeBSD.ORG, current@FreeBSD.ORG References: <20021110195207.GA3323@HAL9000.homeunix.com> <20021115232830.U14343-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021115232830.U14343-100000@gamplex.bde.org> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thus spake Bruce Evans : > > > > I retained the int 12h fallback just to be safe, but I > > > > think the bootinfo structure is initialized with a valid basemem > > > > for all loaders since at least 1998. (Maybe the fallbacks in the > > Since 1995, but not in boot2 since 2002/10/01. The bi_memsizes_valid > flag unfortunately covers both bi_basemem and bi_extmem, so it is still > set although bi_basemem is bogus. Also, boot2 and most (all?) other > places never checked for errors from int 0x12, so bi_basemem may be > pure garbage. That's easy enough to fix. Add fields bi_newbasemem and bi_newextmem, implement them correctly, and fall back to the present behavior if neither are present. This approach couldn't make things any worse than they already are. > IIRC, the main reason for making VM86 standard was to use it here. > vm86_intcall() still doesn't seem to be used much. It is used mainly for > the memsize calls and setting vesa modes. int 0x12 can be done just as > easily in the boot code. Setting vesa modes can be optional. Only the > memory map subcall of the int 0x15 is much easier to do like it is done > now (the maps are too large for the boot code to pass easily). Linux manages this by reserving a page for the int 15h:e820h map, I think. It doesn't look unreasonably difficult to pass the map to the kernel. Even if we have to resort to VM86 for this, we can at least deal with basemem in real mode. > > Are there any objections to the following? [...] > > - Remove the basemem calculation from machdep.c. > > machdep.c could probably do the real mode switch without much more > difficulty than boot2, etc. You think so? I would imagine that after paging is enabled, switching to real mode from a loaded kernel would be nontrivial. > I would prefer to fix int 0x12 (if BIOSes are so broken as to trap > even when it is set up correctly, then handle the trap and make int > 0x12 return 0; also return 0 if it fails. So basemem is 0 in broken > cases -- waste a whole 640K as a reward for being broken. Note that > the subsequent int 0x15 call(s) in machdep.c will still work, just as > if the BIOS ate the 640K -- we map it all r/w for the BIOS). Your idea sounds reasonable, although I would still prefer to fix the boot loader to reliably report the base memory size. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message