Thus spake Bruce Evans <[EMAIL PROTECTED]>: > > > > 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
