802.11 monitor mode changes coming

[Lucius Windschuh]

2009/5/18 Sam Leffler <sam at errno.com>:
> I plan to commit these changes by the end of the week.

Hi Sam.
Since updating from r192372 to r192667, ending "tcpdump -ni uath0"
with ^C results in this witness warning:

taskqueue_drain with the following non-sleepable locks held:
exclusive sleep mutex bpf global lock (bpf global lock) r = 0
(0xc0bdafd8) locked @ /usr/src/sys/net/bpf.c:605
KDB: stack backtrace:
db_trace_self_wrapper(c09bbd1c,eb107a24,c06da925,c09c6d24,25d,...) at
db_trace_self_wrapper+0x26
kdb_backtrace(c09c6d24,25d,ffffffff,c0baabcc,eb107a5c,...) at kdb_backtrace+0x29
_witness_debugger(c09be0ad,eb107a70,4,1,0,...) at _witness_debugger+0x25
witness_warn(5,0,c0967968,137,c712ec1c,...) at witness_warn+0x1fd
taskqueue_drain(c712ec00,c72400b8,c7240000,eb107ad0,c0773f49,...) at
taskqueue_drain+0xa9
ieee80211_waitfor_parent(c7240000,0,c09cc970,caf,c7240014,...) at
ieee80211_waitfor_parent+0x7b
ieee80211_ioctl(c64ac400,80206910,eb107af0,eb107b20,8903,...) at
ieee80211_ioctl+0x1a9
if_setflag(c64ac44c,0,c09b71f8,ca,0,...) at if_setflag+0x10a
ifpromisc(c64ac400,0,c09c6d24,236,c615ad4c,...) at ifpromisc+0x33
bpf_detachd(c0bdafd8,0,c09c6d24,25d,c6863400,...) at bpf_detachd+0x242
bpf_dtor(c6f4ba00,0,c09ab531,9f,c771a578,...) at bpf_dtor+0xb0
devfs_destroy_cdevpriv(c6863400,0,c09ab531,a9,eb107be8,...) at
devfs_destroy_cdevpriv+0xac
devfs_fpdrop(c771a578,c77356c0,3,0,c771a578,...) at devfs_fpdrop+0x68
_fdrop(c771a578,c77356c0,eb107c1c,c06da76c,0,c7735764,c0baabc8,c0a26b14,c09b3b14,c6f0972c,45b,c09b3b14,eb107c44,c06a2c90,c6f0972c,8,c09b3b14,45b)
at _fdrop+0x53
closef(c771a578,c77356c0,45b,440,c771a578,...) at closef+0x290
kern_close(c77356c0,3,eb107d2c,c09285d3,c77356c0,...) at kern_close+0x102
close(c77356c0,eb107cf8,4,c09b53e8,c0a1ec10,...) at close+0x1a
syscall(eb107d38) at syscall+0x283
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (6, FreeBSD ELF32, close), eip = 0x2838f9b3, esp =
0xbfbfe54c, ebp = 0xbfbfe568 --

Well, I have no perfect evidence that your changes caused this
behaviour, but since it happens only on 802.11 interfaces and not in
my previous CURRENT, this looks like fallout from your monitor works.

Lucius