Under moderate use (elaborate web pages as opposed to large downloads) if_wi will hang, and produce the following errors:

wi0: device timeout
wi0: timeout in wi_cmd 0x0002; event status 0x8000
wi0: timeout in wi_cmd 0x0000; event status 0x8000
wi0: wi_cmd: busy bit won't clear.
wi0: init failed
wi0: failed to allocate 2372 bytes on NIC
wi0: tx buffer allocation failed (error 12)
wi0: interface not running

Any attempts to reactivate the interface (dhclient, ifconfig down/up, and once even ifconfig ether) cause kernel panic.  Following is a backtrace of the kernel dump.  I know I'm not the only person to have issues with this, so hopefully it will help.
Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x78
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0xc04f2091
stack pointer           = 0x28:0xd9c94bb4
frame pointer           = 0x28:0xd9c94bb8
code segment            = base rx0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = resume, IOPL = 0
current process         = 1536 (ifconfig)
trap number             = 12
panic: page fault
Uptime: 1h33m38s
Dumping 383 MB (2 chunks)
  chunk 0: 1MB (159 pages) ... ok
  chunk 1: 383MB (98048 pages) 368 352 336 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16

#0  doadump () at pcpu.h:165
165             __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) bt
#0  doadump () at pcpu.h:165
#1  0xc04d1ac2 in boot (howto=260) at ../../../kern/kern_shutdown.c:409
#2  0xc04d1d58 in panic (fmt=0xc0619c11 "%s") at ../../../kern/kern_shutdown.c:565
#3  0xc05f7470 in trap_fatal (frame=0xd9c94b74, eva=120) at ../../../i386/i386/trap.c:837
#4  0xc05f6c52 in trap (frame=
      {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1030006304, tf_esi = -1028496640, tf_ebp = -641119304, tf_isp = -641119328, tf_ebx = -1023460736, tf_edx = -1023460736, tf_ecx = 4, tf_eax = -1028496608, tf_trapno = 12, tf_err = 0, tf_eip = -1068556143, tf_cs = 32, tf_eflags = 65539, tf_esp = -1028496640, tf_ss = -641119268}) at ../../../i386/i386/trap.c:270
#5  0xc05e5e0a in calltrap () at ../../../i386/i386/exception.s:139
#6  0xc04f2091 in turnstile_setowner (ts=0xc2ff3a80, owner=0x4) at ../../../kern/subr_turnstile.c:432
#7  0xc04f2388 in turnstile_wait (lock=0xc318307c, owner=0x4) at ../../../kern/subr_turnstile.c:591
#8  0xc04c90e4 in _mtx_lock_sleep (m=0xc318307c, tid=3266470656, opts=0, file=0x0, line=0) at ../../../kern/kern_mutex.c:579
#9  0xc05528d3 in in_control (so=0xc2ac2858, cmd=2149607705, data=0xc29b59e0 "wi0", ifp=0xc275f400, td=0xc2b26300) at ../../../netinet/in.c:484
#10 0xc053ee0f in ifioctl (so=0xc2ac2858, cmd=2149607705, data=0xc29b59e0 "wi0", td=0xc2b26300) at ../../../net/if.c:1593
#11 0xc04f99af in soo_ioctl (fp=0xc2b26320, cmd=2149607705, data=0xc29b59e0, active_cred=0xc2990080, td=0xc2b26300) at ../../../kern/sys_socket.c:214
#12 0xc04f4079 in ioctl (td=0xc2b26300, uap=0xd9c94d04) at file.h:264
#13 0xc05f7787 in syscall (frame=
      {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 134566848, tf_esi = -1077940404, tf_ebp = -1077940728, tf_isp = -641118876, tf_ebx = 0, tf_edx = 134578684, tf_ecx = 134566848, tf_eax = 54, tf_trapno = 12, tf_err = 2, tf_eip = 672428783, tf_cs = 51, tf_eflags = 646, tf_esp = -1077942852, tf_ss = 59}) at ../../../i386/i386/trap.c:983
#14 0xc05e5e5f in Xint0x80_syscall () at ../../../i386/i386/exception.s:200
#15 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)

How-To-Repeat: Though this happened when I was using the GENERIC default kernel, my DEBUG kernel has few options/devices, dynamically loading what I need. I only remove those I knew were unneccesary, usb, scsi, raid, most NICs.  It also happens with this kernel.  Setting up the card with ifconfig goes smoothly.  When browsing though, either nearly immediately or at a most unexpected time, the driver will hang and produce the above errors.  To induce the panic, as said above, any attempts to manually bring the interface back up, short of rebooting, cause panic.