Date: Thu, 06 Nov 1997 04:01:03 -0600 From: Tony Overfield <tony@dell.com> To: Terry Lambert <tlambert@primenet.com> Cc: jamil@trojanhorse.ml.org, hackers@FreeBSD.ORG Subject: Re: >64MB Message-ID: <3.0.3.32.19971106040103.006ede20@bugs.us.dell.com> In-Reply-To: <199711051858.LAA14121@usr02.primenet.com> References: <3.0.3.32.19971105020626.006da974@bugs.us.dell.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> The bootloader already makes the "64 MB limited" BIOS call and sends >> this value to the kernel, but for some strange reason, the kernel >> tosses that value away in favor of the sometimes bogus CMOS value. >> Using this BIOS call's result instead of tossing it would resolve >> my complaint about the CMOS groping. >At 06:58 PM 11/5/97 +0000, Terry Lambert wrote: >The problem with this approach is "keyhole memory allocations" for >soft IDE drive tables and APM BIOS data that can't be overwritten. >This is a common practice among some PC manufacturers (who will >remain nameless). > >At least the "base memory" in the CMOS must be examined to determine >memory which can not be given over to the kernel for it to scribble on. Well, I was obviously talking about extended memory, not base memory, but I'll bite on this sucker bait anyway... ;-) I claim your argument is wrong. The INT 12h BIOS call will (and must) always reflect any "keyhole allocations". The RTC value will *not* reflect them. The BIOS call provides precisely the correct value, unless you happen to think the kernel should steal the memory back from the BIOS, which is, of course, extremely risky. My brief inspection of this code reveals (please correct me if I'm wrong) that the RTC base memory value is never even used (if the bootloader is recent and working, at least) except to produce benign error messages. If the RTC value is necessary, I sure don't see how. >The kernel loads at 1M, regardless of whether there is memory there >or not. Yes, the bootloader knows how much memory is available, but it fails to make the comparison. >There is no graceful failure mode possible for a failure to >load yourself. How about this message, "Not enough extended memory found! (4 MB needed)"? No, I'm not really arguing for any changes here, the days of 640K systems are long gone, but graceful failure is indeed possible. >Given this, a kernel with VM86() capabilities loaded into however >much memory it takes, starting at 1M, can make VM86() calls to >determine how much memory is there. You yourself note that the CMOS >examination for memory sizing is bogusly used at present ...and that >it occurs *after* the kernel is loaded. Yes, but the bootloader already knows how much memory is there. It knows this before the kernel is loaded. It can make sure there is enough memory before the kernel is loaded. It can and does pass that value to the kernel after it is loaded. The kernel then throws it away and gets the wrong information from the CMOS. >> At *least* the "64 MB limited" BIOS call must be in the bootloader. > >At present, and only because the call historically can't be made by >the kernel in protected mode. That's close to being fixed. It only needs to be in the bootloader if you want to make sure there is enough memory to load the kernel, or if you want to remove the bogus CMOS stuff before the vm86() support is working. Right now, the value obtained from the boot loader is completely extraneous except for the useless error message. Speaking of vm86(), why not just use real-mode? It's easier and much better for compatibility while booting. I do remember your dreams of running SCSI option ROM code in multi-use mode, but that's surely a long way off. The APM init code seems to have a good example of making real-mode BIOS calls from the kernel during initialization. - Tony
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.3.32.19971106040103.006ede20>