Re: Can't enable SDIO wifi module on PBP
- In reply to: KIRIYAMA Kazuhiko : "Can't enable SDIO wifi module on PBP"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 04 Jun 2021 19:34:48 UTC
On 2021-Jun-4, at 04:07, KIRIYAMA Kazuhiko <kiri at truefc.org> wrote: I do not make any claim that the below notes are tied to any sufficient changes to enable SDIO wifi. They may be more general/generic. > . . . > uma_zalloc_debug: zone "malloc-2048" with the following non-sleepable locks held: > exclusive sleep mutex SD slot mtx (sdhci) r = 0 (0xffff0000411c6030) locked @ /usr/src/sys/dev/sdhci/sdhci.c:617 > stack backtrace: > #0 0xffff0000004d819c at witness_debugger+0x64 > #1 0xffff0000004d9320 at witness_warn+0x3e8 > #2 0xffff0000006f9084 at uma_zalloc_debug+0x2c > #3 0xffff0000006f8a8c at uma_zalloc_arg+0x2c > #4 0xffff00000043fa18 at malloc+0xa0 > #5 0xffff00000000f550 at xpt_alloc_ccb+0x1c > #6 0xffff000000034ee0 at mmccam_start_discovery+0x18 > #7 0xffff0000002506fc at sdhci_card_task+0x110 > #8 0xffff000000255460 at sdhci_fdt_attach+0x5b4 > #9 0xffff0000004a3b34 at device_attach+0x400 > #10 0xffff0000004a369c at device_probe_and_attach+0x7c > #11 0xffff0000004a5880 at bus_generic_new_pass+0xf8 > #12 0xffff0000004a5830 at bus_generic_new_pass+0xa8 > #13 0xffff0000004a5830 at bus_generic_new_pass+0xa8 > #14 0xffff0000004a0ae0 at bus_set_pass+0x4c > #15 0xffff0000003f644c at mi_startup+0x12c > #16 0xffff0000000008a8 at virtdone+0x6c The above may be a problem that needs to be fixed overall. > . . . > lock order reversal: (sleepable after non-sleepable) > 1st 0xffffa00001026558 dwmmcsim (dwmmcsim, sleep mutex) @ /usr/src/sys/cam/cam_xpt.c:2802 > 2nd 0xffff000000c12a30 Clock topology lock (Clock topology lock, sx) @ /usr/src/sys/dev/extres/clk/clk.c:1154 > lock order dwmmcsim -> Clock topology lock attempted at: > #0 0xffff0000004d7e7c at witness_checkorder+0xc50 > #1 0xffff0000004743e8 at _sx_xlock+0x7c > #2 0xffff0000001ac808 at clk_set_freq+0x4c > #3 0xffff00000078a998 at dwmmc_rockchip_update_ios+0x3c > #4 0xffff00000078a3bc at dwmmc_update_ios+0xfc > #5 0xffff000000789854 at dwmmc_cam_action+0x14c > #6 0xffff000000009c34 at xpt_action_default+0xca8 > #7 0xffff000000008f5c at xpt_action+0x270 > #8 0xffff00000003633c at mmcprobe_start+0x89c > #9 0xffff00000000cc10 at xpt_run_allocq+0x104 > #10 0xffff00000000cadc at xpt_schedule+0x230 > #11 0xffff000000035a78 at mmcprobe_register+0x2a4 > #12 0xffff000000003b90 at cam_periph_alloc+0x528 > #13 0xffff0000000354dc at mmc_action+0x484 > #14 0xffff000000008f5c at xpt_action+0x270 > #15 0xffff000000011750 at xpt_scanner_thread+0xcc > #16 0xffff000000424198 at fork_exit+0x74 > #17 0xffff00000076716c at fork_trampoline+0x14 > The above may be another problem that needs to be fixed overall. These lock reports do not look like the typical "just ignore the message" ones. (But I'm not competent to make the actual judgement of status.) > . . . === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)