From nobody@FreeBSD.org  Sat Mar 20 08:40:25 2010
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 87A591065670
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 20 Mar 2010 08:40:25 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 783928FC1D
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 20 Mar 2010 08:40:25 +0000 (UTC)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o2K8ePmc023982
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 20 Mar 2010 08:40:25 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id o2K8ePaG023981;
	Sat, 20 Mar 2010 08:40:25 GMT
	(envelope-from nobody)
Message-Id: <201003200840.o2K8ePaG023981@www.freebsd.org>
Date: Sat, 20 Mar 2010 08:40:25 GMT
From: Dominic Fandrey <kamikaze@bsdforen.de>
To: freebsd-gnats-submit@FreeBSD.org
Subject: wpi panics system
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         144898
>Category:       kern
>Synopsis:       [wpi] [panic] wpi panics system
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bschmidt
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Mar 20 08:50:03 UTC 2010
>Closed-Date:    Wed Jan 05 08:09:50 UTC 2011
>Last-Modified:  Wed Jan 05 08:09:50 UTC 2011
>Originator:     Dominic Fandrey
>Release:        RELENG_8
>Organization:
private
>Environment:
FreeBSD mobileKamikaze.norad 8.0-STABLE FreeBSD 8.0-STABLE #0: Thu Mar 18 22:46:18 CET 2010     root@mobileKamikaze.norad:/usr/obj/HP6510b-8/amd64/usr/src/sys/HP6510b-8  amd64
>Description:
A couple of days ago I upgraded my notebook from 2gb to 8gb ram. Ever since my wpi wireless works very unreliable. An established connection just disappears suddenly often after only a couple of minutes (the wireles LED turns itself off). Afterwards it's no longer possible to find wireless networks. Scans always return nothing.

This is not the worst, though. It also panics the system quite often (I'm using a really slow GSM connection, to avoid the panics). I.e. the system freezes without creating a dump.

Once I happened to be looking at the error console and pressed the radio button. This is what I recorded (using pen and paper):

wpi0: Hardware Switch Enabled
wpi0: could not set power mode
wpi0: device config failed
kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address	= 0x20
fault code		= supervisor read data, page not present
instruction pointer	= 0x20:0xffffffff802501ab
stack pointer		= 0x28:0xffffff80e7c01b70
frame pointer		= 0x28:0xffffff80e7c01ba0
code segment		= base 0x0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags	= resume, IOPL = 0
current process		= 0 (wpi0 taskq)
trap number		= 12
panic: page fault
cpuid = 1



As I said, the system doesn't dump, no idea why. This is an HP Compag 6510b, Intel Core2Duo, 8gb memory.

pciconf -lv:
hostb0@pci0:0:0:0:	class=0x060000 card=0x30c0103c chip=0x2a008086 rev=0x0c hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Mobile PM965/GM965/GL960 Express Processor to DRAM Controller'
    class      = bridge
    subclass   = HOST-PCI
vgapci0@pci0:0:2:0:	class=0x030000 card=0x30c0103c chip=0x2a028086 rev=0x0c hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Mobile 965 Express Integrated Graphics Controller'
    class      = display
    subclass   = VGA
vgapci1@pci0:0:2:1:	class=0x038000 card=0x30c0103c chip=0x2a038086 rev=0x0c hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Mobile 965 Express Integrated Graphics Controller'
    class      = display
uhci0@pci0:0:26:0:	class=0x0c0300 card=0x30c0103c chip=0x28348086 rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82801H (ICH8 Family) USB UHCI *4'
    class      = serial bus
    subclass   = USB
uhci1@pci0:0:26:1:	class=0x0c0300 card=0x30c0103c chip=0x28358086 rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82801H (ICH8 Family) USB UHCI *5'
    class      = serial bus
    subclass   = USB
ehci0@pci0:0:26:7:	class=0x0c0320 card=0x30c0103c chip=0x283a8086 rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'ICH8 Enhanced USB2 Enhanced Host Controller (81EC1043 (?))'
    class      = serial bus
    subclass   = USB
hdac0@pci0:0:27:0:	class=0x040300 card=0x30c0103c chip=0x284b8086 rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Intel audio controller embedded with the 82801H chipset ( ICH8 chipset ) (82801H)'
    class      = multimedia
    subclass   = HDA
pcib1@pci0:0:28:0:	class=0x060400 card=0x30c0103c chip=0x283f8086 rev=0x03 hdr=0x01
    vendor     = 'Intel Corporation'
    device     = '82801H (ICH8 Family) PCIe Port 1'
    class      = bridge
    subclass   = PCI-PCI
pcib2@pci0:0:28:1:	class=0x060400 card=0x30c0103c chip=0x28418086 rev=0x03 hdr=0x01
    vendor     = 'Intel Corporation'
    device     = '82801H (ICH8 Family) PCIe Port 2'
    class      = bridge
    subclass   = PCI-PCI
pcib3@pci0:0:28:2:	class=0x060400 card=0x30c0103c chip=0x28438086 rev=0x03 hdr=0x01
    vendor     = 'Intel Corporation'
    device     = '82801H (ICH8 Family) PCIe Port 3'
    class      = bridge
    subclass   = PCI-PCI
pcib4@pci0:0:28:4:	class=0x060400 card=0x30c0103c chip=0x28478086 rev=0x03 hdr=0x01
    vendor     = 'Intel Corporation'
    device     = '82801H (ICH8 Family) PCIe Port 5'
    class      = bridge
    subclass   = PCI-PCI
uhci2@pci0:0:29:0:	class=0x0c0300 card=0x30c0103c chip=0x28308086 rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82801H (ICH8 Family) USB UHCI *1'
    class      = serial bus
    subclass   = USB
uhci3@pci0:0:29:1:	class=0x0c0300 card=0x30c0103c chip=0x28318086 rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82801H (ICH8 Family) USB UHCI *2'
    class      = serial bus
    subclass   = USB
uhci4@pci0:0:29:2:	class=0x0c0300 card=0x30c0103c chip=0x28328086 rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82801H (ICH8 Family) USB UHCI *3'
    class      = serial bus
    subclass   = USB
ehci1@pci0:0:29:7:	class=0x0c0320 card=0x30c0103c chip=0x28368086 rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82801H (ICH8 Family) USB2 EHCI *1'
    class      = serial bus
    subclass   = USB
pcib5@pci0:0:30:0:	class=0x060401 card=0x30c0103c chip=0x24488086 rev=0xf3 hdr=0x01
    vendor     = 'Intel Corporation'
    device     = '82801 Family (ICH2/3/4/5/6/7/8/9-M) Hub Interface to PCI Bridge'
    class      = bridge
    subclass   = PCI-PCI
isab0@pci0:0:31:0:	class=0x060100 card=0x30c0103c chip=0x28158086 rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82801HEM (ICH8M-E) LPC Interface Controller'
    class      = bridge
    subclass   = PCI-ISA
atapci0@pci0:0:31:1:	class=0x01018a card=0x30c0103c chip=0x28508086 rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82801H (ICH8 Family) Ultra ATA Storage Controllers'
    class      = mass storage
    subclass   = ATA
ahci0@pci0:0:31:2:	class=0x010601 card=0x30c0103c chip=0x28298086 rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Mobile SATA AHCI Controller'
    class      = mass storage
    subclass   = SATA
wpi0@pci0:16:0:0:	class=0x028000 card=0x135c103c chip=0x42228086 rev=0x02 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Intel 3945ABG Wireless LAN controller (10208086)'
    class      = network
bge0@pci0:24:0:0:	class=0x020000 card=0x30c0103c chip=0x169314e4 rev=0x02 hdr=0x00
    vendor     = 'Broadcom Corporation'
    device     = 'Ethernet Controller Broadcom Netlink Gigabit (BCM5787A)'
    class      = network
    subclass   = ethernet
none0@pci0:2:4:0:	class=0x060700 card=0x30c0103c chip=0x04761180 rev=0xb6 hdr=0x02
    vendor     = 'Ricoh Company, Ltd.'
    device     = 'Ricoh R/RL/5C476(II) (unknown)'
    class      = bridge
    subclass   = PCI-CardBus



dmesg |grep wpi:
wpi0: <Intel(R) PRO/Wireless 3945ABG> mem 0xe4100000-0xe4100fff irq 17 at device 0.0 on pci16
wpi0: Driver Revision 20071127
wpi0: Hardware Revision (0x1)
wpi0: Regulatory Domain: MoW2
wpi0: Hardware Type: B
wpi0: Hardware Revision: ?
wpi0: SKU does support 802.11a
wpi0: [ITHREAD]

>How-To-Repeat:
Use wpi wireless on an amd64 system with 8gb ram. If you use wpa_supplicant it panics more frequently.
>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-net 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Sat Mar 20 13:53:51 UTC 2010 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=144898 

From: Dominic Fandrey <kamikaze@bsdforen.de>
To: bug-followup@FreeBSD.org, kamikaze@bsdforen.de
Cc:  
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Tue, 30 Mar 2010 16:43:15 +0200

 Because there were so many net related commits in RELENG_8
 recently I rebuilt my system today.
 
 It appears that the system now doesn't panic any more. If at
 all the connection, now works for a maximum of 10 seconds,
 though.
 
 I have to reload the if_wpi and wpifw modules to get it
 running again (for another 10 seconds).
 
 This is what ttyv0 looks like, the beacon misses start
 after a couple of seconds:
 
 
 wpi0: Regulatory Domain: MoW2
 wpi0: Hardware Type: B
 wpi0: Hardware Revision: ?
 wpi0: SKU does support 802.11a
 wpi0: [ITHREAD]
 wlan0: Ethernet address: 00:1c:bf:58:3a:87
 wpi0: timeout resetting Tx ring 1
 wpi0: timeout resetting Tx ring 3
 wpi0: timeout resetting Tx ring 4
 microcode alive notification version 10e02 alive 1
 microcode alive notification version 10e02 alive 1
 wpi_newstate: INIT -> SCAN flags 0x0
 wpi0: scan timeout
 wpi_newstate: SCAN -> SCAN flags 0x0
 microcode alive notification version 10e02 alive 1
 microcode alive notification version 10e02 alive 1
 wpi_newstate: SCAN -> AUTH flags 0x0
 config chan 1 flags 8005 cck f ofdm 15
 wpi_newstate: AUTH -> ASSOC flags 0x0
 wpi_newstate: ASSOC -> RUN flags 0x0
 config chan 1 flags 8005
 wpi0: need multicast update callback
 wpi0: need multicast update callback
 wpi0: need multicast update callback
 Beacon miss: 2728567458 >= 7
 Beacon miss: 2728567458 >= 7
 Beacon miss: 2728567458 >= 7
 Beacon miss: 2728567458 >= 7
 Beacon miss: 2728567458 >= 7
 Beacon miss: 2728567458 >= 7
 Beacon miss: 2728567458 >= 7
 Beacon miss: 2728567458 >= 7
 Beacon miss: 2728567458 >= 7
 Beacon miss: 2728567458 >= 7
 Beacon miss: 2728567458 >= 7
 Beacon miss: 2728567458 >= 7
 Beacon miss: 2728567458 >= 7
 Beacon miss: 2728567458 >= 7
 Beacon miss: 2728567458 >= 7
 Beacon miss: 2728567458 >= 7
 ...
 
 I also recognized that wlan0 always lists "txpower 0",
 even if I try to set it manually (txpowermax is 50.0).

From: Dominic Fandrey <kamikaze@bsdforen.de>
To: jeff curry <jeff@degrind.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Sun, 02 May 2010 21:55:02 +0200

 On 02/05/2010 21:45, jeff curry wrote:
 > This is happening to me as well, 8.0-release p2, amd64, 4 GB RAM, same
 > motherboard chipset and graphics card ( Dell D630 ).
 > 
 > wpi0: device timeout
 > wpi0: could not set power mode
 > wpi0: device config failed
 > 
 > kldunload -> kldload panics the system often but not always. wpi0 device
 > timeouts happen more often with X/gnome running. wireless will not work
 > after this until a reboot ( when kldload doesn't cause kernel panics )
 
 I have found a very reliable (as in 100%) way to panic the system.
 
 - Turn radio off (via hardware switch)
 - Load the driver and firmware
 - Turn radio on (via hardware switch)
 
 Voilà, instant panic.
 
 -- 
 A: Because it fouls the order in which people normally read text.
 Q: Why is top-posting such a bad thing?
 A: Top-posting.
 Q: What is the most annoying thing on usenet and in e-mail? 

From: jeff curry <jeff@degrind.org>
To: bug-followup@FreeBSD.org
Cc: kamikaze@bsdforen.de
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Sun, 2 May 2010 12:45:41 -0700

 --0050450156d6b0f0cd0485a1b8cc
 Content-Type: text/plain; charset=ISO-8859-1
 
 This is happening to me as well, 8.0-release p2, amd64, 4 GB RAM, same
 motherboard chipset and graphics card ( Dell D630 ).
 
 wpi0: device timeout
 wpi0: could not set power mode
 wpi0: device config failed
 
 kldunload -> kldload panics the system often but not always. wpi0 device
 timeouts happen more often with X/gnome running. wireless will not work
 after this until a reboot ( when kldload doesn't cause kernel panics )
 
 --0050450156d6b0f0cd0485a1b8cc
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 This is happening to me as well, 8.0-release p2, amd64, 4 GB RAM, same moth=
 erboard chipset and graphics card ( Dell D630 ).<br><br>wpi0: device timeou=
 t<br>wpi0: could not set power mode<br>
 wpi0: device config failed<br><br>kldunload -&gt; kldload panics the system=
  often but not always. wpi0 device timeouts happen more often with X/gnome =
 running. wireless will not work after this until a reboot ( when kldload do=
 esn&#39;t cause kernel panics )<br>
 <br>
 
 --0050450156d6b0f0cd0485a1b8cc--

From: Dominic Fandrey <kamikaze@bsdforen.de>
To: bug-followup@FreeBSD.org, kamikaze@bsdforen.de
Cc:  
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Wed, 30 Jun 2010 09:59:36 +0200

 Just a followup. The device works when I reduce kern.hz to 200Hz.
 
 There's a 50% package loss, but TCP works fine as long as you can
 live with the increased latency. Of course you can forget about
 UDP.
 
 I can still reliably produce a panic by turning the hardware radio
 switch off while the device is up.
 
 Also the range of the device is really bad. I cannot establish a
 connection in the exact same spot where an atheros device works
 flawlessly and reports great reception.
 
 Regards
 
 -- 
 A: Because it fouls the order in which people normally read text.
 Q: Why is top-posting such a bad thing?
 A: Top-posting.
 Q: What is the most annoying thing on usenet and in e-mail? 

From: Alex Kozlov <spam@rm-rf.kiev.ua>
To: Dominic Fandrey <kamikaze@bsdforen.de>, bug-followup@freebsd.org,
	spam@rm-rf.kiev.ua
Cc:  
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Fri, 6 Aug 2010 00:52:26 +0300

 --7AUc2qLy4jB3hD7Z
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 Hi, Dominic
 
 It's seems to be common issue for many wireless if drivers.
 Can You please try this patch? Thanks.
 
 
 --
 Adios
 
 --7AUc2qLy4jB3hD7Z
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename="patch.txt"
 
 Index: sys/dev/wpi/if_wpi.c
 @@ -2399,7 +2399,7 @@
  wpi_auth(struct wpi_softc *sc, struct ieee80211vap *vap)
  {
  	struct ieee80211com *ic = vap->iv_ic;
 -	struct ieee80211_node *ni = vap->iv_bss;
 +	struct ieee80211_node *ni = ieee80211_ref_node(vap->iv_bss);
  	struct wpi_node_info node;
  	int error;
  
 @@ -2449,6 +2449,7 @@
  	node.action = htole32(WPI_ACTION_SET_RATE);
  	node.antenna = WPI_ANTENNA_BOTH;
  	error = wpi_cmd(sc, WPI_CMD_ADD_NODE, &node, sizeof node, 1);
 +	ieee80211_free_node(ni);
  	if (error != 0)
  		device_printf(sc->sc_dev, "could not add BSS node\n");
  
 @@ -2459,7 +2460,7 @@
  wpi_run(struct wpi_softc *sc, struct ieee80211vap *vap)
  {
  	struct ieee80211com *ic = vap->iv_ic;
 -	struct ieee80211_node *ni = vap->iv_bss;
 +	struct ieee80211_node *ni = ieee80211_ref_node(vap->iv_bss);
  	int error;
  
  	if (vap->iv_opmode == IEEE80211_M_MONITOR) {
 @@ -2493,8 +2494,9 @@
  	}
  
  	error = wpi_set_txpower(sc, ni->ni_chan, 1);
 +	ieee80211_free_node(ni);
  	if (error != 0) {
 -		device_printf(sc->sc_dev, "could set txpower\n");
 +		device_printf(sc->sc_dev, "could not set txpower\n");
  		return error;
  	}
  
 
 --7AUc2qLy4jB3hD7Z--

From: Dominic Fandrey <kamikaze@bsdforen.de>
To: Alex Kozlov <spam@rm-rf.kiev.ua>
Cc: bug-followup@freebsd.org
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Sun, 22 Aug 2010 10:25:09 +0200

 Hello,
 
 On 05/08/2010 23:52, Alex Kozlov wrote:
 > It's seems to be common issue for many wireless if drivers.
 > Can You please try this patch? Thanks.
 
 I finally got around to testing it. I'm mostly using an Atheros
 card, nowadays. Though I have to hotswap it to get past the BIOS.
 
 Your patch fixes all the reliably reproducible panics.
 
 I can scan for wireless networks and it yields the available networks.
 I can connect to a network and use it. There is no package loss,
 I'm currently stress-testing the connection, and it appears to be
 reliable.
 
 Now the downside. If I turn the network down and bring it up again
 it turns blind. An "ifconfig wlan0 list scan" will yield nothing
 and I cannot connect to a network. So I can use it only once.
 
 Unloading the module in between does not help either, so I have
 to reboot if I want to use it again.
 
 What kind of data are you interested in? Dmesg? Anything else?
 
 Regards
 
 -- 
 A: Because it fouls the order in which people normally read text.
 Q: Why is top-posting such a bad thing?
 A: Top-posting.
 Q: What is the most annoying thing on usenet and in e-mail? 

From: Bernhard Schmidt <bschmidt@techwires.net>
To: Dominic Fandrey <kamikaze@bsdforen.de>
Cc: bug-followup@freebsd.org
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Sun, 22 Aug 2010 15:38:00 +0200

 --0015175cfb9cf94b4a048e69a3da
 Content-Type: text/plain; charset=ISO-8859-1
 
 Hi,
 
 please give attached patch a shot, it should fix the issues with the
 RFKill button.
 
 Currently I'm not able to reproduce the other issues, I don't have 8
 GB RAM though.
 
 --
 Bernhard
 
 --0015175cfb9cf94b4a048e69a3da
 Content-Type: application/octet-stream; name="wpi_rfkill.diff"
 Content-Disposition: attachment; filename="wpi_rfkill.diff"
 Content-Transfer-Encoding: base64
 X-Attachment-Id: f_gd5xw6pa0
 
 SW5kZXg6IHN5cy9kZXYvd3BpL2lmX3dwaXZhci5oCj09PT09PT09PT09PT09PT09PT09PT09PT09
 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYvd3Bp
 L2lmX3dwaXZhci5oCShyZXZpc2lvbiAyMTE1NjcpCisrKyBzeXMvZGV2L3dwaS9pZl93cGl2YXIu
 aAkod29ya2luZyBjb3B5KQpAQCAtMTg1LDcgKzE4NSw4IEBAIHN0cnVjdCB3cGlfc29mdGMgewog
 CiAJLyogVGFza3MgdXNlZCBieSB0aGUgZHJpdmVyICovCiAJc3RydWN0IHRhc2sJCXNjX3Jlc3Rh
 cnR0YXNrOwkvKiByZXNldCBmaXJtd2FyZSB0YXNrICovCi0Jc3RydWN0IHRhc2sJCXNjX3JhZGlv
 dGFzazsJLyogcmVzZXQgcmYgdGFzayAqLworCXN0cnVjdCB0YXNrCQlzY19yYWRpb29udGFzazsJ
 LyogZGlzYWJsZSByZiB0YXNrICovCisJc3RydWN0IHRhc2sJCXNjX3JhZGlvb2ZmdGFzazsvKiBl
 bmFibGUgcmYgdGFzayAqLwogCiAgICAgICAgLyogRWVwcm9tIGluZm8gKi8KIAl1aW50OF90CQkJ
 Y2FwOwpJbmRleDogc3lzL2Rldi93cGkvaWZfd3BpLmMKPT09PT09PT09PT09PT09PT09PT09PT09
 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2Rldi93
 cGkvaWZfd3BpLmMJKHJldmlzaW9uIDIxMTU2NykKKysrIHN5cy9kZXYvd3BpL2lmX3dwaS5jCSh3
 b3JraW5nIGNvcHkpCkBAIC0yMjgsNyArMjI4LDggQEAgc3RhdGljIHZvaWQJd3BpX3N0b3BfbWFz
 dGVyKHN0cnVjdCB3cGlfc29mdGMgKik7CiBzdGF0aWMgaW50CXdwaV9wb3dlcl91cChzdHJ1Y3Qg
 d3BpX3NvZnRjICopOwogc3RhdGljIGludAl3cGlfcmVzZXQoc3RydWN0IHdwaV9zb2Z0YyAqKTsK
 IHN0YXRpYyB2b2lkCXdwaV9od3Jlc2V0KHZvaWQgKiwgaW50KTsKLXN0YXRpYyB2b2lkCXdwaV9y
 ZnJlc2V0KHZvaWQgKiwgaW50KTsKK3N0YXRpYyB2b2lkCXdwaV9yYWRpb19vZmYodm9pZCAqLCBp
 bnQpOworc3RhdGljIHZvaWQJd3BpX3JhZGlvX29uKHZvaWQgKiwgaW50KTsKIHN0YXRpYyB2b2lk
 CXdwaV9od19jb25maWcoc3RydWN0IHdwaV9zb2Z0YyAqKTsKIHN0YXRpYyB2b2lkCXdwaV9pbml0
 KHZvaWQgKik7CiBzdGF0aWMgdm9pZAl3cGlfaW5pdF9sb2NrZWQoc3RydWN0IHdwaV9zb2Z0YyAq
 LCBpbnQpOwpAQCAtNTE0LDcgKzUxNSw4IEBAIHdwaV9hdHRhY2goZGV2aWNlX3QgZGV2KQogCiAJ
 LyogQ3JlYXRlIHRoZSB0YXNrcyB0aGF0IGNhbiBiZSBxdWV1ZWQgKi8KIAlUQVNLX0lOSVQoJnNj
 LT5zY19yZXN0YXJ0dGFzaywgMCwgd3BpX2h3cmVzZXQsIHNjKTsKLQlUQVNLX0lOSVQoJnNjLT5z
 Y19yYWRpb3Rhc2ssIDAsIHdwaV9yZnJlc2V0LCBzYyk7CisJVEFTS19JTklUKCZzYy0+c2NfcmFk
 aW9vbnRhc2ssIDAsIHdwaV9yYWRpb19vbiwgc2MpOworCVRBU0tfSU5JVCgmc2MtPnNjX3JhZGlv
 b2ZmdGFzaywgMCwgd3BpX3JhZGlvX29mZiwgc2MpOwogCiAJV1BJX0xPQ0tfSU5JVChzYyk7CiAK
 QEAgLTcxOSw3ICs3MjEsOCBAQCB3cGlfZGV0YWNoKGRldmljZV90IGRldikKIAkJaWMgPSBpZnAt
 PmlmX2wyY29tOwogCiAJCWllZWU4MDIxMV9kcmFpbnRhc2soaWMsICZzYy0+c2NfcmVzdGFydHRh
 c2spOwotCQlpZWVlODAyMTFfZHJhaW50YXNrKGljLCAmc2MtPnNjX3JhZGlvdGFzayk7CisJCWll
 ZWU4MDIxMV9kcmFpbnRhc2soaWMsICZzYy0+c2NfcmFkaW9vbnRhc2spOworCQlpZWVlODAyMTFf
 ZHJhaW50YXNrKGljLCAmc2MtPnNjX3JhZGlvb2ZmdGFzayk7CiAJCXdwaV9zdG9wKHNjKTsKIAkJ
 Y2FsbG91dF9kcmFpbigmc2MtPndhdGNoZG9nX3RvKTsKIAkJY2FsbG91dF9kcmFpbigmc2MtPmNh
 bGliX3RvKTsKQEAgLTE2NzYsMTcgKzE2NzksMjAgQEAgd3BpX25vdGlmX2ludHIoc3RydWN0IHdw
 aV9zb2Z0YyAqc2MpCiAJCWNhc2UgV1BJX1NUQVRFX0NIQU5HRUQ6CiAJCXsKIAkJCXVpbnQzMl90
 ICpzdGF0dXMgPSAodWludDMyX3QgKikoZGVzYyArIDEpOworCQkJc3RydWN0IGllZWU4MDIxMXZh
 cCAqdmFwID0gVEFJTFFfRklSU1QoJmljLT5pY192YXBzKTsKIAogCQkJLyogZW5hYmxlZC9kaXNh
 YmxlZCBub3RpZmljYXRpb24gKi8KIAkJCURQUklOVEYoKCJzdGF0ZSBjaGFuZ2VkIHRvICV4XG4i
 LCBsZTMydG9oKCpzdGF0dXMpKSk7CiAKIAkJCWlmIChsZTMydG9oKCpzdGF0dXMpICYgMSkgewor
 CQkJCXNjLT5zY19zY2FuX3RpbWVyID0gMDsKKwkJCQlpZiAodmFwKSB7CisJCQkJCWllZWU4MDIx
 MV9jYW5jZWxfc2Nhbih2YXApOworCQkJCQlpZWVlODAyMTFfbm90aWZ5X3NjYW5fZG9uZSh2YXAp
 OworCQkJCX0KIAkJCQlkZXZpY2VfcHJpbnRmKHNjLT5zY19kZXYsCiAJCQkJICAgICJSYWRpbyB0
 cmFuc21pdHRlciBpcyBzd2l0Y2hlZCBvZmZcbiIpOwotCQkJCXNjLT5mbGFncyB8PSBXUElfRkxB
 R19IV19SQURJT19PRkY7Ci0JCQkJaWZwLT5pZl9kcnZfZmxhZ3MgJj0gfklGRl9EUlZfUlVOTklO
 RzsKLQkJCQkvKiBEaXNhYmxlIGZpcm13YXJlIGNvbW1hbmRzICovCi0JCQkJV1BJX1dSSVRFKHNj
 LCBXUElfVUNPREVfU0VULCBXUElfRElTQUJMRV9DTUQpOworCQkJCWllZWU4MDIxMV9ydW50YXNr
 KGljLCAmc2MtPnNjX3JhZGlvb2ZmdGFzayk7CiAJCQl9CiAJCQlicmVhazsKIAkJfQpAQCAtMjA5
 NCw4ICsyMTAwLDcgQEAgd3BpX2lvY3RsKHN0cnVjdCBpZm5ldCAqaWZwLCB1X2xvbmcgY21kLCBj
 YWRkcl90IGQKIAkJCQl3cGlfaW5pdF9sb2NrZWQoc2MsIDApOwogCQkJCXN0YXJ0YWxsID0gMTsK
 IAkJCX0KLQkJfSBlbHNlIGlmICgoaWZwLT5pZl9kcnZfZmxhZ3MgJiBJRkZfRFJWX1JVTk5JTkcp
 IHx8Ci0JCQkgICAoc2MtPmZsYWdzICYgV1BJX0ZMQUdfSFdfUkFESU9fT0ZGKSkKKwkJfSBlbHNl
 IGlmICgoaWZwLT5pZl9kcnZfZmxhZ3MgJiBJRkZfRFJWX1JVTk5JTkcpKQogCQkJd3BpX3N0b3Bf
 bG9ja2VkKHNjKTsKIAkJV1BJX1VOTE9DSyhzYyk7CiAJCWlmIChzdGFydGFsbCkKQEAgLTI5Njcs
 NTkgKzI5NzIsNiBAQCB3cGlfaHdfY29uZmlnKHN0cnVjdCB3cGlfc29mdGMgKnNjKQogfQogCiBz
 dGF0aWMgdm9pZAotd3BpX3Jma2lsbF9yZXN1bWUoc3RydWN0IHdwaV9zb2Z0YyAqc2MpCi17Ci0J
 c3RydWN0IGlmbmV0ICppZnAgPSBzYy0+c2NfaWZwOwotCXN0cnVjdCBpZWVlODAyMTFjb20gKmlj
 ID0gaWZwLT5pZl9sMmNvbTsKLQlzdHJ1Y3QgaWVlZTgwMjExdmFwICp2YXAgPSBUQUlMUV9GSVJT
 VCgmaWMtPmljX3ZhcHMpOwotCWludCBudHJpZXM7Ci0KLQkvKiBlbmFibGUgZmlybXdhcmUgYWdh
 aW4gKi8KLQlXUElfV1JJVEUoc2MsIFdQSV9VQ09ERV9DTFIsIFdQSV9SQURJT19PRkYpOwotCVdQ
 SV9XUklURShzYywgV1BJX1VDT0RFX0NMUiwgV1BJX0RJU0FCTEVfQ01EKTsKLQotCS8qIHdhaXQg
 Zm9yIHRoZXJtYWwgc2Vuc29ycyB0byBjYWxpYnJhdGUgKi8KLQlmb3IgKG50cmllcyA9IDA7IG50
 cmllcyA8IDEwMDA7IG50cmllcysrKSB7Ci0JCWlmICgoc2MtPnRlbXAgPSAoaW50KVdQSV9SRUFE
 KHNjLCBXUElfVEVNUEVSQVRVUkUpKSAhPSAwKQotCQkJYnJlYWs7Ci0JCURFTEFZKDEwKTsKLQl9
 Ci0KLQlpZiAobnRyaWVzID09IDEwMDApIHsKLQkJZGV2aWNlX3ByaW50ZihzYy0+c2NfZGV2LAot
 CQkgICAgInRpbWVvdXQgd2FpdGluZyBmb3IgdGhlcm1hbCBjYWxpYnJhdGlvblxuIik7Ci0JCVdQ
 SV9VTkxPQ0soc2MpOwotCQlyZXR1cm47Ci0JfQotCURQUklOVEZOKFdQSV9ERUJVR19URU1QLCgi
 dGVtcGVyYXR1cmUgJWRcbiIsIHNjLT50ZW1wKSk7Ci0KLQlpZiAod3BpX2NvbmZpZyhzYykgIT0g
 MCkgewotCQlkZXZpY2VfcHJpbnRmKHNjLT5zY19kZXYsICJkZXZpY2UgY29uZmlnIGZhaWxlZFxu
 Iik7Ci0JCVdQSV9VTkxPQ0soc2MpOwotCQlyZXR1cm47Ci0JfQotCi0JaWZwLT5pZl9kcnZfZmxh
 Z3MgJj0gfklGRl9EUlZfT0FDVElWRTsKLQlpZnAtPmlmX2Rydl9mbGFncyB8PSBJRkZfRFJWX1JV
 Tk5JTkc7Ci0Jc2MtPmZsYWdzICY9IH5XUElfRkxBR19IV19SQURJT19PRkY7Ci0KLQlpZiAodmFw
 ICE9IE5VTEwpIHsKLQkJaWYgKChpYy0+aWNfZmxhZ3MgJiBJRUVFODAyMTFfRl9TQ0FOKSA9PSAw
 KSB7Ci0JCQlpZiAodmFwLT5pdl9vcG1vZGUgIT0gSUVFRTgwMjExX01fTU9OSVRPUikgewotCQkJ
 CWllZWU4MDIxMV9iZWFjb25fbWlzcyhpYyk7Ci0JCQkJd3BpX3NldF9sZWQoc2MsIFdQSV9MRURf
 TElOSywgMCwgMSk7Ci0JCQl9IGVsc2UKLQkJCQl3cGlfc2V0X2xlZChzYywgV1BJX0xFRF9MSU5L
 LCA1LCA1KTsKLQkJfSBlbHNlIHsKLQkJCWllZWU4MDIxMV9zY2FuX25leHQodmFwKTsKLQkJCXdw
 aV9zZXRfbGVkKHNjLCBXUElfTEVEX0xJTkssIDIwLCAyKTsKLQkJfQotCX0KLQotCWNhbGxvdXRf
 cmVzZXQoJnNjLT53YXRjaGRvZ190bywgaHosIHdwaV93YXRjaGRvZywgc2MpOwotfQotCi1zdGF0
 aWMgdm9pZAogd3BpX2luaXRfbG9ja2VkKHN0cnVjdCB3cGlfc29mdGMgKnNjLCBpbnQgZm9yY2Up
 CiB7CiAJc3RydWN0IGlmbmV0ICppZnAgPSBzYy0+c2NfaWZwOwpAQCAtMzU4NiwxNSArMzUzOCwz
 NiBAQCB3cGlfaHdyZXNldCh2b2lkICphcmcsIGludCBwZW5kaW5nKQogfQogCiBzdGF0aWMgdm9p
 ZAotd3BpX3JmcmVzZXQodm9pZCAqYXJnLCBpbnQgcGVuZGluZykKK3dwaV9yYWRpb19vZmYodm9p
 ZCAqYXJnLCBpbnQgcGVuZGluZykKIHsKIAlzdHJ1Y3Qgd3BpX3NvZnRjICpzYyA9IGFyZzsKKwlz
 dHJ1Y3QgaWZuZXQgKmlmcCA9IHNjLT5zY19pZnA7CisJc3RydWN0IGllZWU4MDIxMWNvbSAqaWMg
 PSBpZnAtPmlmX2wyY29tOworCXN0cnVjdCBpZWVlODAyMTF2YXAgKnZhcCA9IFRBSUxRX0ZJUlNU
 KCZpYy0+aWNfdmFwcyk7CiAKLQlXUElfTE9DSyhzYyk7Ci0Jd3BpX3Jma2lsbF9yZXN1bWUoc2Mp
 OwotCVdQSV9VTkxPQ0soc2MpOworCXdwaV9zdG9wKHNjKTsKKwlpZiAodmFwICE9IE5VTEwpCisJ
 CWllZWU4MDIxMV9zdG9wKHZhcCk7CisKKwlzYy0+ZmxhZ3MgfD0gV1BJX0ZMQUdfSFdfUkFESU9f
 T0ZGOworCWNhbGxvdXRfcmVzZXQoJnNjLT53YXRjaGRvZ190bywgaHosIHdwaV93YXRjaGRvZywg
 c2MpOwogfQogCitzdGF0aWMgdm9pZAord3BpX3JhZGlvX29uKHZvaWQgKmFyZywgaW50IHBlbmRp
 bmcpCit7CisJc3RydWN0IHdwaV9zb2Z0YyAqc2MgPSBhcmc7CisJc3RydWN0IGlmbmV0ICppZnAg
 PSBzYy0+c2NfaWZwOworCXN0cnVjdCBpZWVlODAyMTFjb20gKmljID0gaWZwLT5pZl9sMmNvbTsK
 KwlzdHJ1Y3QgaWVlZTgwMjExdmFwICp2YXAgPSBUQUlMUV9GSVJTVCgmaWMtPmljX3ZhcHMpOwor
 CisJc2MtPmZsYWdzICY9IH5XUElfRkxBR19IV19SQURJT19PRkY7CisKKwl3cGlfaW5pdChzYyk7
 CisJaWYgKHZhcCAhPSBOVUxMKQorCQlpZWVlODAyMTFfaW5pdCh2YXApOworfQorCiAvKgogICog
 QWxsb2NhdGUgRE1BLXNhZmUgbWVtb3J5IGZvciBmaXJtd2FyZSB0cmFuc2Zlci4KICAqLwpAQCAt
 MzYzOCw3ICszNjExLDcgQEAgd3BpX3dhdGNoZG9nKHZvaWQgKmFyZykKIAkJfQogCiAJCWRldmlj
 ZV9wcmludGYoc2MtPnNjX2RldiwgIkhhcmR3YXJlIFN3aXRjaCBFbmFibGVkXG4iKTsKLQkJaWVl
 ZTgwMjExX3J1bnRhc2soaWMsICZzYy0+c2NfcmFkaW90YXNrKTsKKwkJaWVlZTgwMjExX3J1bnRh
 c2soaWMsICZzYy0+c2NfcmFkaW9vbnRhc2spOwogCQlyZXR1cm47CiAJfQogCg==
 --0015175cfb9cf94b4a048e69a3da--

From: Dominic Fandrey <kamikaze@bsdforen.de>
To: Bernhard Schmidt <bschmidt@techwires.net>
Cc: bug-followup@freebsd.org
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Sun, 22 Aug 2010 19:48:46 +0200

 On 22/08/2010 15:38, Bernhard Schmidt wrote:
 > Hi,
 > 
 > please give attached patch a shot, it should fix the issues with the
 > RFKill button.
 > 
 > Currently I'm not able to reproduce the other issues, I don't have 8
 > GB RAM though.
 
 I have now both your patch an Alex's patch applied and everything
 seems to be working. I hope both patches make it into RELENG_8.
 
 I'll get back to you once I've used it for a time. Alex's patch
 already fixed the panic when turning the radio switch off, but
 with your patch I can also connect to a network more than once.
 
 Regards
 
 -- 
 A: Because it fouls the order in which people normally read text.
 Q: Why is top-posting such a bad thing?
 A: Top-posting.
 Q: What is the most annoying thing on usenet and in e-mail? 

From: Bernhard Schmidt <bschmidt@techwires.net>
To: Dominic Fandrey <kamikaze@bsdforen.de>
Cc: bug-followup@freebsd.org
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Mon, 23 Aug 2010 09:06:46 +0200

 On Sun, Aug 22, 2010 at 19:48, Dominic Fandrey <kamikaze@bsdforen.de> wrote:
 > On 22/08/2010 15:38, Bernhard Schmidt wrote:
 >> Hi,
 >>
 >> please give attached patch a shot, it should fix the issues with the
 >> RFKill button.
 >>
 >> Currently I'm not able to reproduce the other issues, I don't have 8
 >> GB RAM though.
 >
 > I have now both your patch an Alex's patch applied and everything
 > seems to be working. I hope both patches make it into RELENG_8.
 >
 > I'll get back to you once I've used it for a time. Alex's patch
 > already fixed the panic when turning the radio switch off, but
 > with your patch I can also connect to a network more than once.
 
 Alex's patch addresses a different issue, there is a race with
 wpa_supplicant (/etc/rc.d/netif restart) which might free a node while
 one of the wpi functions is using it. It shouldn't make any difference
 in your case, though, it's nice to fix this now and I probably going
 to commit it anyways.
 
 Please let me know if there a any stability issues left, it made a
 pretty good impressions over this weekend while I did run some tests.
 
 Thanks.
 
 -- 
 Bernhard
Responsible-Changed-From-To: freebsd-net->bschmidt 
Responsible-Changed-By: bschmidt 
Responsible-Changed-When: Mon Aug 23 07:11:33 UTC 2010 
Responsible-Changed-Why:  
Over to me. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=144898 

From: Dominic Fandrey <kamikaze@bsdforen.de>
To: Bernhard Schmidt <bschmidt@techwires.net>
Cc: bug-followup@freebsd.org
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Mon, 23 Aug 2010 09:20:12 +0200

 On 23/08/2010 09:06, Bernhard Schmidt wrote:
 > On Sun, Aug 22, 2010 at 19:48, Dominic Fandrey <kamikaze@bsdforen.de> wrote:
 >> On 22/08/2010 15:38, Bernhard Schmidt wrote:
 >>> Hi,
 >>>
 >>> please give attached patch a shot, it should fix the issues with the
 >>> RFKill button.
 >>>
 >>> Currently I'm not able to reproduce the other issues, I don't have 8
 >>> GB RAM though.
 >>
 >> I have now both your patch an Alex's patch applied and everything
 >> seems to be working. I hope both patches make it into RELENG_8.
 >>
 >> I'll get back to you once I've used it for a time. Alex's patch
 >> already fixed the panic when turning the radio switch off, but
 >> with your patch I can also connect to a network more than once.
 > 
 > Alex's patch addresses a different issue, there is a race with
 > wpa_supplicant (/etc/rc.d/netif restart) which might free a node while
 > one of the wpi functions is using it. It shouldn't make any difference
 > in your case, though, it's nice to fix this now and I probably going
 > to commit it anyways.
 > 
 > Please let me know if there a any stability issues left, it made a
 > pretty good impressions over this weekend while I did run some tests.
 
 Yesterday, I lost the connection to a WPA2 net. Afterwards I couldn't
 reconnect any more. A "list scan" still yielded the current list of
 available APs, though. Even after a down and up.
 
 This morning I had a freeze when connecting to my university network.
 The script is like that:
 
 ifconfig wlan0 ssid up
 sleep 2
 aps=$(ifconfig wlan0 list scan)
 ifconfig wlan0 ssid <AP with the best connection>
 dhclient wlan0
 vpnc
 
 I have no idea at which point the freeze happened. I just repeated
 the procedure manually and the system didn't freeze.
 
 Regards
 
 -- 
 A: Because it fouls the order in which people normally read text.
 Q: Why is top-posting such a bad thing?
 A: Top-posting.
 Q: What is the most annoying thing on usenet and in e-mail? 

From: Bernhard Schmidt <bschmidt@techwires.net>
To: Dominic Fandrey <kamikaze@bsdforen.de>
Cc: bug-followup@freebsd.org
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Mon, 23 Aug 2010 09:26:06 +0200

 On Mon, Aug 23, 2010 at 09:20, Dominic Fandrey <kamikaze@bsdforen.de> wrote:
 > On 23/08/2010 09:06, Bernhard Schmidt wrote:
 >> Please let me know if there a any stability issues left, it made a
 >> pretty good impressions over this weekend while I did run some tests.
 >
 > Yesterday, I lost the connection to a WPA2 net. Afterwards I couldn't
 > reconnect any more. A "list scan" still yielded the current list of
 > available APs, though. Even after a down and up.
 >
 > This morning I had a freeze when connecting to my university network.
 > The script is like that:
 >
 > ifconfig wlan0 ssid up
 > sleep 2
 > aps=$(ifconfig wlan0 list scan)
 > ifconfig wlan0 ssid <AP with the best connection>
 > dhclient wlan0
 > vpnc
 >
 > I have no idea at which point the freeze happened. I just repeated
 > the procedure manually and the system didn't freeze.
 
 Ok thanks, I'll look into that.
 
 Can you enable debug output for wpi? (sysctl debug.wpi=1) and show me
 the output? I expect there to be some messages related to beacon
 misses.
 
 
 --
 Bernhard

From: Sulev-Madis Silber <madis555@hot.ee>
To: bug-followup@FreeBSD.org, kamikaze@bsdforen.de, 
 bschmidt@techwires.net
Cc:  
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Mon, 13 Dec 2010 09:02:25 +0200

 Hello.
 
 I recently got new Lenovo T60 with that "infamous" card installed...
 
 
 I'm running 8.1-RELEASE-p2, I've also applied these two patches.
 It's better now, indeed, but it's still, sorry, pretty f* unstable (and
 unusable).
 
 It crashed when I played RF kill switch (I got weird "RRAAMM
 ppaarriittyy eerroorr"),
 then crashed when I issued scan while card was associated to open AP. I
 remember doing this many times until it crashed (or freezed, to be correct).
 I currently have no error message for you, active console wasn't ttyv0.
 
 
 Now I'm searching either USB adapter or PCMCIA card and seriously want
 to change internal card.
 But this used (actually pretty unused :)) laptop is under 3 month
 warranty and then I can't help you anymore with these issues (which is
 important to me).
 
 Plus I want to have two cards anyway, with at least one HostAP-capable.
 Just in case some hotel decides to take such stupid amount of money for
 just a one connection again...
 Any suggestions on that?
 
 
 And maybe we get that Intel card working too.
 
 
 Thanks.

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/144898: commit references a PR
Date: Sat, 18 Dec 2010 15:25:27 +0000 (UTC)

 Author: bschmidt
 Date: Sat Dec 18 15:25:21 2010
 New Revision: 216521
 URL: http://svn.freebsd.org/changeset/base/216521
 
 Log:
   Fix a panic while disabling the RF kill button, caller of the
   wpi_rfkill_resume() function will take care of the lock.
   
   PR:		kern/144898
   MFC after:	3 days
 
 Modified:
   head/sys/dev/wpi/if_wpi.c
 
 Modified: head/sys/dev/wpi/if_wpi.c
 ==============================================================================
 --- head/sys/dev/wpi/if_wpi.c	Sat Dec 18 14:34:05 2010	(r216520)
 +++ head/sys/dev/wpi/if_wpi.c	Sat Dec 18 15:25:21 2010	(r216521)
 @@ -3004,14 +3004,12 @@ wpi_rfkill_resume(struct wpi_softc *sc)
  	if (ntries == 1000) {
  		device_printf(sc->sc_dev,
  		    "timeout waiting for thermal calibration\n");
 -		WPI_UNLOCK(sc);
  		return;
  	}
  	DPRINTFN(WPI_DEBUG_TEMP,("temperature %d\n", sc->temp));
  
  	if (wpi_config(sc) != 0) {
  		device_printf(sc->sc_dev, "device config failed\n");
 -		WPI_UNLOCK(sc);
  		return;
  	}
  
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: open->feedback 
State-Changed-By: bschmidt 
State-Changed-When: Mon Dec 27 10:39:31 UTC 2010 
State-Changed-Why:  
feedback has been requested 

http://www.freebsd.org/cgi/query-pr.cgi?pr=144898 

From: Bernhard Schmidt <bschmidt@freebsd.org>
To: kamikaze@bsdforen.de
Cc: "Sulev-Madis Silber" <madis555@hot.ee>,
 bug-followup@freebsd.org
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Mon, 27 Dec 2010 11:34:24 +0100

 Hi,
 
 As you might have noticed, I committed a bunch of fixed to wpi(4) which are 
 now included in 8.2-RC1. Could you please test that in regard to this PR and 
 let me know about the outcome?
 
 Thanks
 
 -- 
 Bernhard

From: Sulev-Madis Silber <madis555@hot.ee>
To: Bernhard Schmidt <bschmidt@freebsd.org>
Cc: kamikaze@bsdforen.de, bug-followup@freebsd.org
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Tue, 28 Dec 2010 05:05:16 +0200

 Monitor mode indeed works now! Good work!
 
 Will test station connectivity later. I have no active AP here I could use.
 ...
 Wait, I just now managed to crash it again. Like before, I issued
 "ifconfig wlan0 scan" and there it went.
 And again, station was associated to local public open AP, in 11g mode.
 
 Is this something you can't replicate on your hardware?
 
 
 And lately I bought new USB adapter advertised having Atheros chip. It
 indeed seems to be Atheros, but it's new AR9271 chip. Sale item is
 called TP-Link WN322G v3.
 
 
 On 2010-12-27 12:34, Bernhard Schmidt wrote:
 > Hi,
 > 
 > As you might have noticed, I committed a bunch of fixed to wpi(4) which are 
 > now included in 8.2-RC1. Could you please test that in regard to this PR and 
 > let me know about the outcome?
 > 
 > Thanks
 > 

From: Bernhard Schmidt <bschmidt@freebsd.org>
To: "Sulev-Madis Silber" <madis555@hot.ee>
Cc: kamikaze@bsdforen.de,
 bug-followup@freebsd.org
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Tue, 28 Dec 2010 09:39:10 +0100

 On Tuesday 28 December 2010 04:05:16 Sulev-Madis Silber wrote:
 > Monitor mode indeed works now! Good work!
 
 fine, thanks
  
 > Will test station connectivity later. I have no active AP here I could use.
 > ...
 > Wait, I just now managed to crash it again. Like before, I issued
 > "ifconfig wlan0 scan" and there it went.
 > And again, station was associated to local public open AP, in 11g mode.
 > 
 > Is this something you can't replicate on your hardware?
 
 You've issued 'ifconfig scan' while you were associated to an AP, right? This 
 I guess is a known issue, wpi(4) does not support background scans, which is 
 what you want to do at that point. This though, should just result in a 
 firmware error, did you get one? I might look into adding a check to prevent a 
 scan being done while there is no actual support for it..
 
 > And lately I bought new USB adapter advertised having Atheros chip. It
 > indeed seems to be Atheros, but it's new AR9271 chip. Sale item is
 > called TP-Link WN322G v3.
 
 No support for that chip series afaik, I'm not aware of anyone working on 
 porting a driver currently.
 
 -- 
 Bernhard

From: Sulev-Madis Silber <madis555@hot.ee>
To: Bernhard Schmidt <bschmidt@freebsd.org>
Cc: kamikaze@bsdforen.de, bug-followup@freebsd.org
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Tue, 28 Dec 2010 11:52:13 +0200

 On 2010-12-28 10:39, Bernhard Schmidt wrote:
 > You've issued 'ifconfig scan' while you were associated to an AP, right? This 
 > I guess is a known issue, wpi(4) does not support background scans, which is 
 > what you want to do at that point. This though, should just result in a 
 > firmware error, did you get one? I might look into adding a check to prevent a 
 > scan being done while there is no actual support for it..
 
 Not sure what I got ("rraamm ppaarriittyy eerrrroorr" again).
 I made "screen shot" of it, because I have no serial console to get
 textual information out.
 
 But what I know is when I issue background scan, it always panics, tried
 two more times.
 It would be nice to have check there to disallow that.
 
 
 >> And lately I bought new USB adapter advertised having Atheros chip. It
 >> indeed seems to be Atheros, but it's new AR9271 chip. Sale item is
 >> called TP-Link WN322G v3.
 > 
 > No support for that chip series afaik, I'm not aware of anyone working on 
 > porting a driver currently.
 
 I forgot to add that indeed, I tried and it's not supported. This USB ID
 (0x1006) is supported in OpenBSD, however...
 
 Sadly I currently don't know how to hack such things myself :(
 It can change, of course :)

From: Dominic Fandrey <kamikaze@bsdforen.de>
To: Bernhard Schmidt <bschmidt@freebsd.org>
Cc: Sulev-Madis Silber <madis555@hot.ee>, bug-followup@freebsd.org
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Tue, 28 Dec 2010 14:36:05 +0100

 On 27/12/2010 11:34, Bernhard Schmidt wrote:
 > As you might have noticed, I committed a bunch of fixed to wpi(4) which are 
 > now included in 8.2-RC1. Could you please test that in regard to this PR and 
 > let me know about the outcome?
 
 
 I have done some tests in the unencrypted 27c3 conference network.
 
 This looks really good to me.
 
 Dangerous things I tried:
 
 * Multiple network scans in sequence WORK and don't appear
   to panic the system
 * Connecting to an unencrypted network works
 * Turning the WLAN hardware switch off, while connected to a
   network does NOT panic the system
 
 I'll do WPA testing when I'm back home (~4 days from now).
 
 Something of interest, the driver prints a WLAN off message, but
 the wlan0 device still claims to be associated, when I trigger
 the hardware switch.
 
 The driver also prints a WLAN on message when I turn it back on.
 But I have to manually bring the wlan0 device down and up to
 reconnect.
 
 Now the bad news. If the wireless connection is bad, ALL TCP
 communication on the system breaks down. Including the communication
 between X clients and X server! I.e. every X program sooner or later
 looses its X connection and crashes.
 
 Regards

From: Dominic Fandrey <kamikaze@bsdforen.de>
To: bug-followup@FreeBSD.org, kamikaze@bsdforen.de
Cc:  
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Tue, 28 Dec 2010 17:15:28 +0100

 To clarify some things. That wpi somehow drags down the TCP stack
 is an assumption, based on what happens when a TCP connection is
 on.
 
 What happens is that X clients sporadically die, sometimes the WM is
 the client, killing all currently running X clients with it.
 
 Thunderbird (while still running) issues complaints about SSL and
 links about zlib errors. All this leads me to conclude that some
 data corruption is occurring.
 
 
 Also I found a new problem, this is from my dmesg:
 ...
 wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
 wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
 wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
 wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
 wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
 wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
 wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
 wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
 wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
 wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
 wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
 wpi0: could not map mbuf (error 12)
 wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
 wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
 wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
 wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
 ...
 
 The wpi_rx_intr messages appeared at breakneck speed until I turned
 the interface down. The mbuf error was thrown in occasionally. It
 did not appear to occur at a fixed frequency.
 
 Regards

From: Bernhard Schmidt <bschmidt@freebsd.org>
To: Dominic Fandrey <kamikaze@bsdforen.de>
Cc: bug-followup@freebsd.org
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Thu, 30 Dec 2010 11:57:18 +0100

 On Tuesday 28 December 2010 17:30:15 Dominic Fandrey wrote:
 >  Also I found a new problem, this is from my dmesg:
 >  wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
 >  ..
 >  wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
 > 
 >  The wpi_rx_intr messages appeared at breakneck speed until I turned
 >  the interface down. The mbuf error was thrown in occasionally. It
 >  did not appear to occur at a fixed frequency.
 
 I've seen this one too.. though, no clue about the cause nor a way to reliably 
 reproduce it. Do you have a scenario where this always happens?
 
 --
 Bernhard

From: Dominic Fandrey <kamikaze@bsdforen.de>
To: Bernhard Schmidt <bschmidt@freebsd.org>
Cc: bug-followup@freebsd.org
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Thu, 30 Dec 2010 16:28:15 +0100

 On 30/12/2010 11:57, Bernhard Schmidt wrote:
 > On Tuesday 28 December 2010 17:30:15 Dominic Fandrey wrote:
 >>  Also I found a new problem, this is from my dmesg:
 >>  wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
 >>  ..
 >>  wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
 >>
 >>  The wpi_rx_intr messages appeared at breakneck speed until I turned
 >>  the interface down. The mbuf error was thrown in occasionally. It
 >>  did not appear to occur at a fixed frequency.
 > 
 > I've seen this one too.. though, no clue about the cause nor a way to reliably 
 > reproduce it. Do you have a scenario where this always happens?
 
 No, sorry to say so, I don't.
 
 Regards

From: Bernhard Schmidt <bschmidt@freebsd.org>
To: Dominic Fandrey <kamikaze@bsdforen.de>
Cc: bug-followup@freebsd.org
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Thu, 30 Dec 2010 19:18:27 +0100

 On Thursday 30 December 2010 16:30:12 Dominic Fandrey wrote:
 > The following reply was made to PR kern/144898; it has been noted by GNATS.
 > 
 > From: Dominic Fandrey <kamikaze@bsdforen.de>
 > To: Bernhard Schmidt <bschmidt@freebsd.org>
 > Cc: bug-followup@freebsd.org
 > Subject: Re: kern/144898: [wpi] [panic] wpi panics system
 > Date: Thu, 30 Dec 2010 16:28:15 +0100
 > 
 >  On 30/12/2010 11:57, Bernhard Schmidt wrote:
 >  > On Tuesday 28 December 2010 17:30:15 Dominic Fandrey wrote:
 >  >>  Also I found a new problem, this is from my dmesg:
 >  >>  wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
 >  >>  ..
 >  >>  wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
 >  >>  
 >  >>  The wpi_rx_intr messages appeared at breakneck speed until I turned
 >  >>  the interface down. The mbuf error was thrown in occasionally. It
 >  >>  did not appear to occur at a fixed frequency.
 >  > 
 >  > I've seen this one too.. though, no clue about the cause nor a way to
 >  > reliably reproduce it. Do you have a scenario where this always
 >  > happens?
 > 
 >  No, sorry to say so, I don't.
 
 I found a way to trigger this, after a clean boot, executing
 i=0
 while [ $i -lt 100 ]; do
 	kldload if_wpi
 	ifconfig wlan0 create wlandev wpi0
 	sleep 0.5
 	kldunload if_wpi
 	i=$(expr $i + 1)
 done
 
 kldload if_wpi
 ifconfig wlan0 create wlandev wpi0
 ifconfig wlan0 ssid iwn2 channel 7 10.1.1.157/16 up
 
 and then doing lots of RX traffic triggered it 100% reliably.
 Patch coming ASAP.
 
 -- 
 Bernhard

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/144898: commit references a PR
Date: Thu, 30 Dec 2010 18:29:31 +0000 (UTC)

 Author: bschmidt
 Date: Thu Dec 30 18:29:22 2010
 New Revision: 216824
 URL: http://svn.freebsd.org/changeset/base/216824
 
 Log:
   The RX path is missing a few bus_dmamap_*() calls, this results in
   modification of memory which was already free'd and eventually in:
   wpi0: could not map mbuf (error 12)
   wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
   and an usuable device.
   
   PR:		kern/144898
   MFC after:	3 days
 
 Modified:
   head/sys/dev/wpi/if_wpi.c
 
 Modified: head/sys/dev/wpi/if_wpi.c
 ==============================================================================
 --- head/sys/dev/wpi/if_wpi.c	Thu Dec 30 18:06:31 2010	(r216823)
 +++ head/sys/dev/wpi/if_wpi.c	Thu Dec 30 18:29:22 2010	(r216824)
 @@ -1052,9 +1052,18 @@ wpi_free_rx_ring(struct wpi_softc *sc, s
  
  	wpi_dma_contig_free(&ring->desc_dma);
  
 -	for (i = 0; i < WPI_RX_RING_COUNT; i++)
 -		if (ring->data[i].m != NULL)
 -			m_freem(ring->data[i].m);
 +	for (i = 0; i < WPI_RX_RING_COUNT; i++) {
 +		struct wpi_rx_data *data = &ring->data[i];
 +
 +		if (data->m != NULL) {
 +			bus_dmamap_sync(ring->data_dmat, data->map,
 +			    BUS_DMASYNC_POSTREAD);
 +			bus_dmamap_unload(ring->data_dmat, data->map);
 +			m_freem(data->m);
 +		}
 +		if (data->map != NULL)
 +			bus_dmamap_destroy(ring->data_dmat, data->map);
 +	}
  }
  
  static int
 @@ -1461,6 +1470,7 @@ wpi_rx_intr(struct wpi_softc *sc, struct
  		return;
  	}
  
 +	bus_dmamap_sync(ring->data_dmat, data->map, BUS_DMASYNC_POSTREAD);
  	head = (struct wpi_rx_head *)((caddr_t)(stat + 1) + stat->len);
  	tail = (struct wpi_rx_tail *)((caddr_t)(head + 1) + le16toh(head->len));
  
 @@ -1491,6 +1501,8 @@ wpi_rx_intr(struct wpi_softc *sc, struct
  		ifp->if_ierrors++;
  		return;
  	}
 +	bus_dmamap_unload(ring->data_dmat, data->map);
 +
  	error = bus_dmamap_load(ring->data_dmat, data->map,
  	    mtod(mnew, caddr_t), MJUMPAGESIZE,
  	    wpi_dma_map_addr, &paddr, BUS_DMA_NOWAIT);
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 

From: Dominic Fandrey <kamikaze@bsdforen.de>
To: Bernhard Schmidt <bschmidt@freebsd.org>
Cc: bug-followup@freebsd.org
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Fri, 31 Dec 2010 11:20:10 +0100

 On 30/12/2010 19:18, Bernhard Schmidt wrote:
 > On Thursday 30 December 2010 16:30:12 Dominic Fandrey wrote:
 >> The following reply was made to PR kern/144898; it has been noted by GNATS.
 >>
 >> From: Dominic Fandrey <kamikaze@bsdforen.de>
 >> To: Bernhard Schmidt <bschmidt@freebsd.org>
 >> Cc: bug-followup@freebsd.org
 >> Subject: Re: kern/144898: [wpi] [panic] wpi panics system
 >> Date: Thu, 30 Dec 2010 16:28:15 +0100
 >>
 >>  On 30/12/2010 11:57, Bernhard Schmidt wrote:
 >>  > On Tuesday 28 December 2010 17:30:15 Dominic Fandrey wrote:
 >>  >>  Also I found a new problem, this is from my dmesg:
 >>  >>  wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
 >>  >>  ..
 >>  >>  wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
 >>  >>  
 >>  >>  The wpi_rx_intr messages appeared at breakneck speed until I turned
 >>  >>  the interface down. The mbuf error was thrown in occasionally. It
 >>  >>  did not appear to occur at a fixed frequency.
 >>  > 
 >>  > I've seen this one too.. though, no clue about the cause nor a way to
 >>  > reliably reproduce it. Do you have a scenario where this always
 >>  > happens?
 >>
 >>  No, sorry to say so, I don't.
 > 
 > I found a way to trigger this, after a clean boot, executing
 > i=0
 > while [ $i -lt 100 ]; do
 > 	kldload if_wpi
 > 	ifconfig wlan0 create wlandev wpi0
 > 	sleep 0.5
 > 	kldunload if_wpi
 > 	i=$(expr $i + 1)
 > done
 > 
 > kldload if_wpi
 > ifconfig wlan0 create wlandev wpi0
 > ifconfig wlan0 ssid iwn2 channel 7 10.1.1.157/16 up
 > 
 > and then doing lots of RX traffic triggered it 100% reliably.
 > Patch coming ASAP.
 
 That it makes my X applications die, makes me worry more than this
 problem, though.
 
 Any way, I will test your patch ASAP.
 
 Regards

From: Dominic Fandrey <kamikaze@bsdforen.de>
To: Bernhard Schmidt <bschmidt@freebsd.org>
Cc: Sulev-Madis Silber <madis555@hot.ee>, bug-followup@freebsd.org
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Sun, 02 Jan 2011 00:18:04 +0100

 On 27/12/2010 11:34, Bernhard Schmidt wrote:
 
 > As you might have noticed, I committed a bunch of fixed to wpi(4) which are 
 > now included in 8.2-RC1. Could you please test that in regard to this PR and 
 > let me know about the outcome?
 
 I now tested WPA2 and it works, too. The system is stable in the
 sense that it does not panic and there is no package loss if I ping
 something.
 
 However X applications still freeze and die, as soon as the wlan0
 interface is up. Even if the interface is not associated and no
 routes go through it.
 
 Regards
 
 -- 
 A: Because it fouls the order in which people normally read text.
 Q: Why is top-posting such a bad thing?
 A: Top-posting.
 Q: What is the most annoying thing on usenet and in e-mail? 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/144898: commit references a PR
Date: Sun,  2 Jan 2011 09:04:01 +0000 (UTC)

 Author: bschmidt
 Date: Sun Jan  2 09:03:53 2011
 New Revision: 216885
 URL: http://svn.freebsd.org/changeset/base/216885
 
 Log:
   MFC r216824:
   The RX path is missing a few bus_dmamap_*() calls, this results in
   modification of memory which was already free'd and eventually in:
   wpi0: could not map mbuf (error 12)
   wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
   and an usuable device.
   
   PR:		kern/144898
 
 Modified:
   stable/8/sys/dev/wpi/if_wpi.c
 Directory Properties:
   stable/8/sys/   (props changed)
   stable/8/sys/amd64/include/xen/   (props changed)
   stable/8/sys/cddl/contrib/opensolaris/   (props changed)
   stable/8/sys/contrib/dev/acpica/   (props changed)
   stable/8/sys/contrib/pf/   (props changed)
 
 Modified: stable/8/sys/dev/wpi/if_wpi.c
 ==============================================================================
 --- stable/8/sys/dev/wpi/if_wpi.c	Sun Jan  2 03:16:47 2011	(r216884)
 +++ stable/8/sys/dev/wpi/if_wpi.c	Sun Jan  2 09:03:53 2011	(r216885)
 @@ -1052,9 +1052,18 @@ wpi_free_rx_ring(struct wpi_softc *sc, s
  
  	wpi_dma_contig_free(&ring->desc_dma);
  
 -	for (i = 0; i < WPI_RX_RING_COUNT; i++)
 -		if (ring->data[i].m != NULL)
 -			m_freem(ring->data[i].m);
 +	for (i = 0; i < WPI_RX_RING_COUNT; i++) {
 +		struct wpi_rx_data *data = &ring->data[i];
 +
 +		if (data->m != NULL) {
 +			bus_dmamap_sync(ring->data_dmat, data->map,
 +			    BUS_DMASYNC_POSTREAD);
 +			bus_dmamap_unload(ring->data_dmat, data->map);
 +			m_freem(data->m);
 +		}
 +		if (data->map != NULL)
 +			bus_dmamap_destroy(ring->data_dmat, data->map);
 +	}
  }
  
  static int
 @@ -1461,6 +1470,7 @@ wpi_rx_intr(struct wpi_softc *sc, struct
  		return;
  	}
  
 +	bus_dmamap_sync(ring->data_dmat, data->map, BUS_DMASYNC_POSTREAD);
  	head = (struct wpi_rx_head *)((caddr_t)(stat + 1) + stat->len);
  	tail = (struct wpi_rx_tail *)((caddr_t)(head + 1) + le16toh(head->len));
  
 @@ -1491,6 +1501,8 @@ wpi_rx_intr(struct wpi_softc *sc, struct
  		ifp->if_ierrors++;
  		return;
  	}
 +	bus_dmamap_unload(ring->data_dmat, data->map);
 +
  	error = bus_dmamap_load(ring->data_dmat, data->map,
  	    mtod(mnew, caddr_t), MJUMPAGESIZE,
  	    wpi_dma_map_addr, &paddr, BUS_DMA_NOWAIT);
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/144898: commit references a PR
Date: Sun,  2 Jan 2011 10:01:38 +0000 (UTC)

 Author: bschmidt
 Date: Sun Jan  2 10:01:29 2011
 New Revision: 216886
 URL: http://svn.freebsd.org/changeset/base/216886
 
 Log:
   MFC r216824:
   The RX path is missing a few bus_dmamap_*() calls, this results in
   modification of memory which was already free'd and eventually in:
   wpi0: could not map mbuf (error 12)
   wpi0: wpi_rx_intr: bus_dmamap_load failed, error 12
   and an usuable device.
   
   PR:		kern/144898
   Approved by:	re (kib)
 
 Modified:
   releng/8.2/sys/dev/wpi/if_wpi.c
 Directory Properties:
   releng/8.2/sys/   (props changed)
   releng/8.2/sys/amd64/include/xen/   (props changed)
   releng/8.2/sys/cddl/contrib/opensolaris/   (props changed)
   releng/8.2/sys/contrib/dev/acpica/   (props changed)
   releng/8.2/sys/contrib/pf/   (props changed)
 
 Modified: releng/8.2/sys/dev/wpi/if_wpi.c
 ==============================================================================
 --- releng/8.2/sys/dev/wpi/if_wpi.c	Sun Jan  2 09:03:53 2011	(r216885)
 +++ releng/8.2/sys/dev/wpi/if_wpi.c	Sun Jan  2 10:01:29 2011	(r216886)
 @@ -1052,9 +1052,18 @@ wpi_free_rx_ring(struct wpi_softc *sc, s
  
  	wpi_dma_contig_free(&ring->desc_dma);
  
 -	for (i = 0; i < WPI_RX_RING_COUNT; i++)
 -		if (ring->data[i].m != NULL)
 -			m_freem(ring->data[i].m);
 +	for (i = 0; i < WPI_RX_RING_COUNT; i++) {
 +		struct wpi_rx_data *data = &ring->data[i];
 +
 +		if (data->m != NULL) {
 +			bus_dmamap_sync(ring->data_dmat, data->map,
 +			    BUS_DMASYNC_POSTREAD);
 +			bus_dmamap_unload(ring->data_dmat, data->map);
 +			m_freem(data->m);
 +		}
 +		if (data->map != NULL)
 +			bus_dmamap_destroy(ring->data_dmat, data->map);
 +	}
  }
  
  static int
 @@ -1461,6 +1470,7 @@ wpi_rx_intr(struct wpi_softc *sc, struct
  		return;
  	}
  
 +	bus_dmamap_sync(ring->data_dmat, data->map, BUS_DMASYNC_POSTREAD);
  	head = (struct wpi_rx_head *)((caddr_t)(stat + 1) + stat->len);
  	tail = (struct wpi_rx_tail *)((caddr_t)(head + 1) + le16toh(head->len));
  
 @@ -1491,6 +1501,8 @@ wpi_rx_intr(struct wpi_softc *sc, struct
  		ifp->if_ierrors++;
  		return;
  	}
 +	bus_dmamap_unload(ring->data_dmat, data->map);
 +
  	error = bus_dmamap_load(ring->data_dmat, data->map,
  	    mtod(mnew, caddr_t), MJUMPAGESIZE,
  	    wpi_dma_map_addr, &paddr, BUS_DMA_NOWAIT);
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 

From: Bernhard Schmidt <bschmidt@freebsd.org>
To: Dominic Fandrey <kamikaze@bsdforen.de>
Cc: "Sulev-Madis Silber" <madis555@hot.ee>,
 bug-followup@freebsd.org
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Sun, 2 Jan 2011 11:36:00 +0100

 On Sunday 02 January 2011 00:18:04 Dominic Fandrey wrote:
 > On 27/12/2010 11:34, Bernhard Schmidt wrote:
 > > As you might have noticed, I committed a bunch of fixed to wpi(4)
 > > which are now included in 8.2-RC1. Could you please test that in
 > > regard to this PR and let me know about the outcome?
 > 
 > I now tested WPA2 and it works, too. The system is stable in the
 > sense that it does not panic and there is no package loss if I ping
 > something.
 
 Thanks
 
 > However X applications still freeze and die, as soon as the wlan0
 > interface is up. Even if the interface is not associated and no
 > routes go through it.
 
 Before or after applying the bus_dma(9) patch? I've seen those without 
 the patch but not with it. Is there anything useful in console? Error 
 message or something?
 
 -- 
 Bernhard

From: Dominic Fandrey <kamikaze@bsdforen.de>
To: Bernhard Schmidt <bschmidt@freebsd.org>
Cc: Sulev-Madis Silber <madis555@hot.ee>, bug-followup@freebsd.org
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Sun, 02 Jan 2011 18:59:51 +0100

 On 02/01/2011 11:36, Bernhard Schmidt wrote:
 > On Sunday 02 January 2011 00:18:04 Dominic Fandrey wrote:
 >> However X applications still freeze and die, as soon as the wlan0
 >> interface is up. Even if the interface is not associated and no
 >> routes go through it.
 > 
 > Before or after applying the bus_dma(9) patch? I've seen those without 
 > the patch but not with it. Is there anything useful in console? Error 
 > message or something?
 > 
 
 I just updated my sources and I'm connected for about 10 minutes
 without the problem occurring. This is a record so far, so I'm
 confident the problem is fixed.
 
 Thanks a lot! This is just great!
 
 Regards
 
 -- 
 A: Because it fouls the order in which people normally read text.
 Q: Why is top-posting such a bad thing?
 A: Top-posting.
 Q: What is the most annoying thing on usenet and in e-mail? 

From: Dominic Fandrey <kamikaze@bsdforen.de>
To: Bernhard Schmidt <bschmidt@freebsd.org>
Cc: Sulev-Madis Silber <madis555@hot.ee>, bug-followup@freebsd.org
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Sun, 02 Jan 2011 20:48:36 +0100

 On 02/01/2011 11:36, Bernhard Schmidt wrote:
 > On Sunday 02 January 2011 00:18:04 Dominic Fandrey wrote:
 >> However X applications still freeze and die, as soon as the wlan0
 >> interface is up. Even if the interface is not associated and no
 >> routes go through it.
 > 
 > Before or after applying the bus_dma(9) patch? I've seen those without 
 > the patch but not with it. Is there anything useful in console? Error 
 > message or something?
 > 
 
 A little update, I'm up for almost 2 hours without issues, now.
 
 I think it's pretty safe for me to say that this works. Very well,
 too!
 
 Thank you so very much!
 
 I sometimes get a "need multicast update callback", but I do not
 see any issues.
 
 Regards
 
 -- 
 A: Because it fouls the order in which people normally read text.
 Q: Why is top-posting such a bad thing?
 A: Top-posting.
 Q: What is the most annoying thing on usenet and in e-mail? 

From: Bernhard Schmidt <bschmidt@freebsd.org>
To: Dominic Fandrey <kamikaze@bsdforen.de>
Cc: "Sulev-Madis Silber" <madis555@hot.ee>,
 bug-followup@freebsd.org
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Mon, 3 Jan 2011 10:30:37 +0100

 On Sunday, January 02, 2011 20:48:36 Dominic Fandrey wrote:
 > On 02/01/2011 11:36, Bernhard Schmidt wrote:
 > > On Sunday 02 January 2011 00:18:04 Dominic Fandrey wrote:
 > >> However X applications still freeze and die, as soon as the wlan0
 > >> interface is up. Even if the interface is not associated and no
 > >> routes go through it.
 > > 
 > > Before or after applying the bus_dma(9) patch? I've seen those without
 > > the patch but not with it. Is there anything useful in console? Error
 > > message or something?
 > 
 > A little update, I'm up for almost 2 hours without issues, now.
 > 
 > I think it's pretty safe for me to say that this works. Very well,
 > too!
 
 Sounds good!
 
 > Thank you so very much!
 
 You're welcome :)
 
 > I sometimes get a "need multicast update callback", but I do not
 > see any issues.
 
 Those are harmless and just indicate that there is a function missing in 
 wpi(4), just ignore those for now.
 
 So, after going over all the mails for this PR again, there's only one issue 
 left. The one with the RFKILL button where the interface isn't coming up 
 automatically after triggering. This though, is a general issue within all 
 drivers currently (I might even have fix this with iwn(4) afair), not just 
 wpi(4). Honestly I'd ignore this for now and address this once I have enough 
 clue (it's on my TODO list) for all drivers.
 
 So, what do you think, is it time to close this PR?
 
 Thanks
 
 -- 
 Bernhard

From: Dominic Fandrey <kamikaze@bsdforen.de>
To: bschmidt@freebsd.org
Cc: Sulev-Madis Silber <madis555@hot.ee>, bug-followup@freebsd.org
Subject: Re: kern/144898: [wpi] [panic] wpi panics system
Date: Mon, 03 Jan 2011 12:00:00 +0100

 On 03/01/2011 10:30, Bernhard Schmidt wrote:
 > So, what do you think, is it time to close this PR?
 
 As far as I am concerned, go ahead. :)
State-Changed-From-To: feedback->closed 
State-Changed-By: bschmidt 
State-Changed-When: Wed Jan 5 08:09:07 UTC 2011 
State-Changed-Why:  
Based on the latest feedback I think is safe to close this PR. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=144898 
>Unformatted:
