On Sun, 20 Jan 2008, Len Brown wrote:
> > [ 0.000000] BIOS-provided physical RAM map:
> > [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009dc00 (usable)
> > [ 0.000000] BIOS-e820: 000000000009dc00 - 00000000000a0000 (reserved)
> > [ 0.000000] BIOS-e820: 00000000000ce000 - 0000000000100000 (reserved)
> > [ 0.000000] BIOS-e820: 0000000000100000 - 0000000037e70000 (usable)
> > [ 0.000000] BIOS-e820: 0000000037e70000 - 0000000037e80000 (ACPI data)
>
> OperationRegion (OSTY, SystemMemory, 0x37E80F06, 0x00000001)
> Field (OSTY, AnyAcc, NoLock, Preserve)
> {
> TPOS, 8
> }
>
> Curious, Op-region OSTY sits in the (reclaimable) ACPI tables region
> in the e820 map. I guess it is a good thing that Linux never calls
> the BIOS's bluff and reclaims that region after the tables are read
> (we leave the tables in place and use them there) -- because otherwise
> the OS could scribble on a region that is used by AML at run time.
Shouldn't such problems be added that as a test of firmware quality to the
linux firmware kit (if it doesn't catch such issues already), even if it
doesn't cause Linux breakage?
Anyone screwing up something so basic probably botched up other stuff as
well.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
