Summary (was Re: Breaking the 64MB barrier)

B. James Phillippe (bryan@terran.org)
Fri, 16 Oct 1998 10:35:06 -0700 (PDT)


On 16 Oct 1998, Achim Oppelt wrote:

> "B. James Phillippe" <bryan@terran.org> writes:
>
> > The question is this: I had a debate with someone about the 64MB+
> > memory issue with Linux. Their position is that it's a bug in the kernel,
> > and mine was that it was an x86 BIOS limitation. I have two questions:
> > 1.) who's right? 2.) How is it that Microsoft is able to deal with this
>
> Both the 2.1.x series of kernels and the 2.0.36pre* kernels have no
> problems detecting more than 64MB of memory. They use a new BIOS call (int
> 0x15 with ax = 0xe801) which doesn't have the limitation to 64MB that the
> old one (ax = 0x88) used to have. (I hope I figured this right from
> arch/i386/boot/setup.S - look for STANDARD_MEMORY_BIOS_CALL in the
> 2.0.36pre* version of that file.) I guess that answers both your questions.

Thanks, this is very helpful information. I will then examine a diff
between 2.0.33 (what we're using) and the latest 2.0.36pre to see if I can
understand the change better. One reason I was thrown is that 2.0.36 final
is still on trial and it is unknown how much longer the jury will
deliberate. :)

> > without a bootloader option, and we can't? Seems this is a sizeable
> > flaw (regardless of the cause) for systems where the memory amount may
> > be changed dynamically. If this is indeed a kernel limitation, what
> > would be
>
> Yeah. Opening the case to add/remove SIMMs is very easy, compared to a
> "vi /etc/lilo.conf; /sbin/lilo". :-)

Actually, I hope you're not being sarcastic. The company I work for is
similar to Corel and Cobaltmicro in that we too sell an "appliance"-like
Linux product. Unfortunately, our platform is x86-based under the hood
(FYI, the product is an Internet firewall called the WatchGuard Firebox
[http://www.watchguard.com FMI]) so we are faced with much of the
x86-specific PC-BIOS braindamage. In our particular appliance, there is no
vi. In fact, there is no shell of any kind, nor ability to login, nor
keyboard nor graphic device. The entire system boots off a pre-loaded
flash and is remote-controlled though a cryptographic channel to our custom
user interface. So yes, adding a DIMM to the appliance is 1000-fold easier
than re-writing the flash with a new bootloader (changing the LILO option
is basically rewriting the bootsector). It is the difference between being
able to offer a system with no memory barrier versus being pinned to 64M.

-bp

--
B. James Phillippe	. bryan@terran.org
UNIX Software Engineer	. http://www.terran.org/~bryan
Member since 1.1.59	. finger:bryan@earth.terran.org
MOTM: Waiting for the DSL to go in :)

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/