kern/159768: [iwn] [panic] iwn_auth being called with wrong ni_chan
Colin Percival
cperciva at FreeBSD.org
Sun Aug 14 17:30:09 UTC 2011
>Number: 159768
>Category: kern
>Synopsis: [iwn] [panic] iwn_auth being called with wrong ni_chan
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sun Aug 14 17:30:09 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Colin Percival
>Release: FreeBSD 9.0-BETA1 amd64
>Organization:
>Environment:
Dell Latitude E5420, containing an Intel Centrino Advanced-N 6205
9.0-BETA1, amd64, GENERIC minus debug options.
iwn0 is wlan0; wlan0 is running with wpa_supplicant.
>Description:
panic reading 0xffff. kgdb shows iwn0 taskq at line 5294 of if_iwn.c:
if (IEEE80211_IS_CHAN_2GHZ(ni->ni_chan))
and ni_chan is 0xffff (aka. IEEE80211_CHAN_ANY).
The last entry in dmesg before the panic is
wlan0: ieee80211_new_state_locked: pending INIT -> AUTH transition lost
which may explain how we got into iwn_auth without having ni_chan
changed from IEEE80211_CHAN_ANY to a valid channel.
>How-To-Repeat:
Only happened once so far. My laptop was sitting at the edge of the
access point's range and wlan0 lost its connection and re-connected 239
times before the panic; so this might be a disconnection/reconnection
race condition of some sort.
I can provide the crashdump (or load it up in kgdb here) if there's
any more information to be gleaned from it.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-bugs
mailing list