> Date: Fri, 14 Sep 2018 15:33:04 -0700 > From: Philip Guenther <[email protected]> > > On Fri, 14 Sep 2018, Hrvoje Popovski wrote: > > On 14.9.2018. 19:44, Mark Kettenis wrote: > ... > > > Hvorje, can you boot this machine with 16 cores but acpicpu(4) > > > disabled and send us the acpidump output from /var/db/acpi? > > > > here it is: > > APIC.11 table is broken, having two LAPIC entries with the same processor > ID of 0x38: > > [044h 0068 1] Subtable Type : 00 [Processor Local APIC] > [045h 0069 1] Length : 08 > [046h 0070 1] Processor ID : 38 > [047h 0071 1] Local Apic ID : 0E > [048h 0072 4] Flags (decoded below) : 00000001 > Processor Enabled : 1 > ... > [084h 0132 1] Subtable Type : 00 [Processor Local APIC] > [085h 0133 1] Length : 08 > [086h 0134 1] Processor ID : 38 > [087h 0135 1] Local Apic ID : 0F > [088h 0136 4] Flags (decoded below) : 00000001 > Processor Enabled : 1 > > Both of those entries stick out as not following the processor<-->apic ID > pattern the other entries do, and the latter doubly sticks out as the only > one where one ID is odd and the other even.
So one thing I noticed is that the Processor objects all have an _MAT method. That method returns a local apic or local x2apic entry that looks correct to me. I suspect that modern versions of Windows and Linux use that information instead of the entries from the table. That may be the reason why they didn't notice the broken table yet. Maybe we should use that information as well on OpenBSD. Not trivial though as it will require changes in how we attach cpu(4) instances. And we'd probably need fill x2apic support as well to make this work.
