Re: Panic and LOR on -CURRENT with ath

On Wed, Dec 21, 2005 at 10:13:41PM -0800, Sam Leffler wrote:
> The info you want is gone by the time the crash happens.  Last time I 
> chased a similar problem I did some private hacks to write-protect mbufs 
> to catch unexpected modification.  You might try removing ipfw or using 
> an alternate packet filter if that's feasible.  I wouldn't be surprised 
> if this is related to ipfw and/or divert sockets.

OK, I'm running with pf right now, and that particular panic went away.

However, I had a few others... the first one is admittedly old, and it
might have disappeared with the last cvsup (dec 27):

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0xdeadc0de
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0xc05288e6
stack pointer           = 0x28:0xc5b70910
frame pointer           = 0x28:0xc5b7091c
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         = 270 (natd)
[thread pid 270 tid 100043 ]
Stopped at      ieee80211_find_txnode+0x36:     testb   $0x1,0(%eax)
db> bt
Tracing pid 270 tid 100043 td 0xc0d5e300
ieee80211_find_txnode(c0d681ac,deadc0de,c0d690f8,c0d681ac,c0d71ef4) at ieee80211
_find_txnode+0x36
ath_start(c0d65000,25000,be,0,c1040842) at ath_start+0xe52
ether_output_frame(c0d65000,c1040800,c1040848,0,0) at ether_output_frame+0x226
ether_output(c0d65000,c1040800,c5b70a80,c0fdda50) at ether_output+0x2d3
ip_output(c1040800,0,c5b70a7c,1,0,0) at ip_output+0xa7e
ip_forward(c06376e0,0,c05ef2e7,6d9,c06376e0) at ip_forward+0x120
ip_input(c1040800) at ip_input+0x8d5
div_send(c0fda000,0,c1040800,c0d91850,0) at div_send+0x18b
sosend(c0fda000,c0d91850,c5b70c40,c1040800,0,0,c0d5e300) at sosend+0x5c5
kern_sendit(c0d5e300,3,c5b70cbc,0,0) at kern_sendit+0xbe
sendit(c5b70cbc,0,bfbdeca0,0,c0d91850) at sendit+0x41
sendto(c0d5e300,c5b70d04,6,f65,296) at sendto+0x47
syscall(3b,3b,bfbf003b,1,b0) at syscall+0x110
Xint0x80_syscall() at Xint0x80_syscall+0x1f


This one happened as I restarted dhclient:


panic: bus_dmamap_load_mbuf_sg: no mbuf packet header!
KDB: stack backtrace:
panic(c06050ba,c060205c,c0554ad9,c1225846,c5708bfa) at panic+0xef
bus_dmamap_load_mbuf_sg(c0d21d80,0,c1225800,c0d733f0,c0d733d0,1) at bus_dmamap_l
oad_mbuf_sg+0x4ec
ath_start(c0d65000,6c,c0ce771c,0,c0614d47) at ath_start+0x26f
taskqueue_run(c0ce7700,0,c0d0e624,0,c04b84c0) at taskqueue_run+0x81
ithread_loop(c0ce7680,c5708d38,c0ce7680,c04b84c0,0) at ithread_loop+0x175
fork_exit(c04b84c0,c0ce7680,c5708d38) at fork_exit+0x83
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xc5708d6c, ebp = 0 ---
KDB: enter: panic
[thread pid 31 tid 100017 ]


This is 100% reproducible: switching from 11b to 11g (with a few associated
nodes, most of which 11b only) results in this panic:


gw0# ifconfig ath0 mode 11g
panic: bogus long slot station count 0
KDB: stack backtrace:
panic(c061e2a3,0,c0d699a8,c0f1d000,b59) at panic+0xef
ieee80211_node_join(c0d691ac,c0f1d000,c0d699ac,0,c061dd08) at ieee80211_node_joi
n
ieee80211_iterate_nodes(c0d699a8,c0557ce0,c0d691ac) at ieee80211_iterate_nodes+0
xbc
ieee80211_newstate(c0d691ac,0,ffffffff) at ieee80211_newstate+0x4e6
ath_newstate(c0d691ac,0,ffffffff,c0d6b000,c0d69000) at ath_newstate+0x2e4
ath_stop_locked(c0d69d3c,8,c06089ec,356,c0d69d3c) at ath_stop_locked+0xab
ath_init(c0d69000,20280,c5e20a60,c0539d66,c0d65000) at ath_init+0x4e
ath_media_change(c0d65000,c066a358,c5e20a64,c0cefd80,c0d65000) at ath_media_chan
ge+0x3e
ifmedia_ioctl(c0d65000,c0d92ca0,c0d69aac,c0206937,0) at ifmedia_ioctl+0x1f6
ieee80211_ioctl(c0d691ac,c0206937,c0d92ca0) at ieee80211_ioctl+0x16a
ath_ioctl(c0d65000,c0206937,c0d92ca0) at ath_ioctl+0xb2
ifhwioctl(c0d92ca0,c1110a80,c0d65000,c0fdf6f4,c0206937) at ifhwioctl+0x113
ifioctl(c0fdf6f4,c0206937,c0d92ca0,c1110a80) at ifioctl+0x5c
soo_ioctl(c0deca68,c0206937,c0d92ca0,c0ded780,c1110a80) at soo_ioctl+0x29d
ioctl(c1110a80,c5e20d04,3,c,246) at ioctl+0xfa
syscall(3b,3b,3b,8057d40,0) at syscall+0x110
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (54, FreeBSD ELF32, ioctl), eip = 0x2813f71f, esp = 0xbfbfe4cc, ebp = 0xbfbfe4e8 ---
KDB: enter: panic
[thread pid 1615 tid 100068 ]
Stopped at      kdb_enter+0x2c: leal    0(%esi),%esi


I'll keep testing but things look nicer despite these panics (as they only
happen during non routine things).


Bye,
	Andrea

-- 
            Secret hacker rule #11: hackers read manuals.



-- 
                   Press every key to continue.