panic: deadlres_td_sleep_q: possible deadlock detected on RPI3

[Mark Millard]

On 2020-Jan-30, at 17:29, bob prohaska <fbsd at www.zefox.net> wrote:

> On Thu, Jan 30, 2020 at 11:24:19AM -0800, Mark Millard wrote:
>> 
>> If you want to risk crashing/hanging-up the machine, you could
>> try to "kldload mac_ntpd" and see if it loads well or not.
>> 
>> 
> That produced a prompt hang with no output at all. The backtrace reports:
> 
> KDB: enter: Break to debugger
> [ thread pid 1116 tid 100085 ]
> Stopped at      0x4031ed44
> db> bt
> Tracing pid 1116 tid 100085 td 0xfffffd0001020000
> db_trace_self() at db_stack_trace+0xf8
>         pc = 0xffff00000073c55c  lr = 0xffff000000103c58
>         sp = 0xffff00005a4bc830  fp = 0xffff00005a4bc860
> 
> db_stack_trace() at db_command+0x228
>         pc = 0xffff000000103c58  lr = 0xffff0000001038d0
>         sp = 0xffff00005a4bc870  fp = 0xffff00005a4bc950
> 
> db_command() at db_command_loop+0x58
>         pc = 0xffff0000001038d0  lr = 0xffff000000103678
>         sp = 0xffff00005a4bc960  fp = 0xffff00005a4bc980
> 
> db_command_loop() at db_trap+0xf4
>         pc = 0xffff000000103678  lr = 0xffff00000010697c
>         sp = 0xffff00005a4bc990  fp = 0xffff00005a4bcbb0
> 
> db_trap() at kdb_trap+0x1d8
>         pc = 0xffff00000010697c  lr = 0xffff0000004510a0
>         sp = 0xffff00005a4bcbc0  fp = 0xffff00005a4bcc70
> 
> kdb_trap() at do_el1h_sync+0xf4
>         pc = 0xffff0000004510a0  lr = 0xffff000000759568
>         sp = 0xffff00005a4bcc80  fp = 0xffff00005a4bccb0
> 
> do_el1h_sync() at handle_el1h_sync+0x78
>         pc = 0xffff000000759568  lr = 0xffff00000073f078
>         sp = 0xffff00005a4bccc0  fp = 0xffff00005a4bcdd0
> 
> handle_el1h_sync() at kdb_alt_break_internal+0x130
>         pc = 0xffff00000073f078  lr = 0xffff000000450858
>         sp = 0xffff00005a4bcde0  fp = 0xffff00005a4bce80
> 
> kdb_alt_break_internal() at kdb_alt_break+0xc
>         pc = 0xffff000000450858  lr = 0xffff000000450718
>         sp = 0xffff00005a4bce90  fp = 0xffff00005a4bce90
> 
> kdb_alt_break() at uart_intr_rxready+0x88
>         pc = 0xffff000000450718  lr = 0xffff000000263124
>         sp = 0xffff00005a4bcea0  fp = 0xffff00005a4bcec0
> 
> uart_intr_rxready() at uart_intr+0xec
>         pc = 0xffff000000263124  lr = 0xffff000000263e0c
>         sp = 0xffff00005a4bced0  fp = 0xffff00005a4bcf00
> 
> uart_intr() at intr_event_handle+0xc8
>         pc = 0xffff000000263e0c  lr = 0xffff0000003cbaf4
>         sp = 0xffff00005a4bcf10  fp = 0xffff00005a4bcf50
> 
> intr_event_handle() at intr_isrc_dispatch+0x34
>         pc = 0xffff0000003cbaf4  lr = 0xffff00000078faa4
>         sp = 0xffff00005a4bcf60  fp = 0xffff00005a4bcf70
> 
> intr_isrc_dispatch() at bcm2835_intc_intr+0xa8
>         pc = 0xffff00000078faa4  lr = 0xffff000000729a50
>         sp = 0xffff00005a4bcf80  fp = 0xffff00005a4bcfc0
> 
> bcm2835_intc_intr() at intr_event_handle+0xc8
>         pc = 0xffff000000729a50  lr = 0xffff0000003cbaf4
>         sp = 0xffff00005a4bcfd0  fp = 0xffff00005a4bd010
> 
> intr_event_handle() at intr_isrc_dispatch+0x34
>         pc = 0xffff0000003cbaf4  lr = 0xffff00000078faa4
>         sp = 0xffff00005a4bd020  fp = 0xffff00005a4bd030
> 
> intr_isrc_dispatch() at bcm_lintc_intr+0x1e8
>         pc = 0xffff00000078faa4  lr = 0xffff00000072fc88
>         sp = 0xffff00005a4bd040  fp = 0xffff00005a4bd0c0
> 
> bcm_lintc_intr() at intr_irq_handler+0x74
>         pc = 0xffff00000072fc88  lr = 0xffff00000078f904
>         sp = 0xffff00005a4bd0d0  fp = 0xffff00005a4bd0f0
> 
> intr_irq_handler() at handle_el1h_irq+0x74
>         pc = 0xffff00000078f904  lr = 0xffff00000073f140
>         sp = 0xffff00005a4bd100  fp = 0xffff00005a4bd210
> 
> handle_el1h_irq() at rms_wlock+0x124
>         pc = 0xffff00000073f140  lr = 0xffff000000403fc4
>         sp = 0xffff00005a4bd220  fp = 0xffff00005a4bd2b0
> 
> rms_wlock() at rms_wlock+0x124
>         pc = 0xffff000000403fc4  lr = 0xffff000000403fc4
>         sp = 0xffff00005a4bd2c0  fp = 0xffff00005a4bd360
> 
> rms_wlock() at mac_policy_modevent+0xc0
>         pc = 0xffff000000403fc4  lr = 0xffff00000066ba44
>         sp = 0xffff00005a4bd370  fp = 0xffff00005a4bd3c0
> 
> mac_policy_modevent() at module_register_init+0xc4
>         pc = 0xffff00000066ba44  lr = 0xffff0000003e783c
>         sp = 0xffff00005a4bd3d0  fp = 0xffff00005a4bd400
> 
> module_register_init() at linker_load_module+0xab8
>         pc = 0xffff0000003e783c  lr = 0xffff0000003d8670
>         sp = 0xffff00005a4bd410  fp = 0xffff00005a4bd740
> 
> linker_load_module() at kern_kldload+0xec
>         pc = 0xffff0000003d8670  lr = 0xffff0000003d9e40
>         sp = 0xffff00005a4bd750  fp = 0xffff00005a4bd780
> 
> kern_kldload() at sys_kldload+0x64
>         pc = 0xffff0000003d9e40  lr = 0xffff0000003d9f98
>         sp = 0xffff00005a4bd790  fp = 0xffff00005a4bd7b0
> 
> sys_kldload() at do_el0_sync+0x514
>         pc = 0xffff0000003d9f98  lr = 0xffff000000759bf4
>         sp = 0xffff00005a4bd7c0  fp = 0xffff00005a4bd860
> 
> do_el0_sync() at handle_el0_sync+0x90
>         pc = 0xffff000000759bf4  lr = 0xffff00000073f224
>         sp = 0xffff00005a4bd870  fp = 0xffff00005a4bd980
> 
> handle_el0_sync() at 0x210368
>         pc = 0xffff00000073f224  lr = 0x0000000000210368
>         sp = 0xffff00005a4bd990  fp = 0x0000ffffffffeaf0
> 
> db> 

This would be good to submit as a comment to:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243464

adding with notes about the context (versions and such)
and that other kernel modules loaded without such problems.
I'd guess that you are not using ZFS, in which case that
forms a good contrast with the original submittal in that
respect.

Although, it might be good to try some other kernel module
for manual loading to see if the problem repeats and to
note the result.

From what you and others have reported, head -r356776 and
later do seem to have some aarch64 problems, at least on
RPi3's.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)