Bug 243876
| Summary: | panic: deadlres_td_sleep_q: possible deadlock detected for 0xfffffd0000eff000, blocked for 1800305 ticks | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Bob Prohaska <fbsd> |
| Component: | arm | Assignee: | freebsd-arm (Nobody) <freebsd-arm> |
| Status: | Open --- | ||
| Severity: | Affects Only Me | CC: | cy, fbsd, grahamperrin, markj, rz-rpi03 |
| Priority: | --- | Keywords: | crash |
| Version: | CURRENT | ||
| Hardware: | arm64 | ||
| OS: | Any | ||
I think there were some mailing list threads about this? Was it ever resolved, or is it still reproducible? If it still occurs, please show output from db> show thread <addr> Thread XXXXXX at <addr> ... db> thread XXXXXX db> bt where <addr> is the address from the panic message. |
Apologies if this is duplicate, first observation was on January 23, 2020 A Pi3 running -current (initially at r356835) persistently crashes during buildworld, reporting: panic: deadlres_td_sleep_q: possible deadlock detected for 0xfffffd0000eff000, blocked for 1800305 ticks cpuid = 0 time = 1579775738 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc = 0xffff0000007392dc lr = 0xffff000000106814 sp = 0xffff0000520ce580 fp = 0xffff0000520ce790 db_trace_self_wrapper() at vpanic+0x194 pc = 0xffff000000106814 lr = 0xffff00000040968c sp = 0xffff0000520ce7a0 fp = 0xffff0000520ce850 vpanic() at panic+0x44 pc = 0xffff00000040968c lr = 0xffff000000409434 sp = 0xffff0000520ce860 fp = 0xffff0000520ce8e0 panic() at deadlkres+0x2f8 pc = 0xffff000000409434 lr = 0xffff0000003a480c sp = 0xffff0000520ce8f0 fp = 0xffff0000520ce940 deadlkres() at fork_exit+0x7c pc = 0xffff0000003a480c lr = 0xffff0000003c8a0c sp = 0xffff0000520ce950 fp = 0xffff0000520ce980 fork_exit() at fork_trampoline+0x10 pc = 0xffff0000003c8a0c lr = 0xffff000000755b3c sp = 0xffff0000520ce990 fp = 0x0000000000000000 KDB: enter: panic [ thread pid 0 tid 100052 ] Stopped at 0 db> db> bt Tracing pid 0 tid 100052 td 0xfffffd0000ce8560 db_trace_self() at db_stack_trace+0xf8 pc = 0xffff0000007392dc lr = 0xffff000000103c58 sp = 0xffff0000520ce150 fp = 0xffff0000520ce180 db_stack_trace() at db_command+0x228 pc = 0xffff000000103c58 lr = 0xffff0000001038d0 sp = 0xffff0000520ce190 fp = 0xffff0000520ce270 db_command() at db_command_loop+0x58 pc = 0xffff0000001038d0 lr = 0xffff000000103678 sp = 0xffff0000520ce280 fp = 0xffff0000520ce2a0 db_command_loop() at db_trap+0xf4 pc = 0xffff000000103678 lr = 0xffff00000010697c sp = 0xffff0000520ce2b0 fp = 0xffff0000520ce4d0 db_trap() at kdb_trap+0x1d8 pc = 0xffff00000010697c lr = 0xffff000000450af8 sp = 0xffff0000520ce4e0 fp = 0xffff0000520ce590 kdb_trap() at do_el1h_sync+0xf4 pc = 0xffff000000450af8 lr = 0xffff000000755db8 sp = 0xffff0000520ce5a0 fp = 0xffff0000520ce5d0 do_el1h_sync() at handle_el1h_sync+0x78 pc = 0xffff000000755db8 lr = 0xffff00000073b878 sp = 0xffff0000520ce5e0 fp = 0xffff0000520ce6f0 handle_el1h_sync() at kdb_enter+0x34 pc = 0xffff00000073b878 lr = 0xffff000000450144 sp = 0xffff0000520ce700 fp = 0xffff0000520ce790 kdb_enter() at vpanic+0x1b0 pc = 0xffff000000450144 lr = 0xffff0000004096a8 sp = 0xffff0000520ce7a0 fp = 0xffff0000520ce850 vpanic() at panic+0x44 pc = 0xffff0000004096a8 lr = 0xffff000000409434 sp = 0xffff0000520ce860 fp = 0xffff0000520ce8e0 panic() at deadlkres+0x2f8 pc = 0xffff000000409434 lr = 0xffff0000003a480c sp = 0xffff0000520ce8f0 fp = 0xffff0000520ce940 deadlkres() at fork_exit+0x7c pc = 0xffff0000003a480c lr = 0xffff0000003c8a0c sp = 0xffff0000520ce950 fp = 0xffff0000520ce980 fork_exit() at fork_trampoline+0x10 pc = 0xffff0000003c8a0c lr = 0xffff000000755b3c sp = 0xffff0000520ce990 fp = 0x0000000000000000 db> The panic can also be triggered after a prompt hang by invoking kldload mac_ntpd The machine freezes initially, but panics after a delay of some minutes.