Panic in rum(4) on 8.0-BETA2

[Sam Leffler]

Florent Thoumie wrote:
> Since upgrading from 7.2-RELEASE to 8.0-BETA2, I've been experiencing the
> following panic on a regular basis:
> 
> : flz at cream:/var/crash; sudo kgdb -c vmcore.1 /boot/kernel/kernel.symbols
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> 
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-marcel-freebsd"...
> 
> Unread portion of the kernel message buffer:
> Kernel page fault with the following non-sleepable locks held:
> exclusive sleep mutex rum0 (network driver) r = 0 (0xc4ad29a4) locked @
> /usr/src/sys/dev/usb/wlan/if_rum.c:1278
> exclusive sleep mutex rum0_com_lock (rum0_com_lock) r = 0 (0xc4b06014)
> locked @ /usr/src/sys/net80211/ieee80211_scan.c:683
> KDB: stack backtrace:
> db_trace_self_wrapper(c0c6baf4,f3694a60,c08bc995,c0c7edcd,2ab,...) at
> db_trace_self_wrapper+0x26
> kdb_backtrace(c0c7edcd,2ab,ffffffff,c0efbc54,f3694a98,...) at
> kdb_backtrace+0x29
> _witness_debugger(c0c6df35,f3694aac,4,1,0,...) at _witness_debugger+0x25
> witness_warn(5,0,c0ca1b88,80246,c0db9aa0,...) at witness_warn+0x1fd
> trap(f3694b38) at trap+0x173
> calltrap() at calltrap+0x6
> --- trap 0xc, eip = 0xc093f0e8, esp = 0xf3694b78, ebp = 0xf3694b94 ---
> ieee80211_crypto_encap(c592d000,c4a0ca00,c0c58b19,4b3,c0efbc60,...) at
> ieee80211_crypto_encap+0xa8
> rum_start(c4ad2000,f3694c1c,c09232cf,c4ad2000,0,...) at rum_start+0x358
> if_start(c4ad2000,0,c0c778c5,c01,52,...) at if_start+0x12
> if_transmit(c4ad2000,c4a11100,c4a0b700,a4,c4b06000,...) at if_transmit+0x13f
> 
> ieee80211_start(c4691800,f3694ca4,c096918e,c4691800,5,...) at
> ieee80211_start+0x661
> if_start(c4691800,5,10,654,f3694ca4,...) at if_start+0x12
> ieee80211_newstate_cb(c8cf9000,1,c0c6d2f0,54,c4ace8dc,...) at
> ieee80211_newstate_cb+0x20e
> taskqueue_run(c4ace8c0,c4ace8dc,0,c0c5e82b,0,...) at taskqueue_run+0x10b
> taskqueue_thread_loop(c4b06074,f3694d38,c0c63ebc,342,c0db9aa0,...) at
> taskqueue_thread_loop+0x68
> fork_exit(c08b5b10,c4b06074,f3694d38) at fork_exit+0xb8
> fork_trampoline() at fork_trampoline+0x8
> --- trap 0, eip = 0, esp = 0xf3694d70, ebp = 0 ---
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address    = 0x20
> fault code        = supervisor read, page not present
> instruction pointer    = 0x20:0xc093f0e8
> stack pointer            = 0x28:0xf3694b78
> frame pointer            = 0x28:0xf3694b94
> code segment        = base 0x0, limit 0xfffff, type 0x1b
>             = DPL 0, pres 1, def32 1, gran 1
> processor eflags    = interrupt enabled, resume, IOPL = 0
> current process        = 0 (rum0 taskq)
> panic: from debugger
> cpuid = 0
> Uptime: 40m53s
> Physical memory: 1007 MB
> Dumping 155 MB: 140 124 108 92 76 60 44 28 12

Can you provide the line of code where the trap happened and the 
contents of the local variables?

Also show what your network config and/or how to reproduce the issue.

Do

wlandebug state+crypto

to collect debug msgs from the net80211 layer.

	Sam