Kernel page fault with non-sleepable locks held error with kernel r270837

[Garrett Cooper]

> On Aug 30, 2014, at 22:01, Hiroo Ono (小野寛生) <hiroo.ono+freebsd at gmail.com> wrote:
> 
> Hello,
> 
> During upgrading world and kernel from r26939 to r270837, I got the
> following problem.
> a) the arch is i386
> b) kernel is of r270837, userland is of r26939 (make kernel is done
> and rebooted, make installworld not yet).
> c) booting in single user mode is OK.
> d) during startup of multi-user mode, when dhclient is run, the
> following message appears, and the system freezes:
> 
> Starting devd.
> wlan0: link state changed to UP
> Starting webcamd.
> Attached to ugen4.2[0]
> Starting webcready running for ugen4.2.0
> /usr/local/etc/rc.d/webcamd: WARNING: failed to start webcamd
> Starting dhclient.
> DHCPREQUEST on wlan0 to 255.255.255.255 port 67
> DHCPACK from 192.168.8.2
> Kernel page fault with the following non-sleepable locks held:
> exclusive sleep mutex so_rcv (so_rcv) r = 0 (0xc713f078) locked @
> /usr/src/sys/kern/kern_event.c:2005
> KDB stack backtrace:
> rapper+0x2d/frame 0xe8f42710
> kdb_backtrace(c11aaf80,0,c713f078,c119a9e8,7d5,...) at 0xc0b4b160 =
> kdb_backtrace+0x30/frame 0xe8f42778
> witness_warn(5,0,c136b0a0,76fb000,c1833d58,...) at 0xc8b68a52 =
> witness_warn+0x402/frame 0xe8f427c8
> trap_pfault(18,3fd,c0dcc2d0,c1f64a80,c75fa000,...) at 0xc102f46b =
> trap_pfault+0x5b/frame 0xe8f42840
> trap(e8f42988) at 0xc102edcf = trap+0x6cf/frame 0xe8f4297c
> calltrap() at 0xc1017c4c = calltrap+0x6/frame 0xe8f4297c
> filt_soread(c75f7828,0,c119a9e8,48d,0,...) at 0xc0b9837d =
> filt_soread+0x9d/frame 0xe8f429f0
> kqueue_register(c6f59310,1,1,4f5,0,...) at 0xc0ad1457 =
> kqueue_register+0x807/frame 0xe8f42a68
> kern_kevent(c6f59310,7,12c217ce1 = Xint0x80), eip =
> instruction poi         = 0x28:0xe8f429f0     fff, type 0x1b
> DHCPREQUEST on wlan0 to 255.255.255.255 port 67
> DHCPACK from 192.168.8.2

Is bpf built into the kernel, or is it built and loaded as a module. I'm wondering because an issue with vimage and socket "hook" support was resolved in an earlier revision, but this might not have been caught:
http://svnweb.freebsd.org/base?view=revision&revision=270318
Cheers,
-Garrett