Date: Mon, 20 Nov 2023 14:21:19 -0400 From: Mitchell Horne <mhorne@freebsd.org> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, current@freebsd.org Subject: Re: db> reset -> panic: acquiring blockable sleep lock with spinlock or critical section held ... Message-ID: <2b0ef12f-a158-4de3-8d25-ad2e5fcde644@freebsd.org> In-Reply-To: <0q526858-7s33-27qo-6q80-8o1q10415q2s@yvfgf.mnoonqbm.arg>
index | next in thread | previous in thread | raw e-mail
On 11/16/23 18:21, Bjoern A. Zeeb wrote: > Hi, > > I seem to remember changes related to that a while ago but my cache > is miss for the actual change. Are we suppoed to handle this case? > > It would be nice if "reset" would reset again the first time ... > Hi Bjoern, This is still my fault, I am sorry to say. If you recall, I proposed a fix after your initial report (back in February!), see https://reviews.freebsd.org/D38656. However, I held off on committing it because I had some more work to do in the area, and believed there was a more correct way to fix this edge-case. I posted what I believe to be the better fix just now, see https://reviews.freebsd.org/D42684. I will commit this ASAP along with some other tweaks to shutdown hooks which should (loaded word) eliminate this type of recursive panic during debugger reset. At least, that is the goal of the series :) I apologize for the delay on this, my ability to finish some of the work I've started has been spotty this year. Cheers, Mitchell > > KDB: enter: Break to debugger > [ thread pid 11 tid 100005 ] > Stopped at kdb_alt_break_internal+0x180: str xzr, [x19, #896] > db> reset > panic: acquiring blockable sleep lock with spinlock or critical section > held (sleep mutex) eventhandler @ /usr/src/sys/kern/subr_eventhandler.c:269 > cpuid = 2 > time = 307 > KDB: stack backtrace: > db_trace_self() at db_trace_self > db_trace_self_wrapper() at db_trace_self_wrapper+0x38 > vpanic() at vpanic+0x1a0 > panic() at panic+0x48 > witness_checkorder() at witness_checkorder+0xb4c > __mtx_lock_flags() at __mtx_lock_flags+0xac > eventhandler_find_list() at eventhandler_find_list+0x44 > kern_reboot() at kern_reboot+0x284 > db_reset() at db_reset+0xd8 > db_command() at db_command+0x2e4 > db_command_loop() at db_command_loop+0x58 > db_trap() at db_trap+0x100 > kdb_trap() at kdb_trap+0x364 > handle_el1h_sync() at handle_el1h_sync+0x18 > --- exception, esr 0xf2000000 > kdb_alt_break_internal() at kdb_alt_break_internal+0x180 > kdb_alt_break() at kdb_alt_break+0x10 > uart_intr_rxready() at uart_intr_rxready+0x8c > uart_intr() at uart_intr+0x120 > intr_event_handle() at intr_event_handle+0xf4 > intr_isrc_dispatch() at intr_isrc_dispatch+0x78 > arm_gic_v3_intr() at arm_gic_v3_intr+0x120 > intr_irq_handler() at intr_irq_handler+0x88 > handle_el1h_irq() at handle_el1h_irq+0x14 > --- interrupt > cpu_idle() at cpu_idle+0x78 > sched_idletd() at sched_idletd+0x4a0 > fork_exit() at fork_exit+0x78 > fork_trampoline() at fork_trampoline+0x18 > KDB: enter: panic > [ thread pid 11 tid 100005 ] > Stopped at kdb_enter+0x48: str xzr, [x19, #896] > db> reset > Uptime: 5m7s > INFO: PSCI Power Domain Map: > >help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2b0ef12f-a158-4de3-8d25-ad2e5fcde644>