Re: kern/58761: bwi(4): reproducible panic: kernel diagnostic assertion "ci->ci_mtx_count == -1" failed

[Andrius V <vezhlys%gmail.com@localhost>]

The following reply was made to PR kern/58761; it has been noted by GNATS.

From: Andrius V <vezhlys%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/58761: bwi(4): reproducible panic: kernel diagnostic
 assertion "ci->ci_mtx_count == -1" failed
Date: Fri, 3 Jan 2025 16:32:01 +0200

 On Sun, Oct 20, 2024 at 1:10=E2=80=AFAM <vezhlys%gmail.com@localhost> wrote:
 >
 > >Number:         58761
 > >Category:       kern
 > >Synopsis:       bwi(4): reproducible panic: kernel diagnostic assertion =
 "ci->ci_mtx_count =3D=3D -1" failed
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       medium
 > >Responsible:    kern-bug-people
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   net
 > >Arrival-Date:   Sat Oct 19 22:10:01 +0000 2024
 > >Originator:     Andrius V
 > >Release:        NetBSD 10.99.12
 > >Organization:
 > >Environment:
 > NetBSD 10.99.12 (VT-310DP) #2: Sat Oct 19 23:17:54 EEST 2024 i386
 > >Description:
 > I have a Buffalo AirStation wireless-g wifi card on cardbus which is atta=
 ched to a PCI cardbus adapter. NetBSD successfully attaches bfi(4) interfac=
 e with the required firmware copied to the system. dhcpcd successfully assi=
 gns IP address and network is working. However, system crashes as soon as I=
  call ifconfig bwi0 down. System is VIA C3 i386 based system. Reproducible =
 each time. Tested on the latest netbsd current code at time of writing only=
 . Will do checks on older releases later.
 >
 > panic: kernel diagnostic assertion "ci->ci_mtx_count =3D=3D -1" failed: f=
 ile "/home/andriusv/netbsd-src-git/sys/kern/kern_synch.c", line 762 mi_swit=
 ch: cpu0: ci_mtx_count (-2) !=3D -1 (block with spin-mutex held)
 > cpu0: Begin traceback...
 > vpanic(c0fe1c98,dd3179f0,dd317a38,c0a5e139,c0fe1c98,c0efe1c7,c0fe1f5c,c0f=
 e1ac4,2fa,c0ee15a0) at netbsd:vpanic+0x176
 > kern_assert(c0fe1c98,c0efe1c7,c0fe1f5c,c0fe1ac4,2fa,c0ee15a0,0,fffffffe,c=
 0a593ab,c0a6ca50) at netbsd:kern_assert+0x23
 > mi_switch(c639cb40,4,0,0,0,c0f2d3d6,c38c26b8,c38c26b8,c38c26c0,2) at netb=
 sd:mi_switch+0x77e
 > sleepq_block(4,0,c0ee0920,2,0,c11d4740,c38c2580,4,db952000,dd317af4) at n=
 etbsd:sleepq_block+0x207
 > cv_timedwait(c38c26b8,c38c26c0,4,400,cfc,dd317ae4,c38c26b8,3,c38c26c0,4) =
 at netbsd:cv_timedwait+0xe3
 > pccbb_power(c38c2580,4,dd317b0b,c031b22b,c3e30000,80,c3e6b380,dd317b20,c0=
 31782a,dd317b84) at netbsd:pccbb_power+0x230
 > disable_function(dd317b84,c057368c,c3d7df40,0,b540e2,4d0,c0a94ab9,0,1e,1)=
  at netbsd:disable_function+0x71
 > cardbus_function_disable(c3d7df40,0,b540e2,4d0,c0a94ab9,0,1e,1,c3e30244,f=
 fffffff) at netbsd:cardbus_function_disable+0xe
 > bwi_init_statechg(c3e30004,c3e30a90,dd317bb8,c0b6840b,c3e30004,6,0,10003,=
 c3e30a90,c3e30a90) at netbsd:bwi_init_statechg+0x20
 > bwi_media_change(c3e30004,6,0,10003,c3e30a90,c3e30a90,c3e30a90,dd317bec,c=
 0b68a2d,c3e30a90) at netbsd:bwi_media_change+0x38
 > ifmedia_change(c3e30a90,c3e30004,0,c0b448aa,0,c3886ac0,c3e6b380,80,c3e302=
 44,c3e30004) at netbsd:ifmedia_change+0x31
 > ifmedia_ioctl(c3e30004,c4074d00,c3e30a90,c0906937,dd317c2c,dd317c94,0,bfb=
 535b0,dd317c2c,c6124cf0) at netbsd:ifmedia_ioctl+0x231
 > ieee80211_ioctl(c3e30244,c0906937,c4074d00,c0a1532d,4,c11a7f40,c3e30244,c=
 639cb40,c3e30004,c0906937) at netbsd:ieee80211_ioctl+0x4ef
 > bwi_ioctl(c3e30004,c0906937,c4074d00,14,c3e30004,c0906937,0,7,c4074d00,88=
 43) at netbsd:bwi_ioctl+0xd8
 > doifioctl(c6464050,c0906937,c4074d00,c639cb40,c4074d00,1,c42019c0,c090693=
 7,dd317e6c,c0a86b4b) at netbsd:doifioctl+0x876
 > soo_ioctl(c42019c0,c0906937,c4074d00,c0a64747,c11a7660,c639cb40,0,4af,c09=
 06937,c4074d00) at netbsd:soo_ioctl+0x11c
 > sys_ioctl(c639cb40,dd317f68,dd317f60,ffffffff,0,dd317f60,c11baa58,36,0,0)=
  at netbsd:sys_ioctl+0x2c3
 > syscall() at netbsd:syscall+0x10f
 > --- syscall (number 54) ---
 >
 To add to my original report, this issue is triggered by wpa_supplicant rat=
 her
 than specifically by the "bringing the interface down" operation
 (it can occur during any media status change).
 
 When wpa_supplicant is disabled, performing ifconfig bwi0 down/up does
 not cause a crash.
 However, the ifconfig bwi0 down operation appears to trigger some
 wpa_supplicant activity,
 with the utility potentially holding a spin mutex before invoking
 pccbb_power and cv_timedwait,
 which leads to the assertion failure mentioned above.