Re: ACPI stops working after memory upgrade vpr Matrix 175b4

[Bruno Ducrot <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org>]

On Thu, Feb 05, 2004 at 08:27:58AM -0800, Randy.Dunlap wrote:
> On Thu, 5 Feb 2004 13:30:49 +0100 Karol Kozimor <sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org> wrote:
> 
> | Thus wrote Randy.Dunlap:
> | > < Recompile your DSDT. Since the amount of RAM changed and you're probably
> | > < using old DSDT containing wrong addresses, no wonder you're hitting
> | > < errors.
> | > Is this correct?  If a user adds or removes memory, then the
> | > DSDT must be rebuilt?  Sheesh!!  That's bad if this is correct.
> | 
> | Yes, that's a necessity in most cases. Why do you consider it that bad?
> 
> That seems quite backwards to me.
> Why should we consider that a good thing?

IMHO that a bad thing.

> I discussed this with Andy Grover and he said that the DSDT isn't
> where the memory size is defined.  It should just be coming from
> the e820 BIOS calls, not from ACPI DSDT etc., which certainly
> made sense to me, as that is something that a user wouldn't need
> to modify after changing the memory size of a system.

I'm not sure if the tables are copied upon e820 calls, but I think
there are copied on POST at least on Phoenix BIOS (that what I
understood from their documentations).  Also most of time, the
AML need somehow to access to the nvram, which is located typically
relative to TOM.  Also, when you add/remove memory modules, there
there is chance that mmio regions are not the same, and
aml need to know that.

-- 
Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn