Re: dmidecode from Dell Vostro 1000

[Henrique de Moraes Holschuh <hmh@hmh.eng.br>]

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