ACPI strangeness on Asus M2A-VM

[Carl-Daniel Hailfinger]

Hi,

I believe I should not getting the following ACPI debug message (and
similar messages) with only 2 GB RAM installed:
evregion-0398 [00] ev_address_space_dispa: Handler ffff8800773c9ae0
(@ffffffff803a9598) Address 0000000100000128 [SystemMemory]
evregion-0398 [00] ev_address_space_dispa: Handler ffff8800773c9ae0
(@ffffffff803a9598) Address 0000000100000131 [SystemMemory]

The address in that message is 128/131 bytes above the 4 GB boundary.
/proc/iomem says no device lives there. AFAICS that means ACPI tries to
access nonexisting memory.

The machine boots fine, but once I plug in 4 GB RAM, ACPI still tries to
access the address above although real memory lives at that location and
booting fails with the following messages:
ACPI Error (exregion-0164): Could not map memory at 0000000100000128,
size ED7 [20070126]
ACPI Exception (evregion-0420): AE_NO_MEMORY, Returned by Handler for
[SystemMemory] [20070126]
ACPI Exception (dswexec-0462): AE_NO_MEMORY, While resolving operands
for [LGreater] [20070126]
ACPI Error (psparse-0537): Method parse/execution failed
[_SB_.PCI0.STCR.PMRY.PMST._STA] (Node ffff81013fa524f0), AE_NO_MEMORY
ACPI Error (uteval-0233): Method execution failed
[_SB_.PCI0.STCR.PMRY.PMST._STA] (Node ffff81013fa524f0), AE_NO_MEMORY
[...]
ACPI Error (exregion-0164): Could not map memory at 0000000100000131,
size ECE [20070126]
ACPI Exception (evregion-0420): AE_NO_MEMORY, Returned by Handler for
[SystemMemory] [20070126]
ACPI Error (psparse-0537): Method parse/execution failed [_GPE._L1F]
(Node ffff81013fa52330), AE_NO_MEMORY
ACPI Exception (evgpe-0577): AE_NO_MEMORY, while evaluating GPE method
[_L1F] [20070126]

The factory BIOS does not exhibit this behaviour.

Interesting is that the addresses above 4 GB look like they are offsets
to 0xffffffff, i.e. they all seem to be 4G-1+offset.

Attached are:
minicom_2009-03-17T053516.cap (coreboot+Linux, 2 GB)
minicom_2009-03-17T054446.cap (BIOS+Linux, 2 GB)

The following kernel parameters were used to improve debugging:
mminit_loglevel=4 acpi.debug_level=0x10807

Possibly interesting excerpts from the ACPI code:

Device(STCR) {
Name(_ADR, 0x00120000)
Device(PMRY)
{
        Name(_ADR, 0)
        Method(_GTM, 0x0, NotSerialized) {
                Return(STTM)
        }
        Method(_STM, 0x3, NotSerialized) {}

Device(PMST) {
                Name(_ADR, 0)
                Method(_STA,0) {
                        if (LGreater(P0IS,0)) {
                                return (0x0F) /* sata is visible */
                        }
                        else {
                                return  (0x00) /* sata is missing */
                        }
                }
        }/* end of PMST */
...
} /* end STCR */
> From the excerpt above, it seems that the access to P0IS and causes the

error.
OperationRegion(PCFG, SystemMemory, PCBA, 0x01000000) /* Each bus
consumes 1MB */
        Field(PCFG, ByteAcc, NoLock, Preserve) {
        /* Byte offsets are computed using the following technique:
           * ((bus number + 1) * ((device number * 8) * 4096)) +
register offset
           * The 8 comes from 8 functions per device, and 4096 bytes per
function config space
        */
        Offset(0x00090024),     /* Byte offset to SATA register 24h -
Bus 0, Device 18, Function 0 */
        STB5, 32,               /* Address of SATA_BAR5 */
...
}

OperationRegion(SB5, SystemMemory, STB5, 0x1000) /* SATA_BAR5 (ABAR) */
        Field(SB5, AnyAcc, NoLock, Preserve)
        {
...
        Offset(0x128),          /* Port 0 Serial ATA status */
        P0DD, 4,                /* Port 0 Device Detection (DET) */
        , 4,
        P0IS, 4,                /* Port 0 Interface Power Management
(IPM) */
        Offset(0x12C),          /* Port 0 Serial ATA control */
        P0DI, 4,
        Offset(0x130),          /* Port 0 Serial ATA error */
        , 16,
        P0PR, 1,

The only explanation I can come up with is:
P0IS lives at addrof(SB5)+0x129
P0PR lives at addrof(SB5)+0x132
Field SB5 has address STB5.
Therefore:
P0IS lives at STB5+0x129
P0PR lives at STB5+0x132
The accesses to P0IS happen at 0x100000128.
The accesses to P0PR happen at 0x100000131.
Subtraction yields:
STB5=0xffffffff.
That's certainly NOT a valid address of a BAR.

The coreboot log says:
sata_bar5=fc409000

/proc/iomem says:
fc409000-fc4093ff : 0000:00:12.0
  fc409000-fc4093ff : ahci

lspci says:
00:12.0 SATA controller [0106]: ATI Technologies Inc SB600 Non-Raid-5
SATA [1002:4380] (prog-if 01 [AHCI 1.0])
        Subsystem: ATI Technologies Inc SB600 Non-Raid-5 SATA [1002:4380]
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 64, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 22
        Region 0: I/O ports at 4020 [size=8]
        Region 1: I/O ports at 4060 [size=4]
        Region 2: I/O ports at 4030 [size=8]
        Region 3: I/O ports at 4070 [size=4]
        Region 4: I/O ports at 4000 [size=16]
        Region 5: Memory at fc409000 (32-bit, non-prefetchable) [size=1K]
        Capabilities: [60] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: ahci
        Kernel modules: ahci
00: 02 10 80 43 07 01 30 02 00 01 06 01 10 40 00 00
10: 21 40 00 00 61 40 00 00 31 40 00 00 71 40 00 00
20: 01 40 00 00 00 90 40 fc 00 00 00 00 02 10 80 43
30: 00 00 00 00 60 00 00 00 00 00 00 00 00 01 00 00
40: 14 00 80 02 01 00 10 00 01 00 00 00 00 00 00 00
50: 05 00 84 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 01 00 22 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 12 00 10 00 0f 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 06 00 00 2c d6 01 b4 00 d6 01 b4 00
90: d6 01 b4 00 d6 01 b4 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 b8 00 00 00 00 00 00 00 b8 00 00
b0: 00 00 00 00 00 b8 00 00 00 00 00 00 00 b8 00 00
c0: 00 20 00 00 80 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Tell me what additional info you need and I'll send it.

Regards,
Carl-Daniel

[Myles Watson]

2009/3/17 Carl-Daniel Hailfinger :
> Hi,
>
> I believe I should not getting the following ACPI debug message (and
> similar messages) with only 2 GB RAM installed:
> evregion-0398 [00] ev_address_space_dispa: Handler ffff8800773c9ae0
> (@ffffffff803a9598) Address 0000000100000128 [SystemMemory]
> evregion-0398 [00] ev_address_space_dispa: Handler ffff8800773c9ae0
> (@ffffffff803a9598) Address 0000000100000131 [SystemMemory]
>
> The address in that message is 128/131 bytes above the 4 GB boundary.
> /proc/iomem says no device lives there. AFAICS that means ACPI tries to
> access nonexisting memory.
>
> The machine boots fine, but once I plug in 4 GB RAM, ACPI still tries to
> access the address above although real memory lives at that location and
> booting fails with the following messages:
> ACPI Error (exregion-0164): Could not map memory at 0000000100000128,
> size ED7 [20070126]
> ACPI Exception (evregion-0420): AE_NO_MEMORY, Returned by Handler for
> [SystemMemory] [20070126]
> ACPI Exception (dswexec-0462): AE_NO_MEMORY, While resolving operands
> for [LGreater] [20070126]
> ACPI Error (psparse-0537): Method parse/execution failed
> [_SB_.PCI0.STCR.PMRY.PMST._STA] (Node ffff81013fa524f0), AE_NO_MEMORY
> ACPI Error (uteval-0233): Method execution failed
> [_SB_.PCI0.STCR.PMRY.PMST._STA] (Node ffff81013fa524f0), AE_NO_MEMORY
> [...]
> ACPI Error (exregion-0164): Could not map memory at 0000000100000131,
> size ECE [20070126]
> ACPI Exception (evregion-0420): AE_NO_MEMORY, Returned by Handler for
> [SystemMemory] [20070126]
> ACPI Error (psparse-0537): Method parse/execution failed [_GPE._L1F]
> (Node ffff81013fa52330), AE_NO_MEMORY
> ACPI Exception (evgpe-0577): AE_NO_MEMORY, while evaluating GPE method
> [_L1F] [20070126]
>
> The factory BIOS does not exhibit this behaviour.
>
> Interesting is that the addresses above 4 GB look like they are offsets
> to 0xffffffff, i.e. they all seem to be 4G-1+offset.
>
> Attached are:
> minicom_2009-03-17T053516.cap (coreboot+Linux, 2 GB)
> minicom_2009-03-17T054446.cap (BIOS+Linux, 2 GB)
>
> The following kernel parameters were used to improve debugging:
> mminit_loglevel=4 acpi.debug_level=0x10807
>
> Possibly interesting excerpts from the ACPI code:
>
> Device(STCR) {
> Name(_ADR, 0x00120000)
> Device(PMRY)
> {
>        Name(_ADR, 0)
>        Method(_GTM, 0x0, NotSerialized) {
>                Return(STTM)
>        }
>        Method(_STM, 0x3, NotSerialized) {}
>
> Device(PMST) {
>                Name(_ADR, 0)
>                Method(_STA,0) {
>                        if (LGreater(P0IS,0)) {
>                                return (0x0F) /* sata is visible */
>                        }
>                        else {
>                                return  (0x00) /* sata is missing */
>                        }
>                }
>        }/* end of PMST */
> ...
> } /* end STCR */
>
> From the excerpt above, it seems that the access to P0IS and causes the
> error.
> OperationRegion(PCFG, SystemMemory, PCBA, 0x01000000) /* Each bus
> consumes 1MB */

It looks like it is using memory-mapped PCI configuration.  What is
PCBA?  Have you inserted some Store (..., Debug) lines and run it to
see where the values are coming up wrong?
> Field(PCFG, ByteAcc, NoLock, Preserve) {
>        /* Byte offsets are computed using the following technique:
>           * ((bus number + 1) * ((device number * 8) * 4096)) +
> register offset
>           * The 8 comes from 8 functions per device, and 4096 bytes per
> function config space
>        */
>        Offset(0x00090024),     /* Byte offset to SATA register 24h -
> Bus 0, Device 18, Function 0 */
>        STB5, 32,               /* Address of SATA_BAR5 */
> ...
> }
>
> OperationRegion(SB5, SystemMemory, STB5, 0x1000) /* SATA_BAR5 (ABAR) */
>        Field(SB5, AnyAcc, NoLock, Preserve)
>        {
> ...
>        Offset(0x128),          /* Port 0 Serial ATA status */
>        P0DD, 4,                /* Port 0 Device Detection (DET) */
>        , 4,
>        P0IS, 4,                /* Port 0 Interface Power Management
> (IPM) */
>        Offset(0x12C),          /* Port 0 Serial ATA control */
>        P0DI, 4,
>        Offset(0x130),          /* Port 0 Serial ATA error */
>        , 16,
>        P0PR, 1,
>
> The only explanation I can come up with is:
> P0IS lives at addrof(SB5)+0x129
> P0PR lives at addrof(SB5)+0x132
> Field SB5 has address STB5.
> Therefore:
> P0IS lives at STB5+0x129
> P0PR lives at STB5+0x132
> The accesses to P0IS happen at 0x100000128.
> The accesses to P0PR happen at 0x100000131.
> Subtraction yields:
> STB5=0xffffffff.
> That's certainly NOT a valid address of a BAR.

...
> Writing IRQ routing tables to 0xf0000...write_pirq_routing_table done.
> ACPI: Writing ACPI tables at f0400...
> ACPI:    * HPET
> ACPI: added table 1/9 Length now 40
> ACPI:    * MADT
> ACPI: added table 2/9 Length now 44
> ACPI:    * SSDT
> processor_brand=AMD Athlon(tm) 64 Processor 3000+
> Pstates Algorithm ...
> Pstate_freq[0] = 1800MHz        Pstate_vid[0] = 12      Pstate_volt[0] = 1250mv Pstate_power[0] = 62000mw
> Pstate_freq[1] = 1000MHz        Pstate_vid[1] = 18      Pstate_volt[1] = 1100mv Pstate_power[1] = 26673mw
> ACPI: added table 3/9 Length now 48
> ACPI:    * FACS
> ACPI:    * DSDT
> ACPI:    * DSDT @ 000f0748 Length 26a4
> ACPI:    * FADT

I expected to see an MCFG here.  I know you don't need it, but it
would be easy to add if you have Memory-mapped configuration set up
correctly.  I was going to check the address.
> pm_base: 0x0800
> ACPI: added table 4/9 Length now 52
> ACPI: done.
> Wrote the mp table end at: 00000020 - 00000120
> Moving GDT to 0x500...ok
> Multiboot Information structure has been written.
> Adjust low_table_end from 0x00000530 to 0x00001000
> Adjust rom_table_end from 0x000f30d0 to 0x00100000
> uma_memory_base=0x78000000, uma_memory_size=0x8000000
> Wrote coreboot table at: 00000530 - 00000760  checksum d78d

Thanks,
Myles

[Carl-Daniel Hailfinger]

On 17.03.2009 16:47, Myles Watson wrote:
> 2009/3/17 Carl-Daniel Hailfinger :
> > Hi,
> >
> > I believe I should not getting the following ACPI debug message (and
> > similar messages) with only 2 GB RAM installed:
> > evregion-0398 [00] ev_address_space_dispa: Handler ffff8800773c9ae0
> > (@ffffffff803a9598) Address 0000000100000128 [SystemMemory]
> > evregion-0398 [00] ev_address_space_dispa: Handler ffff8800773c9ae0
> > (@ffffffff803a9598) Address 0000000100000131 [SystemMemory]
> >
> > The address in that message is 128/131 bytes above the 4 GB boundary.
> > /proc/iomem says no device lives there. AFAICS that means ACPI tries to
> > access nonexisting memory.
> >
> > The machine boots fine, but once I plug in 4 GB RAM, ACPI still tries to
> > access the address above although real memory lives at that location and
> > booting fails with the following messages:
> > ACPI Error (exregion-0164): Could not map memory at 0000000100000128,
> > size ED7 [20070126]
> > ACPI Exception (evregion-0420): AE_NO_MEMORY, Returned by Handler for
> > [SystemMemory] [20070126]
> > ACPI Exception (dswexec-0462): AE_NO_MEMORY, While resolving operands
> > for [LGreater] [20070126]
> > ACPI Error (psparse-0537): Method parse/execution failed
> > [_SB_.PCI0.STCR.PMRY.PMST._STA] (Node ffff81013fa524f0), AE_NO_MEMORY
> > ACPI Error (uteval-0233): Method execution failed
> > [_SB_.PCI0.STCR.PMRY.PMST._STA] (Node ffff81013fa524f0), AE_NO_MEMORY
> > [...]
> > ACPI Error (exregion-0164): Could not map memory at 0000000100000131,
> > size ECE [20070126]
> > ACPI Exception (evregion-0420): AE_NO_MEMORY, Returned by Handler for
> > [SystemMemory] [20070126]
> > ACPI Error (psparse-0537): Method parse/execution failed [_GPE._L1F]
> > (Node ffff81013fa52330), AE_NO_MEMORY
> > ACPI Exception (evgpe-0577): AE_NO_MEMORY, while evaluating GPE method
> > [_L1F] [20070126]
> >
> > The factory BIOS does not exhibit this behaviour.
> >
> > Interesting is that the addresses above 4 GB look like they are offsets
> > to 0xffffffff, i.e. they all seem to be 4G-1+offset.
> >
> > Attached are:
> > minicom_2009-03-17T053516.cap (coreboot+Linux, 2 GB)
> > minicom_2009-03-17T054446.cap (BIOS+Linux, 2 GB)
> >
> > The following kernel parameters were used to improve debugging:
> > mminit_loglevel=4 acpi.debug_level=0x10807
>
> It looks like it is using memory-mapped PCI configuration.  What is
> PCBA?  Have you inserted some Store (..., Debug) lines and run it to
> see where the values are coming up wrong?

Problem found. We explicitly enable MMCONFIG in the RS690 code twice,
then we disable it and hope that coreboot reenables MMCONFIG accesses.
That never happens.
Crude workaround posted in the thread
[coreboot] [PATCH] Fix RS690 MMCONFIG access
> > ACPI:    * FACS
> > ACPI:    * DSDT
> > ACPI:    * DSDT @ 000f0748 Length 26a4
> > ACPI:    * FADT
>
> I expected to see an MCFG here.  I know you don't need it, but it
> would be easy to add if you have Memory-mapped configuration set up
> correctly.  I was going to check the address.

Ah yes, another TODO item.

Thanks for your suggestions.

Regards,
Carl-Daniel