Re: if_wpi panic in 7.0-PRERELEASE

Sam Banks wrote:
> Hey all,
>
> I have just got myself a new laptop (Dell Vostro 1500) which
> has an Intel 3945ABG wifi card in it. I am getting frequent
> kernel panics with the if_wpi driver. 
>
> >From the attached kgdb output, it appears that a valid mbuf
> struct is being passed into tkip_demic but once m_copydata
> is called (within tkip_demic), it's being passed a null
> pointer. At least, this is what I can see is going on :)
>
> Does anyone have any ideas why this would be happening or
> any further insight?
>
> I've attached what info I think will be helpful but if
> there's anything else needed, just yell out.
>
> Cheers,
>
> Sam.
>
>
> FreeBSD wolfie.evil 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE
> #3: Fri Jan 25 17:35:41 NZDT 2008    
> root_at_wolfie.evil:/usr/src/sys/i386/compile/WOLFIE  i386
>
>
> wpi0_at_pci0:12:0:0:       class=0x028000 card=0x10208086
> chip=0x42228086 rev=0x02 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = '10418086 Intel 3945ABG Wireless LAN
> controller'
>     class      = network
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0xc
> fault code              = supervisor read, page not
> present
> instruction pointer     = 0x20:0xc0597e0f
> stack pointer           = 0x28:0xe59c0b00
> frame pointer           = 0x28:0xe59c0b18
> 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         = 34 (irq17: wpi0 bfe0+)
> panic: from debugger
> cpuid = 0
> Uptime: 16s
> Physical memory: 2034 MB
> Dumping 72 MB: 57 41 25 9
>
> #0  doadump () at pcpu.h:195
> 195     pcpu.h: No such file or directory.
>         in pcpu.h
> (kgdb) bt
> #0  doadump () at pcpu.h:195
> #1  0xc054d14a in boot (howto=260) at
> ./../../kern/kern_shutdown.c:409
> #2  0xc054d44f in panic (fmt=Variable "fmt" is not
> available.
> ) at ../../../kern/kern_shutdown.c:563
> #3  0xc044ad49 in db_panic (addr=Could not find the frame
> base for "db_panic".
> ) at ../../../ddb/db_command.c:433
> #4  0xc044b44c in db_command_loop () at
> ./../../ddb/db_command.c:401
> #5  0xc044cd28 in db_trap (type=12, code=0) at
> ./../../ddb/db_main.c:222
> #6  0xc0573c18 in kdb_trap (type=12, code=0,
> tf=dwarf2_read_address: Corrupted DWARF expression.
> ) at ../../../kern/subr_kdb.c:502
> #7  0xc06cd159 in trap_fatal (frame=0xe59c0ac0, eva=12)
> at ../../../i386/i386/trap.c:890
> #8  0xc06cd40e in trap_pfault (frame=0xe59c0ac0,
> usermode=0, eva=12) at ../../../i386/i386/trap.c:812
> #9  0xc06cdddb in trap (frame=0xe59c0ac0) at
> ./../../i386/i386/trap.c:490
> #10 0xc06b502b in calltrap () at
> ./../../i386/i386/exception.s:139
> #11 0xc0597e0f in m_copydata (m=0x0, off=4, len=8,
> cp=0xe59c0b38 "¤ðiÅ") at
> ./../../kern/uipc_mbuf.c:808
> #12 0xc05ee9d2 in tkip_demic (k=0xc569f0a4,
> m=0xc5293000, force=0)
>     at ../../../net80211/ieee80211_crypto_tkip.c:338
> #13 0xc05f7a7e in ieee80211_input (ic=0xc527c008,
> m=0xc5293000, ni=0xc569f000, rssi=54, noise=0,
> rstamp=0)
>     at ieee80211_crypto.h:186
> #14 0xc06a9687 in wpi_intr (arg=0xc527c000) at
> ./../../dev/wpi/if_wpi.c:1699
> #15 0xc0530e6c in ithread_loop (arg=0xc525ab90) at
> ./../../kern/kern_intr.c:1036
> #16 0xc052d931 in fork_exit (callout=0xc0530cd0
> <ithread_loop>, arg=0xc525ab90, frame=0xe59c0d38)
>     at ../../../kern/kern_fork.c:781
> #17 0xc06b50a0 in fork_trampoline () at
> ./../../i386/i386/exception.s:205
>
>
> Contents of mbuf struct being passed into tkip_demic:
>
> $1 = {m_hdr = {mh_next = 0x0, mh_nextpkt = 0x0,
> mh_data = 0xe5753820 "\b\002~", mh_len = 68, mh_flags
> = 1,
>     mh_type = 1, pad = "\000"}, M_dat = {MH =
> {MH_pkthdr = {rcvif = 0xc527a000, header = 0x0, len
> = 80,
>         csum_flags = 0, csum_data = 0, tso_segsz = 0,
> ether_vtag = 0, tags = {slh_first = 0x0}}, MH_dat =
> {
>         MH_ext = {ext_buf = 0xe5753800 "t", ext_free =
> 0xc06a5c7d <wpi_free_rbuf>, ext_args = 0xc527d990,
>           ext_size = 3072, ref_cnt = 0xc52965a0,
> ext_type = 100},
>         MH_databuf =
> "\0008uå}\\jÀ\220Ù'Å\000\f\000\000 e)Åd", '\0'
> <repeats 182 times>}},
>     M_databuf = "\000 'Å\000\000\000\000P", '\0'
> <repeats 20 times>, "8uå}\\jÀ\220Ù'Å\000\f\000\000
> e)Åd", '\0' <repeats 182 times>}}
>   

I think there is some confusion in the setup of mbufs for the rx ring.  
Frames passed up the stack must have a pkthdr on the first mbuf but it 
looks like wpi_alloc_rx_ring allocates regular mbufs w/ m_get and not 
m_gethdr.  This would explain why mh_flags above is 1 (M_EXT) and not 3 
(M_EXT+M_PKTHDR).

    Sam