lkml.org 
[lkml]   [2000]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] fancy new memory detection, for pre-patch-2.3.48-2
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.453 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site