Page MenuHomeFreeBSD

iwx: Take the iwx lock in the resume path
Needs ReviewPublic

Authored by thj on Mon, Apr 14, 1:49 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Apr 20, 12:17 AM
Unknown Object (File)
Sat, Apr 19, 7:22 PM
Unknown Object (File)
Sat, Apr 19, 2:14 PM
Unknown Object (File)
Sat, Apr 19, 2:05 PM
Unknown Object (File)
Thu, Apr 17, 6:41 AM
Unknown Object (File)
Thu, Apr 17, 2:45 AM
Unknown Object (File)
Thu, Apr 17, 2:10 AM
Unknown Object (File)
Wed, Apr 16, 10:52 PM
This revision needs review, but there are no reviewers specified.

Details

Reviewers
None
Summary

First try at resolving a lock for resume. I plan to iterate on this in this
review, but first I am using it to get external help testing resume. I'm trying
to find hardwar that will resume pre-iwx, but nothing is agreeable today.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 63503
Build 60387: arc lint + arc unit

Event Timeline

thj requested review of this revision.Mon, Apr 14, 1:49 PM

Okay, so, with this applied on top of D49759, resuming with wlan0 configured and up results in:

iwx0: fatal firmware error
iwx0: could not update sta (error 35)
iwx0: could not flush Tx path (error 35)
panic: INIT state change failed
cpuid = 1
time = 1744663188
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00fb2d8c60
vpanic() at vpanic+0x136/frame 0xfffffe00fb2d8d90
panic() at panic+0x43/frame 0xfffffe00fb2d8df0
ieee80211_newstate_cb() at ieee80211_newstate_cb+0x435/frame 0xfffffe00fb2d8e40
taskqueue_run_locked() at taskqueue_run_locked+0x1c2/frame 0xfffffe00fb2d8ec0
taskqueue_thread_loop() at taskqueue_thread_loop+0xd3/frame 0xfffffe00fb2d8ef0
fork_exit() at fork_exit+0x82/frame 0xfffffe00fb2d8f30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00fb2d8f30

FWIW, this is Latitude 7280, those are <$100 on eBay and a worthy replacement for x240 as a small secondary terminal thing.

If I do "doas /etc/rc.d/netif stop" before suspending, it survives the resume, but trying to "netif start" afterwards results in either a hard wedge, or:

panic: iwx_init_fw_sec
cpuid = 1
time = 1744665442
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00d7c66a80
vpanic() at vpanic+0x136/frame 0xfffffe00d7c66bb0
panic() at panic+0x43/frame 0xfffffe00d7c66c10
iwx_init_fw_sec() at iwx_init_fw_sec+0x52e/frame 0xfffffe00d7c66c70
iwx_run_init_mvm_ucode() at iwx_run_init_mvm_ucode+0xdf0/frame 0xfffffe00d7c66d60
iwx_init_hw() at iwx_init_hw+0x1b/frame 0xfffffe00d7c66e00
iwx_parent() at iwx_parent+0x131/frame 0xfffffe00d7c66e40
taskqueue_run_locked() at taskqueue_run_locked+0x1c2/frame 0xfffffe00d7c66ec0
taskqueue_thread_loop() at taskqueue_thread_loop+0xd3/frame 0xfffffe00d7c66ef0
fork_exit() at fork_exit+0x82/frame 0xfffffe00d7c66f30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00d7c66f30

Same thing happens when I boot with wlan0 unconfigured, then suspend/resume, and then try to configure the interface.

The "panic: iwx_init_fw_sec" panic happens because iwx_resume() calls iwx_init_hw(), but doesn't set IWX_FLAG_HW_INITED, so later when iwx_parent() runs it calls iwx_init() again. If I comment out all of iwx_resume(), I can do "netif stop", then suspend, resume, then "netif start" and that makes WiFi work again \o/

When, instead of commenting out iwx_resume(), I made it set IWX_FLAG_HW_INITED, it resulted in messages about "failing to scan", and generally not working (but not panicing either). Manual "netif restart" made it work again.