Would handling a single MADT entry be enough?

[sandras]

On my dual-core test machine my kernel finds two MADTs. Each of these MADTs lists two local APIC IDs - 0 and 1. On both of the MADTs flags say I can enable the cores using the local APIC IDs. The sizes of these MADTs are identical. The checksum bytes differ, though.

I did write some code to handle this duplication.

However, could I just assume a single MADT will report all the local APIC IDs?

Have you seen systems out there that have different local APIC IDs on different MADTs?

[Octocontrabass]

On my dual-core test machine my kernel finds two MADTs.

How is it finding two of them? Are you sure you're following the ACPI specification correctly?

[sandras]

Actually, yes, I'm quite sure I'm following the ACPI specification correctly. This is the second time I'm implementing this. I do check the signatures and checksums of the system descriptor tables, as well as the flags in MADTs. I was able to initialize the cores on my previous iteration using the information I found in the MADTs. The code works fine on other computers as well, and I don't find duplication on those systems.

I've checked the acpidump Linux command. Here's the two tables with APIC signature it returns:

Code: Select all

APIC @ 0x0000000000000000
    0000: 41 50 49 43 68 00 00 00 01 13 50 54 4C 54 44 20  APICh.....PTLTD 
    0010: 09 20 41 50 49 43 20 20 00 00 04 06 20 4C 54 50  . APIC  .... LTP
    0020: 00 00 00 00 00 00 E0 FE 01 00 00 00 00 08 00 00  ................
    0030: 01 00 00 00 00 08 01 01 01 00 00 00 01 0C 02 00  ................
    0040: 00 00 C0 FE 00 00 00 00 04 06 00 05 00 01 04 06  ................
    0050: 01 05 00 01 02 0A 00 00 02 00 00 00 05 00 02 0A  ................
    0060: 00 09 09 00 00 00 0D 00                          ........

APIC @ 0x0000000000000000
    0000: 41 50 49 43 68 00 00 00 01 CC 49 4E 54 45 4C 20  APICh.....INTEL 
    0010: 43 52 45 53 54 4C 4E 45 00 00 04 06 4C 4F 48 52  CRESTLNE....LOHR
    0020: 5A 00 00 00 00 00 E0 FE 01 00 00 00 00 08 00 00  Z...............
    0030: 01 00 00 00 00 08 01 01 01 00 00 00 01 0C 01 00  ................
    0040: 00 00 C0 FE 00 00 00 00 02 0A 00 00 02 00 00 00  ................
    0050: 00 00 02 0A 00 09 09 00 00 00 0D 00 04 06 00 05  ................
    0060: 00 01 04 06 01 05 00 01                          ........

[sounds]

You'll want to check the ACPI spec (use a web search). What you're seeing is the BIOS Vendor overrides the default MADT supplied from Intel.

Intel supplied one:

Code: Select all

APICh.....INTEL 
CRESTLNE....LOHR

BIOS override:

Code: Select all

APICh.....PTLTD 
. APIC  .... LTP

[Octocontrabass]

I've checked the acpidump Linux command. Here's the two tables with APIC signature it returns:

Sounds like you've found a firmware bug. The board manufacturer accidentally included Intel's sample MADT.

What happens if you disable one of the cores in the BIOS? Do both MADTs change?

You'll want to check the ACPI spec (use a web search).

Which part of the ACPI spec explains how to handle duplicate tables?

[sandras]

I do not see any option to disable any of the cores in the BIOS.

For anyone interested, the computer in question is a Dell Vostro 1510 with an Intel Core 2 Duo CPU. The BIOS reports it's version to be A15.

I have updated the BIOS of this laptop in the past and it is at it's latest version. I think I might be able to downgrade it. Maybe that fixes the bug.

This clears up things for me. Thanks, both of you! Local APIC IDs shouldn't have duplicates.

Can ACPI tables list some local APIC IDs in one MADT and others in a different one?

[sounds]

You'll want to check the ACPI spec (use a web search).

Which part of the ACPI spec explains how to handle duplicate tables?

Heh, I went back through the latest one today. MADT should only ever have 1 instance, so the spec excludes this case.

And realistically, a conforming ACPI implementation would need to be able to boot this Dell system, probably logging a warning for the duplicate MADTs. They both enumerate the processors and IO-APIC so it seems like a non-fatal bug. The spec is not very helpful for this scenario.

[sandras]

I did not succeed in updating the BIOS.

But I did simplify my code to not de-duplicate the local APIC IDs. It does report both of the cores twice. And it must be waking up each of the two cores twice. But the cores do wake up and work. I have a final question: Why haven't I tried this earlier? : D

Thank you again. This will help me simplify stuff.

[Octocontrabass]

Can ACPI tables list some local APIC IDs in one MADT and others in a different one?

No. Everything you need will be in one MADT.

In this case, both MADTs contain the same information, so it doesn't matter which one you use, but you should only use one of them.