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
Responsible Changed From-To: freebsd-bugs->freebsd-wireless Over to maintainer(s).
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
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"
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Seems to be fixed in base r254279 (as noted in comment #3).