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

From: david parsons (orc@pell.portland.or.us)
Date: Mon Feb 28 2000 - 13:50:30 EST


Linus Torvalds wrote:
>
>
>
> On Mon, 28 Feb 2000 nathan.zook@amd.com wrote:
> >
> > You specifically mentioned es:di being changed as a don't care. The problem
> > is that the ACPI spec (Table 14.2) describes es:di out as, "Return Address
> > Range Descriptor pointer. Same value as on input."
>
> Feel free to do sanity checking.
>
> But no config options.
>
> Why?
>
> I'm looking at the current patch, and I'm left wondering which magic
> combination of options I would choose as a vendor.

    This is a point that Nathan and I have been debating about for quite
    some time. He's much more paranoid than I am and is assuming that
    bios vendors WILL promiscuously break the e820 system call, while
    I've been saying that if this happens every Windows (and Linux)
    machine will stop working on this bios, which is a pretty powerful
    incentive to not break things.

    But doing the paranoia checking is pretty cheap.

    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.

> If one set of config options is not generally usable, then that set should
> not exist at all. I refuse to have code that is complex _and_ conditional,
> and for no apparent reason.

    This is certainly a compelling reason to simplify the assembly-side
    code and remove the checks for water remaining wet at room
    temperature.

    The big reason I want to get the assembly-side and the little bits
    of kernelside patch (with or without paranoia checking) into the
    kernel is that I'd like to cleanly swat out the couple of problems
    that people have had with e820 telling them that video memory is
    usable and having zero-length segments in really high memory ruin
    their day.

    I wanted to do acpi reclaim because the patch bloats the kernel by
    about 2k and the reclaim code gives me another 1-3 pages of code
    back, but some people have reported to Nathan (with the code he
    did prior to us cooperating on the memory detect stuff) that reclaim
    crashes their systems.

    Given my druthers, I'd not have region merge be optional, but I want
    it to be tested by a larger body of people before I yank the option
    and make it the only behavior.

    The config to turn e801 off is because some bios vendors have gone
    rogue and broken it now that e820 is the Official Windows Way of
    detecting memory.

    The config to turn e820 off (or, in the case of Sunday's revision,
    to simply ignore it) is pure and simple paranoia in case a bios
    vendor goes rogue and decides to ship a bios that won't work under
    Windows or Linux.

                  ____
    david parsons \bi/ Addresses at @amd.com and @transmeta.com may have
                   \/ a little more experience when dealing with rogue
                                                         bioses than I do.

-
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/



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