Date: Sat, 16 Nov 2002 00:10:51 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: David Schultz <dschultz@uclink.Berkeley.EDU> Cc: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org>, <bde@FreeBSD.ORG>, <stable@FreeBSD.ORG>, <current@FreeBSD.ORG> Subject: Re: machdep.c problem Message-ID: <20021115232830.U14343-100000@gamplex.bde.org> In-Reply-To: <20021110195207.GA3323@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 10 Nov 2002, David Schultz wrote: > Thus spake Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org>: > > > This approach is okay with me in the sense that it doesn't break > > > anything that wasn't already broken, but as you say, I think we > > > can do better. Below is a patch that merely extracts the basemem > > > size from the bootinfo structure for the purposes of mapping the > > > EBDA. Note that the int 0x12 call was removed from boot2, so the bi_basemem == 0 case can;t be trusted. > > > 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. > > > kernel should be removed entirely to avoid redundancy, or moved > > > from loader and boot2 to locore.s.) > > > > Yes, this idea was in my first patch actually, and this was not > > good solution as Bruce explained. Please see the archive at: > > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=94412+0+archive/2002/freebsd-current/20021006.freebsd-current > > It sounds like the basic objection is, ``We came up with this > feature in 1995 and never used it, so we shouldn't start using it > now.'' We did use it, at least in the non-VM86 case, until VM86 became standard in 1999. I didn't like making VM86 the default but got used to it. I now see that I was wrong :-). 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). > Fine, but I still maintain that determining the memory > size in real mode like everyone else is the right thing to do. I agree. > Are there any objections to the following? > > - Remove the redundant and unused memory detection code > from boot2, loader, and libi386. I think this is currently the least bad place for it (except there is not enough room to do int 0x15:0xe820 in boot2). > - Mark the bootinfo fields bi_basemem and bi_extmem as > deprecated. Doesn't go with leaving it in boot2, etc. > - Determine basemem in locore.s using 15h:e820h, with a > fallback to int 12h. I think this is the worst place to do it. > - Remove the basemem calculation from machdep.c. machdep.c could probably do the real mode switch without much more difficulty than boot2, etc. 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). 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?20021115232830.U14343-100000>