Page MenuHomeFreeBSD

ensure that initial local apic id is sane on AMD 10h systems
ClosedPublic

Authored by avg on Apr 22 2016, 1:30 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 28 2024, 10:51 AM
Unknown Object (File)
Feb 28 2024, 9:01 AM
Unknown Object (File)
Dec 23 2023, 2:47 AM
Unknown Object (File)
Nov 9 2023, 10:10 PM
Unknown Object (File)
Oct 8 2023, 9:11 PM
Unknown Object (File)
Sep 29 2023, 10:21 AM
Unknown Object (File)
Sep 18 2023, 4:38 PM
Unknown Object (File)
Jul 16 2023, 6:52 AM
Subscribers

Details

Summary

The initial Local APIC ID is returned by CPUID function 1 (in EBX).
On AMD Family 10h systems the way that ID is built is controlled by
an MSR bit. BKDG instructs BIOS to set it in a certain way, but a BIOS can
be buggy. In that case the ID can confuse tools that use it, e.g. hwloc.
See: https://github.com/open-mpi/hwloc/issues/183

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

avg retitled this revision from to ensure that initial local apic id is sane on AMD 10h systems.
avg updated this object.
avg edited the test plan for this revision. (Show Details)
avg added reviewers: jhb, kib.

Does the MADT ACPI table content no longer match what CPU reports, in particular, the APIC IDs ?

In D6060#129003, @kib wrote:

Does the MADT ACPI table content no longer match what CPU reports, in particular, the APIC IDs ?

Yes, that's the case. MADT and LAPICs have consistent sane values of 0 -3 on my system, but the IDs reported via CPUID.1 are 0, 0x40, 0x80, 0xc0.

In D6060#129004, @avg wrote:

Yes, that's the case. MADT and LAPICs have consistent sane values of 0 -3 on my system, but the IDs reported via CPUID.1 are 0, 0x40, 0x80, 0xc0.

I suggest to note this in the comment.

kib edited edge metadata.
This revision is now accepted and ready to land.Apr 22 2016, 2:51 PM
This revision was automatically updated to reflect the committed changes.