kern/133613: kernel panic in wpi(4)

[Colin Percival]

>Number:         133613
>Category:       kern
>Synopsis:       kernel panic in wpi(4)
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Apr 11 20:40:05 UTC 2009
>Closed-Date:
>Last-Modified:
>Originator:     Colin Percival
>Release:        FreeBSD 7.2-BETA1 amd64
>Organization:
>Environment:
FreeBSD 7.2-BETA1 amd64
>Description:

Running wpa_supplicant on a wpi(4) device, I get the following panic:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address   = 0xffff
fault code              = supervisor read data, page not present
instruction pointer     = 0x8:0xffffffff80d4e64b
stack pointer           = 0x10:0xfffffffe800c9a90
frame pointer           = 0x10:0xfffffffe800c9bc0
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 31 (wpi0 taskq)
trap number             = 12

Looking at the dump, I can see that this is occurring in
sys/dev/wpi/if_wpi.c in wpi_auth:
>How-To-Repeat:
>Fix:

The following patch is a workaround for the panic: It checks to make
sure that there is a channel set before processing the authentication.

Index: if_wpi.c
===================================================================
RCS file: /usr/cvsroot/src/sys/dev/wpi/if_wpi.c,v
retrieving revision 1.5.2.4
diff -p -u -I __FBSDID -I $FreeBSD -r1.5.2.4 if_wpi.c
--- if_wpi.c    18 Mar 2008 18:52:52 -0000      1.5.2.4
+++ if_wpi.c    11 Apr 2009 17:27:44 -0000
@@ -2402,6 +2402,10 @@ wpi_auth(struct wpi_softc *sc)
        struct wpi_node_info node;
        int error;

+        /* Can't authenticate if we don't have a channel set... */
+        if (ni->ni_chan == IEEE80211_CHAN_ANYC) {
+                return (EINVAL);
+        }

        /* update adapter's configuration */
        sc->config.associd = 0;
>Release-Note:
>Audit-Trail:
>Unformatted:
 >>>	if (IEEE80211_IS_CHAN_2GHZ(ni->ni_chan)) {
 		sc->config.flags |= htole32(WPI_CONFIG_AUTO |
 		    WPI_CONFIG_24GHZ);
 	}
 because at this point ni->ni_chan is set to IEEE80211_CHAN_ANYC.
 
 My best guess at what's happening is the following:
 1. wpa_supplicant finds the right channel
 2. wpa_supplicant tells the kernel to authenticate to that channel
 3. the wpi driver queues the authenticate command
 4. wpa_supplicant goes back to scanning
 5. the wpi driver dequeues the command and tries to perform the
 requested authentication, but panics because it's not bound to a
 channel any more.