Re: [PATCH] fancy new memory detection, for pre-patch-2.3.48-2

From: david parsons (
Date: Mon Feb 28 2000 - 16:02:08 EST

Jeff Garzik wrote:
> david parsons wrote:
[paranoid memory detection]

> > As a vendor, I don't want to do it because it's like constantly
> > checking to make sure that 2+2 = 4, but I can also see why a
> > motherboard or processor vendor might want to pull open all the
> > stops while validating a bios.
> Well, it is cheap since it can easily be __init code, so please consider
> doing ALL checks, paranoid or not.

   For Mastodon, no, I probably won't[1]; but I certainly would prefer
   that the assembly-side of the patch have the OPTION to do the checks.
   __init doesn't really apply to the assembly side[2], and the thing
   that's important to me is not whether the code is reclaimed, but how
   much room the kernel image takes up on disk because there's only so
   much you can fit on a 1.44mb install floppy.

   But this depends on what Linus wants; I can defer most of the
   paranoia checks to the kernel-side (Sundays patch does just this by
   moving start+size >64 bits and len < 20 into kernel/setup.c) for
   free. Passing up es:di to the kernel-side takes space out of the
   1kb buffer I've set aside for e820 results, which eats into the
   comfortably large 32 element + 240 byte slop area that I've got
   set up now.

> IMHO MandrakeSoft would always compile in the paranoid checks, simply
> because you never know what sort of filth like buggy BIOS is out
> there...

   I don't think the commercial bioses would have any problems because
   not being able to run Linux or Windows on systems with those bioses
   would result in no sales. The various freeware bios efforts, on the
   other hand, scare me, because there is no good negative feedback
   against maliciously broken features; I CAN see a freeware bios
   deciding to ``helpfully'' break both the e820 definition and ACPI by
   moving es:di to point at the next element, and in this case I would
   much rather have the Linux kernel simply fail catastrophically instead
   of tolerating the broken feature [3]

   david parsons \bi/ It works fine under 2.0.28+logo; no 1.2.13 patch yet.

   [1: The current e820 code is running on a lot of machines, and
       I've yet to see any reports where the assembly-side code fails
       outside of one report where e820 only returned one record
       describing the low memory area.]

   [2: the assembly-side is already stepped all over by the kernel.]

   [3: if somebody breaks e820 in their freeware bios, they will most
       likely test it on one of their machines before dumping it on
       their ftp site. Having their machine lock up and die would be
       a pretty compelling reason to not ship the offending code.]

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:20 EST