Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 11 Mar 2010 05:32:24 GMT
From:      Arthur Hartwig <a_hartwig@fastmail.fm>
To:        freebsd-gnats-submit@FreeBSD.org
Subject:   kern/144642: Enabling rum interface causes panic
Message-ID:  <201003110532.o2B5WOH5081878@www.freebsd.org>
Resent-Message-ID: <201003110540.o2B5e1Qx088949@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         144642
>Category:       kern
>Synopsis:       Enabling rum interface causes panic
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Mar 11 05:40:01 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator:     Arthur Hartwig
>Release:        8.0
>Organization:
self
>Environment:
FreeBSD tux.example.org 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009     root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386

>Description:
I first came across this on pfSense 2.0 BETA (based on FreeBSD 8.0) where I wanted to configure the rum device as a wireless access point. The system panic'd very soon after clicking on the pfSense "Apply changes" button. Analysis showed this click resulted in at least four ifconfig commands relating to the interface but a similar panic could be produced on FreeBSD 8.0 by two simplified commands.  

The following back trace was taken from a panic of the pfSense debug kernel:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address  = 0xffff
fault code             = supervisor read, page not present
instruction pointer    = 0x20:0xc0a777ab
stack pointer          = 0x28:0xd50ddba4
frame pointer          = 0x28:0xd50ddbb0
code segment           = base 0x0, limit 0xfffff type 16
                         DPL 0, pres 1, def32 1, gram 1
processor eflags       = interrupt enabled, resume, IOPL=0
current process        = 0 (rum0 taskq)
[thread pid 0 tid 64096]
db> bt
Tracing pid 0 tid 64096 0xc3673d80
ieee80211_getcapinfo(c36f9000, ffff, c0a5c629, c36f987c, ...) at ieee80211_getcapinfo+0x56
ieee80211_beacon_construct(c3762000, 18, 691, d50ddc04, 5c9, ...) at ieee80211_beacon_construct+0x67
ieee80211_beacon_alloc(c3762000, c36f987c, 6, 2cb, c0e1940e, ...) at ieee80211_beacon_alloc+0xdb
rum_new_state(c36f9000, 5, ffffffff, 654, d50ddca8, ...) at rum_newstate+0x2b3

The back trace for the panic in adhoc mode is a bit different to the backtrace in hostap mode, but both cases panic attempting to access 0xffff at ieee80211_getcapinfo+0x56.

The problem appears to be that ieee80211_getcapinfo() is called with the second parameter 0xffff (IEEE80211_CHAN_ANYC) rather than a valid pointer to a struct ieee80211_channel. 
>How-To-Repeat:
FreeBSD 8.0, rum USB Wireless NC plugged in, the following two commands cause a system panic within a couple of seconds:

# ifconfig wlan create wlandev rum0 wlanmode adhoc bssid
# ifconfig wlan0 up ssid Bree

The following two commands cause a similar panic:

# ifconfig wlan create wlandev rum0 wlanmode hostap bssid
# ifconfig wlan0 up ssid Bree

The following two commands don't cause a panic within a couple of seconds:

# ifconfig wlan create wlandev rum0 bssid
# ifconfig wlan0 up ssid Bree


>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:



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