Bug 286059 - iwx(4): panic on resume, "iwx0 not locked"
Summary: iwx(4): panic on resume, "iwx0 not locked"
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 15.0-CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: Tom Jones
URL:
Keywords:
Depends on:
Blocks: 278175
  Show dependency treegraph
 
Reported: 2025-04-12 13:03 UTC by Edward Tomasz Napierala
Modified: 2025-04-22 20:15 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Edward Tomasz Napierala freebsd_committer freebsd_triage 2025-04-12 13:03:09 UTC
When resuming from S3 suspend, the iwx(4) driver (on 15-CURRENT with https://reviews.freebsd.org/D49759, wouldn't attach otherwise) panics like this:

panic: lock (sleep mutex) iwx0 not locked @ /usr/home/trasz/git/freebsd-src/sys/dev/iwx/if_iwx.c: 4012
cpuid = 2
time = 1744390217
KDB: stack backtrace:
db_trace_self_rapper () at db_trace_self_urapper+0x2b/frame ßxfffffe00fb36e510
vpanic() at vpanic+0x136/frame 0xfffffe00fb36e640
panic() at panic+0x43/frame 0xfffffe00fb3бeбa0
witness_unlock() at witness_unlock+x154/frame 0xfffffe00fb3бe6d0 _mtx_unlock_flags() at -_mtx_unlock_flags+0x3f/frame ßxfffffe00fb3бe6fĐ
iwx_run_init_mvm_ucode() at iwx_run_init_mvm_ucode+0x82/frame Oxfffffe00fb36e7el
iux_init_hu() at iux_init_hu+0xlb/frame Bxfffffe00fb36eB80
lux_resume() at iux_resume+0x22/frame Bxfffffe00fb3бeBa0
bus_gener ic_resume_child() at bus_generic_resume_child+0x3d/frame Axfffffe0@fb36eBc®
pci_resume_child() at pci_resume_child+Bx6b/frame Bxfffffe00fb36eßf0
pci_resume() at pci_resume+0x117/frame Bxfffffe00fb3бe940
bus_gener ic_resume_child() at bus_generic_resume_child+0x3d/frame 0xfffffe00fb36960
bus_gener ic_resume() at bus_generic_resume+0x29/frame Oxfffffe00fb36980
pcib_resume() at pcib_resume+Bxcb/frame 0xfffffe00fb36e9b0
bus_gener ic_resume_child() at bus_gener ic_resume_child+0x3d/frame xfffffeD0fb359d0
pci_resume_child) at pci_resume_child+0x6b/frame 0xfffffe00fb36ea00
pci_resume() at pci_resume+0x49/frame 0xfffffe00fb36ea50
bus_generic_resume_child() at bus_generic_resume_child+0x3d/frame Bxfffffe00fb3бea70
bus_gener ic_resume() at bus_generic_resume+0x29/frame 0xfffffe0@fb36ea90
bus_gener ic_resume_child) at bus_generic_resume_child+0x3d/frame Oxfffffeu@fb36eabl
bus_generic_resume() at bus_generic_resume+0x29/frame 0xfffffe00fb36ead®
bus_gener ic_resume_child() at bus_generic_resume_child+0x3d/frame 0xfffffe00fb36eafO
bus_generic_resume() at bus_generic_resume+0x29/frame 0xfffffe00fb35eb10
bus_gener ic_resume_child() at bus_generic_resume_child+0x3d/frame Oxfffffe00fb36eb30
root_resume() at root_resume+0x29/frame 0xfffffe00fb36eb50
acpi_EnterSleepState() at acpi_EnterSleepState+0x7d2/frame 0xfffffe00fb36ebd0
acpi_AckSleepState() at acpi_AckSleepState+0x131/frame @xfffffe00fb36ec00
devfs_ioctl() at devfs_ioctl+0xd1/frame Axfffffe00fb36ec50
vn_locti( at vn_ioctl+0xb6/frame @xfffffe00fb3бecc0
devfs_ioctl_f() at devfs_ioctl_f+Bxle/frame Bxfffffe00fb36ece0
kern_ioctl() at kern_ioctl+0x286/frame 0xfffffe00fb36ed40
sys_ioctl() at sys_ioctl+0x12f/frame 0xfffffe00fb3бeeß0
amd64_syscall() at amd64_syscal 1+0x15a/frame 0xfffffe00fb36ef30

(Note the traceback is OCR-ed.)

When it panics, the system is _very_ slow, you can see characters being output one by one.  Crashdumps don't work either; interrupt problem?  The panic doesn't happen if if_iwx(4) is not loaded.
Comment 1 Edward Tomasz Napierala freebsd_committer freebsd_triage 2025-04-12 14:28:56 UTC
Probably unrelated, but there's also this LOR reported upon boot; it doesn't appear to be breaking anything though?

lock order reversal:
 1st 0xfffffe00fbb66058 iwx0_tx_lock (iwx0_tx_lock, sleep mutex) @ /usr/home/trasz/git/freebsd-src/sys/net80211/ieee80211_output.c:1038
 2nd 0xfffffe00fbbed3b0 iwx0 (network driver, sleep mutex) @ /usr/home/trasz/git/freebsd-src/sys/dev/iwx/if_iwx.c:10777
lock order iwx0_tx_lock -> network driver attempted at:
#0 0xffffffff80bce791 at witness_checkorder+0xbe1
#1 0xffffffff80b312b1 at __mtx_lock_flags+0x91
#2 0xffffffff83d3c896 at iwx_raw_xmit+0x36
#3 0xffffffff80d0b26b at ieee80211_mgmt_output+0x1eb
#4 0xffffffff80d0d0fa at ieee80211_send_mgmt+0xc0a
#5 0xffffffff80d19ff4 at sta_newstate+0x5e4
#6 0xffffffff83d40e2d at iwx_newstate+0xa4d
#7 0xffffffff80d112cc at ieee80211_newstate_cb+0x29c
#8 0xffffffff80bc0d12 at taskqueue_run_locked+0x1c2
#9 0xffffffff80bc1bd3 at taskqueue_thread_loop+0xd3
#10 0xffffffff80b0abd2 at fork_exit+0x82
#11 0xffffffff81069afe at fork_trampoline+0xe
Comment 2 Tom Jones freebsd_committer freebsd_triage 2025-04-14 08:36:54 UTC
Thanks! 

It is great to have an example from a system where suspend already works. My test devices don't like coming back from naps. 

The panic message is related to firmware not getting an internal lock, I will see what might be missing from OpenBSD to get this working.
Comment 3 Tom Jones freebsd_committer freebsd_triage 2025-04-14 13:50:39 UTC
I was wrong about the panic and it might just be a driver one. Could you try this patch for me?

I don't have hardware that will resume pre-iwx so its not possible for me to test.

https://reviews.freebsd.org/D49827