Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 06 Feb 2009 18:55:27 -0800
From:      Sam Leffler <sam@freebsd.org>
To:        L Campbell <llc2w@virginia.edu>
Cc:        freebsd-current@freebsd.org
Subject:   Re: iwi broken? reproducible crash :(
Message-ID:  <498CF81F.2090105@freebsd.org>
In-Reply-To: <792298050902061142k33f35be7sb19d566835e796ad@mail.gmail.com>
References:  <792298050902061142k33f35be7sb19d566835e796ad@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
L Campbell wrote:
> I recently updated to CURRENT from RELENG_7 (from sources pulled on
> Feb. 6th), and since then haven't been able to get my Inspiron 6000's
> Intel PRO 2200/BG working again (it worked mostly fine on RELENG_7).
> The machine is running an i386 non-GENERIC kernel (I can post the
> configuration if it's relevant).
>
> The settings on the device (set from rc.conf) configured for my home
> network (which experiences the same problem) look like this --
>
> $ ifconfig iwi0
> iwi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 2290
>         ether 00:16:6f:63:a6:dc
>         media: IEEE 802.11 Wireless Ethernet autoselect mode 11g
>         status: associated
>
> $ ifconfig wlan0
> wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>         ether 00:16:6f:63:a6:dc
>         media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
>         status: no carrier
>         ssid home_ssid channel 5 (2432 Mhz 11g)
>         country US authmode OPEN privacy OFF txpower 0 bmiss 24 scanvalid 60
>         protmode CTS wme bintval 0
>
> When attempting to associate with an access point (without any
> encryption or additional complications), the console gets flooded with
> a barrage of messages --
>
> $ ifconfig wlan0 down ssid wahoo bssid - channel 11 up
> iwi0: need multicast update callback
> iwi0: iwi_cmd: cmd 84 not sent, busy
> iwi0: iwi_cmd: cmd 42 not sent, busy
> iwi0: firmware error
>
> Enabling debug via `$ sysctl debug.iwi=1` reproducibly causes the
> kernel to crash:
>
> Unread portion of the kernel message buffer:
> exit SCANNING state
> iwi_ops: SET_WME arg 0
> iwi_newstate: SCAN -> AUTH flags 0x1
> iwi_ops: AUTH arg 192
> enter ASSOCIATING state
> Configuring adapter
> Setting ESSID to "wahoo"
> Setting power mode to 0
> Setting RTS threshold to 2346
> Setting fragmentation threshold to 2346
> Setting negotiated rates (12)
> Setting WME parameters
> Setting WME IE (len=7)
> Setting sensitivity to 69
> Join bssid 00:19:07:05:99:c3 dst 00:19:07:05:99:c3 channel 11 policy
> 0x1 auth 0 capinfo 0x21 lintval 100 bintval 100
> iwi_newstate: AUTH -> ASSOC flags 0x1
> exit ASSOCIATING state
> iwi_newstate: ASSOC -> SCAN flags 0x1
> iwi_ops: SET_WME arg 0
> iwi_newstate: SCAN -> AUTH flags 0x1
> iwi_ops: AUTH arg 192
> enter ASSOCIATING state
> Configuring adapter
> exit ASSOCIATING state
> Setting ESSID to "wahoo"
> iwi_newSetting power mode to 0
> state: AUTSetting RTS threshold to 2346
> H -> SCAN Setting fragmentation threshold to 2346
> flags 0x9Setting negotiated rates (12)
>
> Setting WME parameters
> iwi_newSetting WME IE (len=7)
> state: SCA
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0xc40ee184
> fault code              = supervisor read, page not present
> instruction pointer     = 0x20:0xc06bea06
> stack pointer           = 0x28:0xc3a05b64
> frame pointer           = 0x28:0xc3a05b64
> 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 (iwi0 taskq)
>
> kgdb> bt
> #12 0xc06bea06 in node_getrssi (ni=0xc40ee000)
>     at /usr/src/sys/net80211/ieee80211_node.c:1005
> #13 0xc051286c in iwi_ops (arg0=0xc3d4ec00, npending=1)
>     at /usr/src/sys/dev/iwi/if_iwi.c:2926
> #14 0xc062d042 in taskqueue_run (queue=0xc3d73180)
>     at /usr/src/sys/kern/subr_taskqueue.c:282
> #15 0xc062d3db in taskqueue_thread_loop (arg=0xc3d4ec4c)
>     at /usr/src/sys/kern/subr_taskqueue.c:403
> #16 0xc05d6e80 in fork_exit (callout=0xc062d360 <taskqueue_thread_loop>,
>     arg=0xc3d4ec4c, frame=0xc3a05d38) at /usr/src/sys/kern/kern_fork.c:821
> #17 0xc07daf70 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270
>
> kgdb> f 12
> kgdb> list
> 0xc06bea06 is in node_getrssi (/usr/src/sys/net80211/ieee80211_node.c:1005).
> 1000    }
> 1001
> 1002    static int8_t
> 1003    node_getrssi(const struct ieee80211_node *ni)
> 1004    {
> 1005            uint32_t avgrssi = ni->ni_avgrssi;
> 1006            int32_t rssi;
> 1007
> 1008            if (avgrssi == IEEE80211_RSSI_DUMMY_MARKER)
> 1009                    return 0;
>
> kgdb> p ni
> $1 = (const struct ieee80211_node *) 0xc40ee000
>
> I dunno if this is the right channel to post the information (or even
> if I'm posting anything useful). Let me know if you need more
> information or have any ideas/suggestions/patches to test. Thanks a
> bunch :3
>   

Looks like a race in referencing the bss node and a state change.  I 
haven't looked at iwi forever so can't recall how it's supposed to 
work.  You might enable net80211 state machine debug msgs to see if it 
provides more info: wlandebug state.

    Sam




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?498CF81F.2090105>