Re: db> reset -> panic: acquiring blockable sleep lock with spinlock or critical section held ...
- Reply: Bjoern A. Zeeb: "Re: db> reset -> panic: acquiring blockable sleep lock with spinlock or critical section held ..."
- In reply to: Bjoern A. Zeeb: "db> reset -> panic: acquiring blockable sleep lock with spinlock or critical section held ..."
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 20 Nov 2023 18:21:19 UTC
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: > >