Date: Fri, 15 Nov 2002 05:22:58 -0800 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Bruce Evans <bde@zeta.org.au> Cc: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org>, bde@FreeBSD.ORG, stable@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: machdep.c problem Message-ID: <20021115132258.GB14000@HAL9000.homeunix.com> In-Reply-To: <20021115232830.U14343-100000@gamplex.bde.org> References: <20021110195207.GA3323@HAL9000.homeunix.com> <20021115232830.U14343-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Bruce Evans <bde@zeta.org.au>: > > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021115132258.GB14000>