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)
Wed, Nov 20, 11:43 AM
Unknown Object (File)
Tue, Nov 19, 9:24 AM
Unknown Object (File)
Tue, Nov 5, 1:45 PM
Unknown Object (File)
Oct 22 2024, 5:58 PM
Unknown Object (File)
Oct 22 2024, 5:16 PM
Unknown Object (File)
Oct 22 2024, 6:20 AM
Unknown Object (File)
Oct 16 2024, 9:52 PM
Unknown Object (File)
Oct 15 2024, 2:42 PM
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.