From julio+host-mastodon-jmmv@meroh.net  Wed Aug  7 02:45:30 2013
Return-Path: <julio+host-mastodon-jmmv@meroh.net>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1])
	(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by hub.freebsd.org (Postfix) with ESMTP id 5B1D4C76
	for <FreeBSD-gnats-submit@freebsd.org>; Wed,  7 Aug 2013 02:45:30 +0000 (UTC)
	(envelope-from julio+host-mastodon-jmmv@meroh.net)
Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.122])
	by mx1.freebsd.org (Postfix) with ESMTP id 1B3EE204F
	for <FreeBSD-gnats-submit@freebsd.org>; Wed,  7 Aug 2013 02:45:29 +0000 (UTC)
Received: from [108.176.158.82] ([108.176.158.82:65531] helo=portal.meroh.net)
	by hrndva-oedge02.mail.rr.com (envelope-from <julio+host-mastodon-jmmv@meroh.net>)
	(ecelerity 2.2.3.46 r()) with ESMTP
	id 2C/93-18468-8C4B1025; Wed, 07 Aug 2013 02:45:28 +0000
Received: from mastodon.meroh.net (lime-wifi.meroh.net [192.168.1.27])
	by portal.meroh.net (Postfix) with ESMTP id DBFE7EFE67
	for <FreeBSD-gnats-submit@freebsd.org>; Tue,  6 Aug 2013 22:45:19 -0400 (EDT)
Received: from mastodon.meroh.net (localhost [127.0.0.1])
	by mastodon.meroh.net (8.14.7/8.14.7) with ESMTP id r772jPNo001342
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 6 Aug 2013 22:45:25 -0400 (EDT)
	(envelope-from jmmv@mastodon.meroh.net)
Received: (from jmmv@localhost)
	by mastodon.meroh.net (8.14.7/8.14.7/Submit) id r772jPNv001341;
	Tue, 6 Aug 2013 22:45:25 -0400 (EDT)
	(envelope-from jmmv)
Message-Id: <201308070245.r772jPNv001341@mastodon.meroh.net>
Date: Tue, 6 Aug 2013 22:45:25 -0400 (EDT)
From: Julio Merino <julio+host-mastodon-jmmv@meroh.net>
Reply-To: Julio Merino <julio+host-mastodon-jmmv@meroh.net>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: Turning up bwi0 crashes / deadlocks the kernel
X-Send-Pr-Version: 3.114
X-GNATS-Notify:

>Number:         181100
>Category:       kern
>Synopsis:       [bwi] Turning up bwi0 crashes / deadlocks the kernel
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-wireless
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Aug 07 02:50:00 UTC 2013
>Closed-Date:    
>Last-Modified:  Tue Aug 13 10:00:00 UTC 2013
>Originator:     Julio Merino
>Release:        FreeBSD 10.0-CURRENT powerpc
>Organization:
>Environment:
System: FreeBSD mastodon.meroh.net 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r253975M: Mon Aug 5 20:31:12 EDT 2013 jmmv@mastodon.meroh.net:/usr/obj/usr/src/sys/GENERIC64 powerpc

	Kernel does NOT have WITNESS enabled.

>Description:
	I don't know if this is a powerpc-related issue or if it is a
	generic issue with (possibly) interrupt handling.  I'm filing
	the report in the kern component for triage.

	I have a PowerMac G5 in which I'm trying to set up a wireless
	connection.  I have installed the bwi-firmware-kmod-3.130.20
	package and attempted the following commands:

	# kldload if_bwi
	# ifconfig wlan0 create wlandev bwi0
	# ifconfig bwi0 up scan

	as described in the handbook.  However, after the third command,
	the kernel crashes or sometimes apparently deadlocks.  The last
	time this happened resulted in the following messages spewed to
	the console (manually transcribed):

-----
bwi0: <Broadcom BCM4306 802.11b/g Wireless Lan> mem 0x80104000-0x80105fff irq 185 at device 1.0 on pci5
bwi0: BBP: id 0x4306, rev 0x2, pkg 0
bwi0: MA
bwi0: PHY: type 2, rev 1, ver 1
bwi0: RF: manu 0x17f, type 0x2050, rev 2
bwi0: invalid antenna gain in sprom
atapci1 <ServerWorks K2 SATA150 controller> at device 12.1 on pci8
pcib1: failed to reserve resource for pcib8
atapci1: 0x10 bytes of rid 0x20 res 4 failed (0, 0xffffffffffffffff).
atapci1: unable to map interrupt
device_attach: atapci1 attach returned 6
wlan0: Ethernet address: xx:xx:xx:xx:xx:xx
bwi0: firmware rev 0x0127, patch level 0x000e

fatal kernel trap:

   exception = 0x300 (data storage interrupt)
   virtual address = 0x6275735f676574
   dsisr = 0x46000000
   srr0 = 0x7c4ed8
   srr1 = 0x9000000000009032
   lr = 0xc00000000b554590
   curthread = 0x25b2b490
           pid = 12, comm = irq185: bwi0

[ thread pid 12 tid 100102 ]
Stopped at 0x7c4ed8: ld r30, r27, 0x0,
-----
	
	To me, this looks like an interrupt routing problem or some
	other kind of device conflict.  Note that the error messages
	seem to indicate that.  Also, I have no idea why atapci1 appears
	after bwi0 given that I did not perform any other activities in
	between the commands mentioned above that could cause a storage
	device from being attached.

	This is the output of atapci-related entries in sysctl, which
	shows nothing about atapci1:

-----
$ sysctl -a | grep atapci
mastodon:~> sysctl -a | grep atapci
dev.ata.2.%parent: atapci0
dev.ata.3.%parent: atapci0
dev.ata.4.%parent: atapci0
dev.ata.5.%parent: atapci0
dev.atapci.0.%desc: ServerWorks K2 SATA150 controller
dev.atapci.0.%driver: atapci
dev.atapci.0.%location: slot=12 function=0
dev.atapci.0.%pnpinfo: vendor=0x1166 device=0x0240 subvendor=0x1166
subdevice=0x0240 class=0x01018f name=k2-sata-root compat=k2-s-ata
dev.atapci.0.%parent: pci8
-----

	And, finally, atapci messages from dmesg after a reboot, without
	having loaded bwi0 at all:

-----
mastodon:~> dmesg | grep atapci
atapci0: <ServerWorks K2 SATA150 controller> mem 0x80600000-0x80601fff
irq 128 at device 12.0 on pci8
atapci0: 0x10 bytes of rid 0x20 res 4 failed (0, 0xffffffffffffffff).
ata2: <ATA channel> at channel 0 on atapci0
ata3: <ATA channel> at channel 1 on atapci0
ata4: <ATA channel> at channel 2 on atapci0
ata5: <ATA channel> at channel 3 on atapci0
atapci1: <ServerWorks K2 SATA150 controller> at device 12.1 on pci8
atapci1: 0x10 bytes of rid 0x20 res 4 failed (0, 0xffffffffffffffff).
atapci1: unable to map interrupt
device_attach: atapci1 attach returned 6
------

	I can provide more information if necessary.
>How-To-Repeat:
	On a PowerMac G5 (and possibly other machines):

	# kldload if_bwi
	# ifconfig wlan0 create wlandev bwi0
	# ifconfig bwi0 up scan
>Fix:

	


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Wed Aug 7 02:52:45 UTC 2013 
Responsible-Changed-Why:  
Over to maintainer(s). 

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

From: Julio Merino <julio@meroh.net>
To: bug-followup@freebsd.org, julio+host-mastodon-jmmv@meroh.net
Cc:  
Subject: Re: kern/181100: [bwi] Turning up bwi0 crashes / deadlocks the kernel
Date: Sun, 11 Aug 2013 12:40:56 -0400

 I rebuilt a kernel with WITNESS enabled and got the following
 stacktrace, which probably sheds some useful details.  Copying by hand
 so omitting addresses:
 
 Sleeping on "fwload" with the following non-sleepable locks held:
 exclusive sleep mutex bwi0 (network driver) r = 0 (0x...) locked @
 /usr/src/sys/modules/bwi/../../dev/bwi/if_bwi.c:1313
 KDB: stack backtrace:
 0x...: at .kdb_backgrace
 0x...: at ._witness_debugger
 0x...: at .witness_warn
 0x...: at ._sleep
 0x...: at .firmware_get
 0x...: at .bwi_mac_init
 0x...: at .bwi_init_statechg
 0x...: at .bwi_ioctl
 0x...: at .parent_updown
 0x...: at .taskqueue_run_locked
 0x...: at .taskqueue_thread_loop
 0x...: at .fork_exit
 0x...: at .fork_tramploline
 0x...: at fffffffffffffffc
 bwi0: firmware rev 0x0127, patch level 0x000e
 panic: rate 130 is basic/mcs?
 cpuid = 0
 KDB: stack backtrace:
 0x...: at .kdb_backtrace
 0x...: at .vpanic
 0x...: at .kassert_panic
 0x...: at .bwi_mac_set_ackrates
 0x...: at .bwi_mac_init
 0x...: at .bwi_init_statechg
 0x...: at .bwi_ioctl
 0x...: at .parent_updown
 0x...: at .taskqueue_run_locked
 0x...: at .taskqueue_thread_loop
 0x...: at .fork_exit
 0x...: at .fork_trampoline
 0x...: at fffffffffffffffc
 KDB: enter: panic
 [ thread pid 0 tid 100100 ]
 Stopped at 0x...
 
 -- 
 Julio Merino / @jmmv

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/181100: commit references a PR
Date: Tue, 13 Aug 2013 09:58:35 +0000 (UTC)

 Author: adrian
 Date: Tue Aug 13 09:58:27 2013
 New Revision: 254279
 URL: http://svnweb.freebsd.org/changeset/base/254279
 
 Log:
   ieee80211_rate2plcp() and ieee80211_rate2phytype() are both pre-11n
   routines and thus assert if one passes in a rate code with the
   high bit set.
   
   Since the high bit can indicate either IEEE80211_RATE_BASIC or
   IEEE80211_RATE_MCS, it's up to the caller to determine whether
   the rate is 11n or not, and either mask out the BASIC bit, or
   call a different function.
   
   (Yes, this does mean that net80211 should grow 11n-aware rate2phytype()
   and rate2plcp() functions..)
   
   This may need to happen for the other drivers - it's currently only
   done (now) for iwn(4) and bwi(4).
   
   PR:		kern/181100
 
 Modified:
   head/sys/dev/bwi/bwimac.c
 
 Modified: head/sys/dev/bwi/bwimac.c
 ==============================================================================
 --- head/sys/dev/bwi/bwimac.c	Tue Aug 13 09:06:18 2013	(r254278)
 +++ head/sys/dev/bwi/bwimac.c	Tue Aug 13 09:58:27 2013	(r254279)
 @@ -1427,7 +1427,8 @@ bwi_mac_set_ackrates(struct bwi_mac *mac
  		enum ieee80211_phytype modtype;
  		uint16_t ofs;
  
 -		modtype = ieee80211_rate2phytype(rt, rs->rs_rates[i]);
 +		modtype = ieee80211_rate2phytype(rt,
 +		    rs->rs_rates[i] & IEEE80211_RATE_VAL);
  		switch (modtype) {
  		case IEEE80211_T_DS:
  			ofs = 0x4c0;
 @@ -1438,7 +1439,9 @@ bwi_mac_set_ackrates(struct bwi_mac *mac
  		default:
  			panic("unsupported modtype %u\n", modtype);
  		}
 -		ofs += 2*(ieee80211_rate2plcp(rs->rs_rates[i], modtype) & 0xf);
 +		ofs += 2*(ieee80211_rate2plcp(
 +		    rs->rs_rates[i] & IEEE80211_RATE_VAL,
 +		    modtype) & 0xf);
  
  		MOBJ_WRITE_2(mac, BWI_COMM_MOBJ, ofs + 0x20,
  			     MOBJ_READ_2(mac, BWI_COMM_MOBJ, ofs));
 _______________________________________________
 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"
 
>Unformatted:
