On 25 Sep 2021, at 23:01, Alexander Motin wrote:
The branch main has been updated by mav:

URL: https://cgit.FreeBSD.org/src/commit/?id=695323ae88c71776e131940ed7dedd25365e932f

commit 695323ae88c71776e131940ed7dedd25365e932f
Author:     Alexander Motin <[email protected]>
AuthorDate: 2021-09-25 20:54:28 +0000
Commit:     Alexander Motin <[email protected]>
CommitDate: 2021-09-25 21:01:28 +0000

    acpi_cpu: Fix panic if some CPU devices are disabled.

    While there, remove couple unneeded global variables.
---
sys/dev/acpica/acpi_cpu.c | 66 +++++++++++++++++++++--------------------------
 1 file changed, 29 insertions(+), 37 deletions(-)

diff --git a/sys/dev/acpica/acpi_cpu.c b/sys/dev/acpica/acpi_cpu.c
index ab4ffda7a02e..0577b6eac8b7 100644
--- a/sys/dev/acpica/acpi_cpu.c
+++ b/sys/dev/acpica/acpi_cpu.c
@@ -154,8 +154,6 @@ static struct sysctl_oid *cpu_sysctl_tree;
 static int              cpu_cx_generic;
 static int              cpu_cx_lowest_lim;

-static device_t                *cpu_devices;
-static int              cpu_ndevices;
 static struct acpi_cpu_softc **cpu_softc;
 ACPI_SERIAL_DECL(cpu, "ACPI CPU");

@@ -443,26 +441,21 @@ acpi_cpu_attach(device_t dev)
 static void
 acpi_cpu_postattach(void *unused __unused)
 {

I’m seeing this panic on a bhyve VM running an up-to-date main kernel:

        Fatal trap 12: page fault while in kernel mode
        cpuid = 2; apic id = 02
        fault virtual address   = 0x0
        fault code              = supervisor read data, page not present
        instruction pointer     = 0x20:0xffffffff804f643c
        stack pointer           = 0x28:0xffffffff8358bf20
        frame pointer           = 0x28:0xffffffff8358bfa0
        code segment            = base 0x0, limit 0xfffff, type 0x1b
                                = DPL 0, pres 1, long 1, def32 0, gran 1
        processor eflags        = interrupt enabled, resume, IOPL = 0
        current process         = 0 (swapper)
        trap number             = 12
        panic: page fault
        cpuid = 2
        time = 1
        KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff8358bbc0
        vpanic() at vpanic+0x187/frame 0xffffffff8358bc20
        panic() at panic+0x43/frame 0xffffffff8358bc80
        trap_fatal() at trap_fatal+0x387/frame 0xffffffff8358bce0
        trap_pfault() at trap_pfault+0x99/frame 0xffffffff8358bd40
        trap() at trap+0x2a7/frame 0xffffffff8358be50
        calltrap() at calltrap+0x8/frame 0xffffffff8358be50
--- trap 0xc, rip = 0xffffffff804f643c, rsp = 0xffffffff8358bf20, rbp = 0xffffffff8358bfa0 --- acpi_cpu_postattach() at acpi_cpu_postattach+0x5c/frame 0xffffffff8358bfa0
        mi_startup() at mi_startup+0x1f0/frame 0xffffffff8358bff0
        btext() at btext+0x22
        KDB: enter: panic
        [ thread pid 0 tid 100000 ]
        Stopped at      kdb_enter+0x37: movq    $0,0x1274f0e(%rip)
        db>

I’ve not done any digging, but given that it seems to die in acpi_cpu_postattach() and you touched that last …, well you know how that goes.

Best regards,
Kristof
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-src-all
To unsubscribe, send any mail to "[email protected]"

Reply via email to