After update to main-n266611-49a83b94395a: panic: bus_generic_rman_activate_resource

After I saw this with both my headless "build machine" and a laptop (and
verified that there were no more recent commits to main), I figured it
might be worth reporting.

This was after a source update from:
FreeBSD 15.0-CURRENT #473 main-n266588-2a35f3cdf63d-dirty: Fri Nov 24 13:11:48 UTC 2023     root@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 1500004 1500004

("-dirty" because I had hand-applied 50335b1ae4e4:

main-n266589-50335b1ae4e4
commit 50335b1ae4e48712f831e85ddfa7b00da0af382c
Author: Emmanuel Vadot <manu@FreeBSD.org>
Date:   Fri Nov 24 11:30:09 2023 +0100

    sys/mutex.h: Reorder includes

    Fixes:  2a35f3cdf63d ("sys/mutex.h: Include sys/lock.h instead of sys/_lock.h")

after seeing a build failure yesterday after updating to
main-n266588-2a35f3cdf63d.)

Here's a backtrace:

...
Event timer "HPET6" frequency 14318180 Hz quality 340
Event timer "HPET7" frequency 14318180 Hz quality 340
panic: bus_generic_rman_activate_resource: rman 0xffffffff81b0b0e8 doesn't match for resource 0xfffff801092b9280
cpuid = 20
time = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff82eaf8b0
vpanic() at vpanic+0x132/frame 0xffffffff82eaf9e0
panic() at panic+0x43/frame 0xffffffff82eafa40
bus_generic_rman_activate_resource() at bus_generic_rman_activate_resource+0x146/frame 0xffffffff82eafaa0
acpi_alloc_sysres() at acpi_alloc_sysres+0x83/frame 0xffffffff82eafae0
acpi_alloc_resource() at acpi_alloc_resource+0x108/frame 0xffffffff82eafba0
bus_alloc_resource() at bus_alloc_resource+0x9b/frame 0xffffffff82eafc00
acpi_timer_probe() at acpi_timer_probe+0xaa/frame 0xffffffff82eafc80
device_probe_child() at device_probe_child+0x16f/frame 0xffffffff82eafcd0
device_probe() at device_probe+0x8a/frame 0xffffffff82eafcf0
device_probe_and_attach() at device_probe_and_attach+0x32/frame 0xffffffff82eafd20
bus_generic_attach() at bus_generic_attach+0x18/frame 0xffffffff82eafd40
acpi_probe_children() at acpi_probe_children+0x226/frame 0xffffffff82eafda0
acpi_attach() at acpi_attach+0x97b/frame 0xffffffff82eafe30
device_attach() at device_attach+0x3bc/frame 0xffffffff82eafe70
device_probe_and_attach() at device_probe_and_attach+0x70/frame 0xffffffff82eafea0
bus_generic_attach() at bus_generic_attach+0x18/frame 0xffffffff82eafec0
device_attach() at device_attach+0x3bc/frame 0xffffffff82eaff00
device_probe_and_attach() at device_probe_and_attach+0x70/frame 0xffffffff82eaff30
bus_generic_new_pass() at bus_generic_new_pass+0xed/frame 0xffffffff82eaff60
bus_set_pass() at bus_set_pass+0x36/frame 0xffffffff82eaff90
configure() at configure+0x9/frame 0xffffffff82eaffa0
mi_startup() at mi_startup+0x1c8/frame 0xffffffff82eafff0
KDB: enter: panic
[ thread pid 0 tid 100000 ]
Stopped at      kdb_enter+0x32: movq    $0,0xe3cf53(%rip)
db>

I can leave this machine in this state for a few hours, so if there's
any diagnostic information to be gained, I'm happy to do that, but I'll
need clues as to what to do.

If I can get a dump, I'm happy to make it available (but I'll hold off
on trying that for now, as I expect the attempt could disturb evidence).

Information about the machine(s) & update history may be found at
https://www.catwhisker.org/~david/FreeBSD/history/ in case that's
of use.  (This includes a copy of /var/run/dmesg.boot from the last
successful verbose boot, which was from yesterday.)

Peace,
david
-- 
David H. Wolfskill                              david@catwhisker.org
The notion that anyone would perceive a need to "make neo-Nazis
look bad" is about as absurd as perceiving a need to "hydrate" water.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.