Discussion:
kern/138427: [wpi] [panic] Kernel panic after trying set monitor wlanmode on Intel 3945 ABG (wpi driver)
(too old to reply)
Henry Hu
2010-03-25 15:50:06 UTC
Permalink
The following reply was made to PR kern/138427; it has been noted by GNATS.

From: Henry Hu <***@gmail.com>
To: bug-***@FreeBSD.org, ***@simplusnet.pl
Cc:
Subject: Re: kern/138427: [wpi] [panic] Kernel panic after trying set monitor
wlanmode on Intel 3945 ABG (wpi driver)
Date: Thu, 25 Mar 2010 23:40:26 +0800

Me too. backtrace:


(kgdb) where
#0 doadump () at pcpu.h:246
#1 0xc0637af7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416
#2 0xc0637e02 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:579
#3 0xc08bd983 in trap_fatal (frame=0xf09caaa8, eva=20) at
/usr/src/sys/i386/i386/trap.c:938
#4 0xc08be2b7 in trap (frame=0xf09caaa8) at /usr/src/sys/i386/i386/trap.c:328
#5 0xc08a0bbb in calltrap () at /usr/src/sys/i386/i386/exception.s:165
#6 0xc06736bf in turnstile_broadcast (ts=0x0, queue=0) at
/usr/src/sys/kern/subr_turnstile.c:832
#7 0xc0628129 in _mtx_unlock_sleep (m=0xc6d2b008, opts=0, file=0x0,
line=0) at /usr/src/sys/kern/kern_mutex.c:677
#8 0xc06286c4 in unlock_mtx (lock=0xc6d2b008) at
/usr/src/sys/kern/kern_mutex.c:164
#9 0xc06409e7 in _sleep (ident=0xf0bd1b60, lock=0xc6d2b008,
priority=256, wmesg=0xc8c3a896 "wpicmd", timo=100) at
/usr/src/sys/kern/kern_synch.c:204
#10 0xc8c34369 in wpi_cmd (sc=0xc6d2b000, code=Variable "code" is not available.
) at /usr/src/sys/modules/wpi/../../dev/wpi/if_wpi.c:2210
#11 0xc8c3709b in wpi_config (sc=0xc6d2b000) at
/usr/src/sys/modules/wpi/../../dev/wpi/if_wpi.c:2771
#12 0xc8c374d7 in wpi_set_channel (ic=0xc8c3d000) at
/usr/src/sys/modules/wpi/../../dev/wpi/if_wpi.c:3555
#13 0xc0729913 in update_channel (arg=0xc8c3d000, npending=1) at
/usr/src/sys/net80211/ieee80211_proto.c:1119
#14 0xc06711a2 in taskqueue_run (queue=0xc81dc100) at
/usr/src/sys/kern/subr_taskqueue.c:239
#15 0xc06713ad in taskqueue_thread_loop (arg=0xc8c3d074) at
/usr/src/sys/kern/subr_taskqueue.c:360
#16 0xc060c661 in fork_exit (callout=0xc06712f0
<taskqueue_thread_loop>, arg=0xc8c3d074, frame=0xf09cad38) at
/usr/src/sys/kern/kern_fork.c:843
#17 0xc08a0c30 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270
(kgdb) frame 7
#7 0xc0628129 in _mtx_unlock_sleep (m=0xc6d2b008, opts=0, file=0x0,
line=0) at /usr/src/sys/kern/kern_mutex.c:677
677 turnstile_broadcast(ts, TS_EXCLUSIVE_QUEUE);
(kgdb) l
672 turnstile_chain_lock(&m->lock_object);
673 ts = turnstile_lookup(&m->lock_object);
674 if (LOCK_LOG_TEST(&m->lock_object, opts))
675 CTR1(KTR_LOCK, "_mtx_unlock_sleep: %p contested", m);
676 MPASS(ts != NULL);
677 turnstile_broadcast(ts, TS_EXCLUSIVE_QUEUE);
678 _release_lock_quick(m);
679
680 /*
681 * This turnstile is now no longer associated with the
mutex. We can
(kgdb) p ts
$13 = (struct turnstile *) 0x0
(kgdb) frame 10
#10 0xc8c34369 in wpi_cmd (sc=0xc6d2b000, code=Variable "code" is not available.
) at /usr/src/sys/modules/wpi/../../dev/wpi/if_wpi.c:2210
2210 return msleep(cmd, &sc->sc_mtx, PCATCH, "wpicmd", hz);
(kgdb) l
2205 if (async) {
2206 sc->flags &= ~ WPI_FLAG_BUSY;
2207 return 0;
2208 }
2209
2210 return msleep(cmd, &sc->sc_mtx, PCATCH, "wpicmd", hz);
2211 }
2212
2213 static int
2214 wpi_wme_update(struct ieee80211com *ic)
(kgdb) frame 7
#7 0xc0628129 in _mtx_unlock_sleep (m=0xc6d2b008, opts=0, file=0x0,
line=0) at /usr/src/sys/kern/kern_mutex.c:677
677 turnstile_broadcast(ts, TS_EXCLUSIVE_QUEUE);
(kgdb) p *m
$14 = {lock_object = {lo_name = 0xc655f1a0 "wpi0", lo_flags =
16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 3358744576}
(kgdb) frame 10
#10 0xc8c34369 in wpi_cmd (sc=0xc6d2b000, code=Variable "code" is not available.
) at /usr/src/sys/modules/wpi/../../dev/wpi/if_wpi.c:2210
2210 return msleep(cmd, &sc->sc_mtx, PCATCH, "wpicmd", hz);
(kgdb) p sc->sc_mtx
$15 = {lock_object = {lo_name = 0xc655f1a0 "wpi0", lo_flags =
16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 3358744576}

it seems like turnstile_lookup failed.
The driver works well in normal mode.

--
Cheers,
Henry
Henry Hu
2010-03-25 16:20:06 UTC
Permalink
The following reply was made to PR kern/138427; it has been noted by GNATS.

From: Henry Hu <***@gmail.com>
To: bug-***@FreeBSD.org, ***@simplusnet.pl
Cc:
Subject: Re: kern/138427: [wpi] [panic] Kernel panic after trying set monitor
wlanmode on Intel 3945 ABG (wpi driver)
Date: Fri, 26 Mar 2010 00:19:14 +0800

--00163628426c61e9260482a26872
Content-Type: text/plain; charset=ISO-8859-1

OK, maybe I've found the problem.
In wpi_set_channel, when in monitor mode, wpi_config is called without
locks. However, it thinks that the lock is held. So the problem
occurs.
See the attached patch. Now I'm capturing in monitor mode with wireshark.

--
Cheers,
Henry

--00163628426c61e9260482a26872
Content-Type: application/octet-stream; name="wpi.diff"
Content-Disposition: attachment; filename="wpi.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_g77rnz290

LS0tIGlmX3dwaS5jLm9yaWcJMjAxMC0wMy0yNSAyMzo1NTo0MC4wMDAwMDAwMDAgKzA4MDAKKysr
IGlmX3dwaS5jCTIwMTAtMDMtMjUgMjM6NTU6NTcuMDAwMDAwMDAwICswODAwCkBAIC0zNTUyLDcg
KzM1NTIsOSBAQAogCSAqIGFyZSBhbHJlYWR5IHRha2VuIGNhcmUgb2YgYnkgdGhlaXIgcmVzcGVj
dGl2ZSBmaXJtd2FyZSBjb21tYW5kcy4KIAkgKi8KIAlpZiAoaWMtPmljX29wbW9kZSA9PSBJRUVF
ODAyMTFfTV9NT05JVE9SKSB7CisJCVdQSV9MT0NLKHNjKTsKIAkJZXJyb3IgPSB3cGlfY29uZmln
KHNjKTsKKwkJV1BJX1VOTE9DSyhzYyk7CiAJCWlmIChlcnJvciAhPSAwKQogCQkJZGV2aWNlX3By
aW50ZihzYy0+c2NfZGV2LAogCQkJICAgICJlcnJvciAlZCBzZXR0dGluZyBjaGFubmVsXG4iLCBl
cnJvcik7Cg==
--00163628426c61e9260482a26872--

Loading...