Re: After update to main-n266611-49a83b94395a: panic: bus_generic_rman_activate_resource
- Reply: David Wolfskill : "Re: After update to main-n266611-49a83b94395a: panic: bus_generic_rman_activate_resource"
- Reply: David Wolfskill : "Re: [resolved] After update to main-n266611-49a83b94395a: panic: bus_generic_rman_activate_resource"
- In reply to: David Wolfskill : "After update to main-n266611-49a83b94395a: panic: bus_generic_rman_activate_resource"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 25 Nov 2023 19:36:33 UTC
Hi. Not tested, but does upgrading to commit ed88eef140a1 [1] and later help? (I'm still at commit 5d4f897f88ed on main.) [1] https://cgit.freebsd.org/src/commit/?id=ed88eef140a1c3d57d546f409c216806dd3da809 Regards. On Sat, 25 Nov 2023 05:45:24 -0800 David Wolfskill <david@catwhisker.org> wrote: > 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. -- Tomoaki AOKI <junchoon@dec.sakura.ne.jp>