From owner-freebsd-bugs@FreeBSD.ORG Sat Apr 11 20:40:06 2009 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 382A21065674 for ; Sat, 11 Apr 2009 20:40:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 18B9C8FC13 for ; Sat, 11 Apr 2009 20:40:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n3BKe5WF073775 for ; Sat, 11 Apr 2009 20:40:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n3BKe5ER073774; Sat, 11 Apr 2009 20:40:05 GMT (envelope-from gnats) Resent-Date: Sat, 11 Apr 2009 20:40:05 GMT Resent-Message-Id: <200904112040.n3BKe5ER073774@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Colin Percival Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id EFE22106566B for ; Sat, 11 Apr 2009 20:39:32 +0000 (UTC) (envelope-from cperciva@xps.daemonology.net) Received: from xps.daemonology.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with SMTP id 9432514D95C for ; Sat, 11 Apr 2009 20:39:32 +0000 (UTC) (envelope-from cperciva@xps.daemonology.net) Received: (qmail 6567 invoked by uid 1001); 11 Apr 2009 20:18:22 -0000 Message-Id: <20090411201822.6566.qmail@xps.daemonology.net> Date: 11 Apr 2009 20:18:22 -0000 From: Colin Percival To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: kern/133613: kernel panic in wpi(4) X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Colin Percival List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 20:40:06 -0000 >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.