illumos gate

Post #6807, the line number has changed, but I'm still seeing it panic with a DEBUG kernel regardless of X2APIC value.

We saw this on one of the systems we use at Joyent. Here's the analysis from our bug report:

The Shrimp MK III always panics on debug bits (regardless of the ACPI version) here:

[0]> :c
SunOS Release 5.11 Version joyent_20160721T220241Z 64-bit
Copyright (c) 2010-2016, Joyent Inc. All rights reserved.
DEBUG enabled

panic[cpu0]/thread=fffffffffbc3fd40: assertion failed: mpa->Id != 255, file: ../../i86pc/io/acpi/acpidev/acpidev_cpu.c, line: 259

Warning - stack not written to the dump buffer
fffffffffbc81c40 genunix:process_type+1683e0 ()
fffffffffbc81c70 acpidev:acpidev_cpu_query_MAT+128 ()
fffffffffbc81d00 acpidev:acpidev_walk_apic+ce ()
fffffffffbc81d70 acpidev:acpidev_cpu_get_procid+b0 ()
fffffffffbc81e10 acpidev:acpidev_cpu_filter_func+94 ()
fffffffffbc81e90 acpidev:acpidev_filter_device+62 ()
fffffffffbc81ee0 acpidev:acpidev_cpu_filter+5c ()
fffffffffbc81f70 acpidev:acpidev_process_object+1db ()
fffffffffbc81fa0 acpidev:acpidev_cpu_probe+f4 ()
fffffffffbc82010 acpidev:acpidev_probe_child+350 ()
fffffffffbc820a0 acpidev:acpidev_process_object+58e ()
fffffffffbc820d0 acpidev:acpidev_container_probe+a0 ()
fffffffffbc82140 acpidev:acpidev_probe_child+350 ()
fffffffffbc821d0 acpidev:acpidev_process_object+58e ()
fffffffffbc82200 acpidev:acpidev_device_probe+a5 ()
fffffffffbc82270 acpidev:acpidev_probe_child+350 ()
fffffffffbc822a0 acpidev:acpidev_boot_probe_device+6b ()
fffffffffbc822d0 acpidev:acpidev_boot_probe+95 ()
fffffffffbc822f0 unix:impl_bus_initialprobe+65 ()
fffffffffbc82320 unix:impl_setup_ddi+dc ()
fffffffffbc82340 genunix:create_devinfo_tree+cc ()
fffffffffbc82350 genunix:setup_ddi+13 ()
fffffffffbc823e0 unix:startup_modules+f6 ()
fffffffffbc823f0 unix:startup+55 ()
fffffffffbc82430 genunix:main+9b ()
fffffffffbc82440 unix:_locore_start+90 ()

panic: entering debugger (no dump device, continue to reboot)
Loaded modules: [ mac specfs ]
kmdb: target stopped at:
kmdb_enter+0xb: movq   %rax,%rdi

kmdb: stop at acpidev`acpidev_cpu_query_MAT
kmdb: target stopped at:
acpidev`acpidev_cpu_query_MAT:  pushq  %rbp
[0]> <rdi::print ACPI_MADT_LOCAL_APIC
{
    Header = {
        Type = 0
        Length = 0x8
    }
    ProcessorId = 0xff
    Id = 0xff
    LapicFlags = 0
}

If you look at the ACPI specification, you'll note that the LapicFlags member is zero. This indicates that the CPU is not enabled. In fact, if you read the ACPI specification in more detail you'll find that it notes in v6.0 / 5.2.12.12 (Processor Local x2APIC Structure), that in theory logical processors here shouldn't have an apic ID of 255 and that they should be using an X2APIC entry instead.

I believe that this assertion was trying to basically rule out a case where we had a CPU with an APIC ID of 255. However, in this case, the CPU is not noted as enabled. We've seen this on other test systems before and I suspect some of the way that the ACPI tables are being constructed is leading them to have these kind of garbage disabled entries used as padding as we see a number of them show up here.

Based on that, I'd propose matching the other callers and only doing this when the processor is enabled. To help the non-debug case, we should warn about it. I'd suggest we move that down to the acpi_probe() function which is used by the PSM drivers.