From: Karol Kozimor <sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org>
To: "Randy.Dunlap" <rddunlap-3NddpPZAyC0@public.gmane.org>
Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: ACPI stops working after memory upgrade vpr Matrix 175b4
Date: Fri, 6 Feb 2004 01:51:09 +0100 [thread overview]
Message-ID: <20040206005109.GA13102@hell.org.pl> (raw)
In-Reply-To: <20040205082758.1917e71a.rddunlap-3NddpPZAyC0@public.gmane.org>
Thus wrote Randy.Dunlap:
> 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
I think you're getting me wrong here: the DSDT clearly does not define the
amount of RAM used by the system, but being dynamically generated by BIOS,
it may include references to fixed memory addresses that can vary with the
amount of RAM installed.
If those addresses change due to such an upgrade, overriding the
BIOS-generated DSDT (containing the right addresses) with one that was
obtained from a system with a different amount of RAM (with addresses
correct for that amount) may indeed not work.
> 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.
The user shouldn't need to supply his own DSDT in the first place.
Best regards,
--
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org
-------------------------------------------------------
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
next prev parent reply other threads:[~2004-02-06 0:51 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-04 15:39 ACPI stops working after memory upgrade vpr Matrix 175b4 Randy.Dunlap
2004-02-04 16:18 ` Sergey Vlasov
[not found] ` <20040204073941.05d71e0b.rddunlap-3NddpPZAyC0@public.gmane.org>
2004-02-04 17:28 ` Bruno Ducrot
[not found] ` <20040204172852.GL882-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org>
2004-02-09 20:21 ` Nate Lawson
2004-02-05 11:21 ` Bas Mevissen
2004-02-05 12:30 ` Karol Kozimor
[not found] ` <20040205123049.GC22034-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org>
2004-02-05 16:27 ` Randy.Dunlap
[not found] ` <20040205082758.1917e71a.rddunlap-3NddpPZAyC0@public.gmane.org>
2004-02-06 0:51 ` Karol Kozimor [this message]
2004-02-07 12:23 ` Bruno Ducrot
-- strict thread matches above, loose matches on Subject: below --
2004-02-11 8:19 Yu, Luming
2004-02-05 20:45 Brown, Len
[not found] ` <BF1FE1855350A0479097B3A0D2A80EE0CC8ABD-N2PTB0HCzHJF3Yvz3xaN/VDQ4js95KgL@public.gmane.org>
2004-02-05 20:41 ` Dave Bauer
2004-02-03 7:07 Yu, Luming
2004-02-03 2:12 Dave Bauer
[not found] ` <401F0395.1090407-eQMij45H2SHXYFsarriMmxagbA6BzR3y@public.gmane.org>
2004-02-03 8:31 ` Karol Kozimor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040206005109.GA13102@hell.org.pl \
--to=sziwan-detuoxkzssqrdjvtcaxf/a@public.gmane.org \
--cc=acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
--cc=rddunlap-3NddpPZAyC0@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox