Re: bin/177871: [patch] etherswitchcfg(8): uninitialized variable while setting port vlangroup
Synopsis: [patch] etherswitchcfg(8): uninitialized variable while setting port vlangroup Responsible-Changed-From-To: freebsd-bugs->freebsd-embedded Responsible-Changed-By: adrian Responsible-Changed-When: Fri Apr 19 17:51:46 UTC 2013 Responsible-Changed-Why: Snarf. http://www.freebsd.org/cgi/query-pr.cgi?pr=177871 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/177872: [patch] etherswitchcfg(8) crashes if called with no argument for vlangroups members
Synopsis: [patch] etherswitchcfg(8) crashes if called with no argument for vlangroups members Responsible-Changed-From-To: freebsd-bugs->freebsd-embedded Responsible-Changed-By: adrian Responsible-Changed-When: Fri Apr 19 17:51:59 UTC 2013 Responsible-Changed-Why: snarf. http://www.freebsd.org/cgi/query-pr.cgi?pr=177872 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/177873: [patch] etherswitchcfg(): Change the per port vlangroup option to pvid
Synopsis: [patch] etherswitchcfg(): Change the per port vlangroup option to pvid Responsible-Changed-From-To: freebsd-bugs->freebsd-embedded Responsible-Changed-By: adrian Responsible-Changed-When: Fri Apr 19 17:52:10 UTC 2013 Responsible-Changed-Why: snarf. http://www.freebsd.org/cgi/query-pr.cgi?pr=177873 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/177832: [mips] [gpio] [patch] GPIO and RF LED do not function on UBNT Routerstation
Synopsis: [mips] [gpio] [patch] GPIO and RF LED do not function on UBNT Routerstation Responsible-Changed-From-To: freebsd-bugs->freebsd-mips Responsible-Changed-By: adrian Responsible-Changed-When: Fri May 10 00:47:06 UTC 2013 Responsible-Changed-Why: Change to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=177832 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/178318: [patch] [arge] if_arge/bootp race under some circunstances
Synopsis: [patch] [arge] if_arge/bootp race under some circunstances Responsible-Changed-From-To: freebsd-bugs->freebsd-mips Responsible-Changed-By: adrian Responsible-Changed-When: Thu May 16 03:23:13 UTC 2013 Responsible-Changed-Why: assign to owner http://www.freebsd.org/cgi/query-pr.cgi?pr=178318 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/178319: [patch] [arge] arge_stop() doesn't clean the tx ring properly
Synopsis: [patch] [arge] arge_stop() doesn't clean the tx ring properly Responsible-Changed-From-To: freebsd-bugs->freebsd-mips Responsible-Changed-By: adrian Responsible-Changed-When: Thu May 16 03:23:25 UTC 2013 Responsible-Changed-Why: assign to owner. http://www.freebsd.org/cgi/query-pr.cgi?pr=178319 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/179269: [ath] [AR9285] RX antenna diversity is not functioning correctly; breaks single-antenna designs
Synopsis: [ath] [AR9285] RX antenna diversity is not functioning correctly; breaks single-antenna designs Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Mon Jun 3 19:11:23 UTC 2013 Responsible-Changed-Why: Punt to maintainer http://www.freebsd.org/cgi/query-pr.cgi?pr=179269 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/179113: [ata] ATA DMA does not fall back on systems that misreport capability
Synopsis: [ata] ATA DMA does not fall back on systems that misreport capability Responsible-Changed-From-To: freebsd-bugs->mav Responsible-Changed-By: adrian Responsible-Changed-When: Wed Jun 5 17:59:58 UTC 2013 Responsible-Changed-Why: Punt this to mav@, as it's a CAM / ATA layer issue. http://www.freebsd.org/cgi/query-pr.cgi?pr=179113 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/179117: [ata] ata device fails without option ATA_CAM
Synopsis: [ata] ata device fails without option ATA_CAM Responsible-Changed-From-To: freebsd-bugs->mav Responsible-Changed-By: adrian Responsible-Changed-When: Wed Jun 5 18:01:42 UTC 2013 Responsible-Changed-Why: Another ATA / CAM bug. Thanks! http://www.freebsd.org/cgi/query-pr.cgi?pr=179117 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/181132: [iwn] stream calculation is wrong for the Intel 4965
Synopsis: [iwn] stream calculation is wrong for the Intel 4965 Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Thu Aug 8 05:51:05 UTC 2013 Responsible-Changed-Why: Changing to owner http://www.freebsd.org/cgi/query-pr.cgi?pr=181132 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/182828: [patch] [igb] Revision 247430 broke outgoing interface stats for stable/8
Synopsis: [patch] [igb] Revision 247430 broke outgoing interface stats for stable/8 State-Changed-From-To: closed->open State-Changed-By: adrian State-Changed-When: Mon Oct 21 06:10:48 UTC 2013 State-Changed-Why: Re-open; the issue was due to jfv's merge. Responsible-Changed-From-To: freebsd-bugs->jfv Responsible-Changed-By: adrian Responsible-Changed-When: Mon Oct 21 06:10:48 UTC 2013 Responsible-Changed-Why: Re-open; the issue was due to jfv's merge. http://www.freebsd.org/cgi/query-pr.cgi?pr=182828 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: misc/160176: Kernel panic on AR7161 platform with AR9220 (BGN) WIFI card while AH_DEBUG used.
Synopsis: Kernel panic on AR7161 platform with AR9220 (BGN) WIFI card while AH_DEBUG used. Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Mon Aug 29 16:53:20 UTC 2011 Responsible-Changed-Why: Bump http://www.freebsd.org/cgi/query-pr.cgi?pr=160176 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: bin/154954: [patch] csup(1) in the CVS mode terminates before it applies all required fixups
Synopsis: [patch] csup(1) in the CVS mode terminates before it applies all required fixups Responsible-Changed-From-To: freebsd-bugs->adrian Responsible-Changed-By: adrian Responsible-Changed-When: Sun Sep 18 09:51:02 UTC 2011 Responsible-Changed-Why: I'll take it http://www.freebsd.org/cgi/query-pr.cgi?pr=154954 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/98162: [request] AcerHK driver port needed for enabling WiFi on Acer's laptops
Synopsis: [request] AcerHK driver port needed for enabling WiFi on Acer's laptops Responsible-Changed-From-To: freebsd-bugs->adrian Responsible-Changed-By: adrian Responsible-Changed-When: Sun Oct 23 15:51:39 UTC 2011 Responsible-Changed-Why: I'll take a crack at this; I have some relevant hardware. http://www.freebsd.org/cgi/query-pr.cgi?pr=98162 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/162647: [ath] 11n TX aggregation session / TX hang
Synopsis: [ath] 11n TX aggregation session / TX hang Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Fri Nov 18 03:56:39 UTC 2011 Responsible-Changed-Why: Punt http://www.freebsd.org/cgi/query-pr.cgi?pr=162647 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/163573: [ath] hostap mode TX buffer hang
Synopsis: [ath] hostap mode TX buffer hang Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Fri Dec 23 19:22:34 UTC 2011 Responsible-Changed-Why: Over to -wireless. http://www.freebsd.org/cgi/query-pr.cgi?pr=163573 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/165060: [ath] vap->iv_bss race conditions causing crashes inside ath_beacon_alloc and similar
Synopsis: [ath] vap->iv_bss race conditions causing crashes inside ath_beacon_alloc and similar Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Mon Feb 13 00:14:06 UTC 2012 Responsible-Changed-Why: Assign http://www.freebsd.org/cgi/query-pr.cgi?pr=165060 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/165146: [net80211] Net802.11 Fragment number is assigned 1 (should be 0) when fragmenting a frame
Old Synopsis: Net802.11 Fragment number is assigned 1 (should be 0) when fragmenting a frame New Synopsis: [net80211] Net802.11 Fragment number is assigned 1 (should be 0) when fragmenting a frame Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Wed Feb 15 06:13:12 UTC 2012 Responsible-Changed-Why: Punt http://www.freebsd.org/cgi/query-pr.cgi?pr=165146 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/165149: [ath] [net80211] Ping with data length more than iv_fragthreshold
Old Synopsis: [ath][net80211] Ping with data length more than iv_fragthreshold New Synopsis: [ath] [net80211] Ping with data length more than iv_fragthreshold Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Wed Feb 15 06:13:29 UTC 2012 Responsible-Changed-Why: Punt http://www.freebsd.org/cgi/query-pr.cgi?pr=165149 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/165220: [ath] "ath_rx_tasklet: sc_inreset_cnt > 0; skipping" messages
Synopsis: [ath] "ath_rx_tasklet: sc_inreset_cnt > 0; skipping" messages Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Fri Feb 17 07:23:32 UTC 2012 Responsible-Changed-Why: Change http://www.freebsd.org/cgi/query-pr.cgi?pr=165220 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/165306: [ath] race conditions between scanning and beacon timeout programming
Synopsis: [ath] race conditions between scanning and beacon timeout programming Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Mon Feb 20 02:42:58 UTC 2012 Responsible-Changed-Why: Reassign http://www.freebsd.org/cgi/query-pr.cgi?pr=165306 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/165212: [ath] No WiFi on Acer Aspire One 751h (Atheros AR5BHB63 & AR5B95)
Old Synopsis: No WiFi on Acer Aspire One 751h (Atheros AR5BHB63 & AR5B95) New Synopsis: [ath] No WiFi on Acer Aspire One 751h (Atheros AR5BHB63 & AR5B95) Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Mon Feb 20 13:19:43 UTC 2012 Responsible-Changed-Why: Reassign http://www.freebsd.org/cgi/query-pr.cgi?pr=165212 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/165382: [kernel] taskqueue_unblock doesn't unblock currently queued tasks
Synopsis: [kernel] taskqueue_unblock doesn't unblock currently queued tasks Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Sat Feb 25 19:02:48 UTC 2012 Responsible-Changed-Why: Flipping to -wireless for now.. http://www.freebsd.org/cgi/query-pr.cgi?pr=165382 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/165475: [ath] operational mode change doesn't poke the underlying rate control module hard enough
Synopsis: [ath] operational mode change doesn't poke the underlying rate control module hard enough Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Sat Feb 25 19:53:43 UTC 2012 Responsible-Changed-Why: Reassign http://www.freebsd.org/cgi/query-pr.cgi?pr=165475 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/165517: [net80211] bgscan isn't triggered when invalid beacons are being sent
Synopsis: [net80211] bgscan isn't triggered when invalid beacons are being sent Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Tue Feb 28 02:42:25 UTC 2012 Responsible-Changed-Why: Reassign http://www.freebsd.org/cgi/query-pr.cgi?pr=165517 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/165866: [ath] TX hangs, requiring a "scan" to properly reset the interface
Synopsis: [ath] TX hangs, requiring a "scan" to properly reset the interface Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Thu Mar 8 23:50:34 UTC 2012 Responsible-Changed-Why: Change to owner http://www.freebsd.org/cgi/query-pr.cgi?pr=165866 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/163237: [ath] AR5416 as HostAP. Delays among clients when a client is in Power saving mode
Old Synopsis: AR5416 as HostAP. Delays among clients when New Synopsis: [ath] AR5416 as HostAP. Delays among clients when a client is in Power saving mode Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Sun Mar 11 15:55:21 UTC 2012 Responsible-Changed-Why: Reassign/update. http://www.freebsd.org/cgi/query-pr.cgi?pr=163237 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/165951: [ar913x] [ath] DDR flush isn't being done for the WMAC
Old Synopsis: [ath] [ar913x] DDR flush isn't being done for the WMAC New Synopsis: [ar913x] [ath] DDR flush isn't being done for the WMAC Responsible-Changed-From-To: freebsd-bugs->freebsd-mips Responsible-Changed-By: adrian Responsible-Changed-When: Mon Mar 12 00:39:21 UTC 2012 Responsible-Changed-Why: This is (mostly) an ar71xx MIPS platform issue. http://www.freebsd.org/cgi/query-pr.cgi?pr=165951 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/165966: [ath] ath0: device timeout on SMP machines due to race conditions
Synopsis: [ath] ath0: device timeout on SMP machines due to race conditions Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Mon Mar 12 07:42:32 UTC 2012 Responsible-Changed-Why: Reassign http://www.freebsd.org/cgi/query-pr.cgi?pr=165966 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/166286: [net80211] [ath] initial switch to HT40 isn't causing a hardware channel change call
Synopsis: [net80211] [ath] initial switch to HT40 isn't causing a hardware channel change call Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Wed Mar 21 00:13:04 UTC 2012 Responsible-Changed-Why: assign to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=166286 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: misc/166357: [ath] 802.11n TX stall when the first _AND_ last frame in the BAW is in the software queue
Synopsis: [ath] 802.11n TX stall when the first _AND_ last frame in the BAW is in the software queue Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Fri Mar 23 21:14:27 UTC 2012 Responsible-Changed-Why: reassign to -wireless. http://www.freebsd.org/cgi/query-pr.cgi?pr=166357 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/166684: [ath] [net80211] mgmtrate/mcastrate isn't updated based on the the BSS rate list
Synopsis: [ath] [net80211] mgmtrate/mcastrate isn't updated based on the the BSS rate list Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Thu Apr 5 22:55:43 UTC 2012 Responsible-Changed-Why: punt to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=166684 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/152750: ath0 lot of bad series hwrate
Synopsis: ath0 lot of bad series hwrate Responsible-Changed-From-To: freebsd-bugs->adrian Responsible-Changed-By: adrian Responsible-Changed-When: Wed Dec 1 23:48:37 UTC 2010 Responsible-Changed-Why: I'll snaffle if_ath stuff http://www.freebsd.org/cgi/query-pr.cgi?pr=152750 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/154153: AR5213 + MIPS + WPA group key packet corruption
Synopsis: AR5213 + MIPS + WPA group key packet corruption Responsible-Changed-From-To: freebsd-bugs->adrian Responsible-Changed-By: adrian Responsible-Changed-When: Thu Jan 20 02:22:04 UTC 2011 Responsible-Changed-Why: I'm going to take over the ath stuff. http://www.freebsd.org/cgi/query-pr.cgi?pr=154153 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/154220: [ath] AR9280 based Ubiquiti SR71-12/15 panics on interface up (on mips)
Synopsis: [ath] AR9280 based Ubiquiti SR71-12/15 panics on interface up (on mips) Responsible-Changed-From-To: freebsd-bugs->adrian Responsible-Changed-By: adrian Responsible-Changed-When: Thu Jan 27 06:46:29 UTC 2011 Responsible-Changed-Why: My bug http://www.freebsd.org/cgi/query-pr.cgi?pr=154220 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/154327: [ath] AR5416 in station mode hangs when transmitting frames
Synopsis: [ath] AR5416 in station mode hangs when transmitting frames Responsible-Changed-From-To: freebsd-bugs->adrian Responsible-Changed-By: adrian Responsible-Changed-When: Thu Jan 27 06:51:22 UTC 2011 Responsible-Changed-Why: my bug http://www.freebsd.org/cgi/query-pr.cgi?pr=154327 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/156765: [ath] Merlin fast-clock check isn't correct
Synopsis: [ath] Merlin fast-clock check isn't correct Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Tue May 3 04:03:10 UTC 2011 Responsible-Changed-Why: Punt to wireless list http://www.freebsd.org/cgi/query-pr.cgi?pr=156765 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/156904: [ath] AR9285 antenna diversity algorithm is buggy and chooses a sub-optimal antenna
Synopsis: [ath] AR9285 antenna diversity algorithm is buggy and chooses a sub-optimal antenna Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Wed May 11 03:40:03 UTC 2011 Responsible-Changed-Why: Bump http://www.freebsd.org/cgi/query-pr.cgi?pr=156904 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/148307: Incorrect alignment checks in sys/mips/atheros/if_arge.c
Synopsis: Incorrect alignment checks in sys/mips/atheros/if_arge.c Responsible-Changed-From-To: freebsd-bugs->adrian Responsible-Changed-By: adrian Responsible-Changed-When: Fri Jul 2 09:41:18 UTC 2010 Responsible-Changed-Why: I've got the fix, I'll talk with gonzo@ and commit an official fix soon. http://www.freebsd.org/cgi/query-pr.cgi?pr=148307 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Undefined symbol "__stdin@FBSD_1_0"
Hi all, fresh new install of fbsd 12.1 on a new system yesterday - all good and working updated afterwards to 12.1-RELEASE-p4 and i can't boot anymore : ld-elf.so.1: /lib/libedit.so.7 : Undefined symbol "__isthreaded@FBSD_1_0" Enter full pathname of shell or RETURN for /bin/sh reinstalled OS again today: after freebsd-update to 12.1-RELEASE-p5 ld-elf.so.1: /lib/libedit.so.7 : Undefined symbol "__stdin@FBSD_1_0" Enter full pathname of shell or RETURN for /bin/sh any clues ? thanks Adrian ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/187624: WEP and other ciphers do not work if h/w driver does not declare support
Synopsis: WEP and other ciphers do not work if h/w driver does not declare support Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Thu Mar 20 19:41:22 UTC 2014 Responsible-Changed-Why: bounce to owne.r http://www.freebsd.org/cgi/query-pr.cgi?pr=187624 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/169084: [ath] suspend/resume doesn't cause a rescan; the association stays even if the AP is not available
Synopsis: [ath] suspend/resume doesn't cause a rescan; the association stays even if the AP is not available Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Thu Jun 14 22:44:35 UTC 2012 Responsible-Changed-Why: Reassign to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=169084 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/169432: [ath] BAR TX hang when aggregation session is reset during a reassociation
Synopsis: [ath] BAR TX hang when aggregation session is reset during a reassociation Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Tue Jun 26 07:30:54 UTC 2012 Responsible-Changed-Why: Refile http://www.freebsd.org/cgi/query-pr.cgi?pr=169432 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/170098: [ath] [net80211] VAPs (Virtual access points) with Atheros ath driver
Old Synopsis: virtual access points with Atheros ath driver New Synopsis: [ath] [net80211] VAPs (Virtual access points) with Atheros ath driver Class-Changed-From-To: doc-bug->sw-bug Class-Changed-By: adrian Class-Changed-When: Mon Jul 23 22:59:09 UTC 2012 Class-Changed-Why: This is partially a docs and partially a kern problem. Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Mon Jul 23 22:59:09 UTC 2012 Responsible-Changed-Why: This is partially a docs and partially a kern problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=170098 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/170302: [ath] 802.11n frames are not being transmitted with multiple rates
Synopsis: [ath] 802.11n frames are not being transmitted with multiple rates Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Tue Jul 31 23:51:48 UTC 2012 Responsible-Changed-Why: Punt to maintainer http://www.freebsd.org/cgi/query-pr.cgi?pr=170302 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/170433: [ath] TX hang after a stuck beacon message with active traffic
Synopsis: [ath] TX hang after a stuck beacon message with active traffic Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Tue Aug 7 00:40:38 UTC 2012 Responsible-Changed-Why: Flip http://www.freebsd.org/cgi/query-pr.cgi?pr=170433 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/170513: [ath] ath logs: ath_tx_aggr_comp_aggr: AR5416 bug:
Old Synopsis: ath logs: ath_tx_aggr_comp_aggr: AR5416 bug: New Synopsis: [ath] ath logs: ath_tx_aggr_comp_aggr: AR5416 bug: Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Thu Aug 9 22:02:45 UTC 2012 Responsible-Changed-Why: Punt. http://www.freebsd.org/cgi/query-pr.cgi?pr=170513 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/170620: [ath] LOR and deadlock when multiple vaps are used
Old Synopsis: LOR and deadlock when multiple vaps are used New Synopsis: [ath] LOR and deadlock when multiple vaps are used Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Tue Aug 14 03:48:32 UTC 2012 Responsible-Changed-Why: Over to maintainer http://www.freebsd.org/cgi/query-pr.cgi?pr=170620 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/171394: [ath] ath0: ath_tx_aggr_comp_aggr: num frames seen=1; bf nframes=4
Synopsis: [ath] ath0: ath_tx_aggr_comp_aggr: num frames seen=1; bf nframes=4 Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Fri Sep 7 00:23:40 UTC 2012 Responsible-Changed-Why: Reassign http://www.freebsd.org/cgi/query-pr.cgi?pr=171394 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/172968: [arswitch] probe/attach occasionally fails to find a PHY
Synopsis: [arswitch] probe/attach occasionally fails to find a PHY Responsible-Changed-From-To: freebsd-bugs->freebsd-embedded Responsible-Changed-By: adrian Responsible-Changed-When: Mon Oct 22 22:31:05 UTC 2012 Responsible-Changed-Why: Flip http://www.freebsd.org/cgi/query-pr.cgi?pr=172968 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/174273: [net80211] taking down a net80211 node with active fast frames traffic causes a panic
Synopsis: [net80211] taking down a net80211 node with active fast frames traffic causes a panic Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Sat Dec 8 09:47:28 UTC 2012 Responsible-Changed-Why: Shuffle! http://www.freebsd.org/cgi/query-pr.cgi?pr=174273 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: misc/174283: [net80211] panics in ieee80211_ff_age() and ieee80211_ff_flush()
Synopsis: [net80211] panics in ieee80211_ff_age() and ieee80211_ff_flush() Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Sun Dec 9 00:50:24 UTC 2012 Responsible-Changed-Why: punt to maintainer list http://www.freebsd.org/cgi/query-pr.cgi?pr=174283 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/175260: [asmc] [patch] add support for Macbook 3.1
Synopsis: [asmc] [patch] add support for Macbook 3.1 Responsible-Changed-From-To: freebsd-bugs->adrian Responsible-Changed-By: adrian Responsible-Changed-When: Tue Jan 15 17:42:06 UTC 2013 Responsible-Changed-Why: I'll snaffle this. http://www.freebsd.org/cgi/query-pr.cgi?pr=175260 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/175446: [ath] high volumes of PHY errors lead to BB/MAC hangs and resets
Synopsis: [ath] high volumes of PHY errors lead to BB/MAC hangs and resets Responsible-Changed-From-To: freebsd-bugs->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Sun Jan 20 07:14:15 UTC 2013 Responsible-Changed-Why: reassign http://www.freebsd.org/cgi/query-pr.cgi?pr=175446 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/177032: [arge] arge1 fails to attach on UBNT Routerstation
please reassign this to -mips, thanks! adrian On 26 March 2013 18:52, wrote: > Old Synopsis: arge1 fails to attach on UBNT Routerstation > New Synopsis: [arge] arge1 fails to attach on UBNT Routerstation > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > Responsible-Changed-By: linimon > Responsible-Changed-When: Wed Mar 27 01:51:56 UTC 2013 > Responsible-Changed-Why: > Over to -net, although it should possibly be on -mips. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=177032 > ___ > freebsd-...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/177846: [ath] [net80211] net80211 TX power limit isn't correctly implemented for the BSS node and when the TX power limit is changed
>Number: 177846 >Category: misc >Synopsis: [ath] [net80211] net80211 TX power limit isn't correctly >implemented for the BSS node and when the TX power limit is changed >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Apr 14 04:40:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: adrian chadd >Release:-HEAD >Organization: >Environment: >Description: There's a few bugs relating to TPC (transmit power control); this is but one. When a VAP is created and the BSS node gets created, the BSS node inherits the ic maximum tx power limit: ieee80211_alloc_node(): .. ni->ni_txpower = ic->ic_txpowlimit; /* max power */ .. However, ic_txpowlimit by default is set to: ieee80211_var.h:#define IEEE80211_TXPOWER_MAX 100 /* .5 dbM (XXX units?) */ . which is 50dBm. Way, way too high by default. But that's fine, shouldn't setting the regulatory and channel TX power limit change the ic_txpowlimit value? Nope. Ok, so what's this actually mean? It means that when the BSS node is created, it inherits the TX power from the IC, but the IC value is quite high. So the driver has to clamp it. but ath(4) doesn't at all clamp it (besides clamping it at 0x3f, the maximum TX power that can fit in the TX power descriptor / register fields.) Now, if you then change the TX power via 'ifconfig wlanX txpower Y', it does change the ic_txpowlimit value, but it doesn't affect the BSS node tx power. Nor, i suspect, the TX power limit of any previously created nodes. So what likely should occur here? * does net80211 get taught how to update the TX power limit for each node when one does a TX power reconfigure? * does each driver for now just use the MIN() of the ic_txpowlimit _and_ the ni->ni_txpower value? The latter is probably better. It won't be atomic, but it'll at least work. >How-To-Repeat: * Create an ath(4) based hostap VAP, on something that we vaguely support TPC on (say, AR5212/AR5413 series NICs); * enable TPC (sysctl dev.ath.X.tpc=1); * bring it up; * change the txpower; * look at how the output power level doesn't change. >Fix: It's likely that I'll just have to teach ath(4) to look at the ic_txpowlimit value when calculating the maximum tx power to send to a node. There are other issues here; like how the TX descriptor code isn't storing maximum TX power limit values in the HAL, so the HAL TX code can't actually clamp the required TX power to the maximum allowed at the given rate. Thus higher rates will distort. But that'll be in another bug. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/177847: [ath] With TPC enabled, TX power values aren't clamped to the hardware maximum
>Number: 177847 >Category: misc >Synopsis: [ath] With TPC enabled, TX power values aren't clamped to the >hardware maximum >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Apr 14 05:00:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: adrian chadd >Release: >Organization: >Environment: -HEAD >Description: When TPC is enabled, the PHY doesn't necessarily clamp the TX power limit at the value programmed into the per-rate TX power registers. For 11n chips, the HT20 and HT40 rates have a different adjustment to the programmed TX power values. Thus when doing TPC, the TX descriptor TX power register needs to be adjusted by that factor. For later series chips (AR9280 and later), the TX descriptor TX power values need to be adjusted to account for the PHY minimum TX power being -2.5dBm, rather than 0 dBm (ie, instead of 0 == 0 dBm, 0 == -2.5dBm.) For later later chips (AR9285), there are some differences between TX power levels for CCK, OFDM and HT rates. >How-To-Repeat: Enable TPC, see things go haywire. >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/178263: [ath] review the use of ic_freq / ic_ieee / ic_flags / ichan->channel
>Number: 178263 >Category: kern >Synopsis: [ath] review the use of ic_freq / ic_ieee / ic_flags / >ichan->channel >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Apr 30 16:20:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: adrian chadd >Release:-HEAD >Organization: >Environment: n/a >Description: Review the use of the frequency / channel fields in ieee80211_channel and HAL_CHANNEL_INTERNAL. * check whether net80211's ieee80211_channel entry stores the real frequency (eg 900mhz, 420mhz mapping) or the underlying channel frequency; * .. and whether ic_flags shows a 900MHz channel using 2.4GHz hardware as being a 2.4GHz channel; * .. and whether ic_ieee reflects the 900MHz IEEE number, or the 2.4GHz hardware number. * Evaluate what HAL_CHANNEL_INTERNAL gets - I _think_ it gets the real channel frequency in 'channel', but we don't store the real channel IEEE number. The aim is to correctly support channel mapping for the 11n chips. I'm worried that ic_freq / ic_flags / ic_ieee is used in places where it shouldn't be. It's also a big requirement to get channel mapping 'right' on the AR9380 and later hardware, in case some vendors (eg Ubiquiti) decide to glue downconverters on the newer chips. It's possible that I'll have to extend the HAL to include this information in HAL_CHANNEL_INTERNAL and then modify a bunch of code to use HAL_CHANNEL_INTERNAL instead of ieee80211_channel when looking at what the _hardware_ programming should look like. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/178378: [net80211] crypto state isn't reset during a reassociation
>Number: 178378 >Category: misc >Synopsis: [net80211] crypto state isn't reset during a reassociation >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon May 06 22:00:01 UTC 2013 >Closed-Date: >Last-Modified: >Originator: adrian chadd >Release: >Organization: >Environment: >Description: When a station reassociates, the crypto state (eg CCMP RSC/TSC counters) may not be reset "right". >How-To-Repeat: What I see: * doing lots of UDP TX from FreeBSD STA -> FreeBSD AP; * the station reassociates; * .. lots of CCMP replay attack complaints on the AP side. >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/178379: [net80211] [ath] WPA rekey on the STA side fails when transmitting lots of UDP traffic
>Number: 178379 >Category: misc >Synopsis: [net80211] [ath] WPA rekey on the STA side fails when >transmitting lots of UDP traffic >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon May 06 22:10:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: adrian chadd >Release: >Organization: >Environment: >Description: When UDP iperf transmit is going on, a WPA group rekey fails and the AP ditches the station. What's going on: * FreeBSD AP -> FreeBSD STA (both ath) * AP sends a WPA rekey EAPOL message to the STA * STA updates the key, sends an EAPOL message back * AP doesn't get it, so it eventually disconnects the station. What's breaking: * The STA gets the EAPOL group rekey frame * the STA updates the keycache entry * The STA sends the EAPOL response * .. but it doesn't actually send the frame, it gets dropped by ath_start() because the buffers are all allocated. I'll dig into it some more. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/178477: [ath] missed beacon / soft reset in STA mode results in hardware error and DMA engine lockup
>Number: 178477 >Category: kern >Synopsis: [ath] missed beacon / soft reset in STA mode results in >hardware error and DMA engine lockup >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri May 10 10:00:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: adrian chadd >Release:-HEAD >Organization: >Environment: >Description: With my most recent changes in ath(4) to the TX DMA list (ie, only writing new TxDP entries for a queue for the first frame being sent after reset; then always using the holding descriptor and link pointer for subsequent frames) I've uncovered a rather annoying bug. If a no-loss reset is done (ie, no packets are lost) the hardware will end up locking up. This is triggerable in STA mode. AP mode doesn't (for now) seem to be a problem. What's seen: ath0: hardware error; resetting ath0: 0x 0x0020 0x, 0x 0x 0x ar5416StopDmaReceive: dma failed to stop in 10ms AR_CR=0x0024 AR_DIAG_SW=0x4220 after this point, no combination of soft or hard chip reset unlocks the DMA engine. When reset debugging is enabled, the queue looks like this: ath0: ath_tx_stopdma: tx queue [3] 0, active=1, hwpending=1, flags 0x, link 0x As far as I'm aware, the TX queue TxDP should never be 0x0 if it's active. Anyway. This is easy to reproduce. >How-To-Repeat: * Insert AR5416 card * Create STA vap * Associate to AP * Force a 'stuck beacon' no-loss reset - sysctl dev.ath.X.forcebstuck=1 * .. the next transmission will cause a hardware error. >Fix: Not sure yet. There's not many things that can go wrong here: * is there a frame on the TXQ that's actually already been freed? * is the holding descriptor not being freed during a soft reset? * .. and what about the link pointer? it should be set to NULL during reset, then the DMA restart routine should re-initialise the link pointer to the last descriptor in the last frame in the list. Or NULL, if the list is empty. Actually, I just hacked on the DMA restart code to ensure that the link pointer is either initialised to the last descriptor in the list or NULL. That seems to have fixed it. So, the reset path isn't freeing the holding descriptor or NULL'ing the axq_link pointer. Fix that! >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/179269: [ath] [AR9285] RX antenna diversity is not functioning correctly; breaks single-antenna designs
>Number: 179269 >Category: kern >Synopsis: [ath] [AR9285] RX antenna diversity is not functioning >correctly; breaks single-antenna designs >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Jun 03 19:10:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: adrian chadd >Release:FreeBSD-10 >Organization: >Environment: >Description: This is applicable to -9 and -8 as well. The AR9285 is a 1x1 design with a twist on "classic" style antenna diversity. The MAC can choose: * RX on antenna 1 or 2; * RX on both, by using a "mixer configuration" to mix the signals from both antennas a specific way; * RX on both, by selecting either antenna 1 or 2 (ie, classic diversity) based on signal level; * RX on both, by using the above mixer configuration (well two - main and alternate) and selecting one based on signal level Now, by default, we're only doing RX on a single antenna. The AR_DEF_ANTENNA register controls the static antenna selection if fast diversity isn't enabled. However! The AR5416 HAL does this: /* * Preserve the antenna on a channel change */ saveDefAntenna = OS_REG_READ(ah, AR_DEF_ANTENNA); if (saveDefAntenna == 0)/* XXX magic constants */ saveDefAntenna = 1; . which means RX will only occur on antenna #2 if antenna diversity is disabled. So in one antenna solutions (antenna #1 / Main is connected) the unit will TX through the antenna, but RX through the unconnected port. >How-To-Repeat: * AR9285 * Connect an antenna to antenna #1 * do NOT connect an antenna to antenna #2 * Try being a station for a while >Fix: This workaround (for the AR5416, I guess) needs to be made conditional. Fast and slow antenna diversity should be enabled as well. I'll go through the code and figure out why that isn't enabled. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/179482: [ath] Fix AR9462 external LNA configuration
>Number: 179482
>Category: misc
>Synopsis: [ath] Fix AR9462 external LNA configuration
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Tue Jun 11 09:50:01 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: adrian chadd
>Release:
>Organization:
>Environment:
>Description:
This ath9k patch needs porting to freebsd's qca_main HAL.
It unfortunately isn't in the upstream HAL yet; it's in a development branch.
https://patchwork.kernel.org/patch/2696121/
===
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
index e6b92ff..25b8bbb 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
@@ -3563,14 +3563,18 @@ static void ar9003_hw_ant_ctrl_apply(struct ath_hw
*ah, bool is2ghz)
{
struct ath9k_hw_capabilities *pCap = &ah->caps;
int chain;
- u32 regval;
+ u32 regval, value;
static const u32 switch_chain_reg[AR9300_MAX_CHAINS] = {
AR_PHY_SWITCH_CHAIN_0,
AR_PHY_SWITCH_CHAIN_1,
AR_PHY_SWITCH_CHAIN_2,
};
- u32 value = ar9003_hw_ant_ctrl_common_get(ah, is2ghz);
+ if (AR_SREV_9485(ah) && (ar9003_hw_get_rx_gain_idx(ah) == 0))
+ ath9k_hw_cfg_output(ah, AR9300_EXT_LNA_CTL_GPIO_AR9485,
+ AR_GPIO_OUTPUT_MUX_AS_PCIE_ATTENTION_LED);
+
+ value = ar9003_hw_ant_ctrl_common_get(ah, is2ghz);
if (AR_SREV_9462(ah) || AR_SREV_9565(ah)) {
REG_RMW_FIELD(ah, AR_PHY_SWITCH_COM,
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.h
b/drivers/net/wireless/ath/ath9k/ar9003_phy.h
index e717741..5013c73 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.h
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.h
@@ -351,6 +351,8 @@
#define AR_PHY_CCA_NOM_VAL_9330_2GHZ -118
+#define AR9300_EXT_LNA_CTL_GPIO_AR9485 9
+
/*
* AGC Field Definitions
*/
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/179547: [ath] Add AR9485 custom board fixes (CUS198)
>Number: 179547 >Category: kern >Synopsis: [ath] Add AR9485 custom board fixes (CUS198) >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Jun 14 05:20:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: adrian chadd >Release: >Organization: >Environment: >Description: There's a custom board type containing the AR9485 which requires some slightly different config handling. I don't know if the qca_main based HAL has this code or not. So - evaluate what's going on, and if not, port it over. The Linux bug and patch: https://bugzilla.kernel.org/show_bug.cgi?id=49201 https://patchwork.kernel.org/patch/2718041/ >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/179827: [hwpmc] process-mode counters aren't correctly read on multi-core machines
>Number: 179827 >Category: kern >Synopsis: [hwpmc] process-mode counters aren't correctly read on >multi-core machines >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Jun 22 01:50:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: adrian chadd >Release:9-STABLE, r252049, amd64 (and i386) >Organization: Netflix, Inc >Environment: >Description: When using a process mode counter PMC on a multi-core machine, the pmc_read() -> PMC_OP_PMCRW event is not correctly reading the PMC. What's going on in hwpmc_mod.c is thus: * It grabs the current thread CPU; * It then checks if the PMC is active; * If it's currently active, it reads the PMC from the current CPU rather than the target CPU; * .. otherwise it returns the old counter value. When I enabled pmc debugging: DEBUG in the kernel, then: # sysctl kern.hwpmc.debugflags="csw=swo,swi pmc=ops" I'd see this: * lots of swi, swo (swapin, swapout) of the process, which updates the cached PMC value * a PMC,OPS event every second whilst it was reading the process mode counter * .. but the PMC,OPS value would always be the "old" one, rather than the updated one. The only time the counter value was updated was if the PMC,OPS (ie, the PMC_OP_PMCRW event) occured _during_ the running of the process - ie, the scheduler put the process being counted _and_ the pmcstat process on the same CPU, switched out the process under profiling (which would switch it out and update the value) and switched in pmcstat to do the read. This reads like it was really designed for reading counters from an active process - ie, where you'd put pmc_read() at specific points in a programs execution in order to count how long certain events were taking. It's totally bogus for the SMP case, where your current process being run is on another CPU and doesn't get switched out for long stretches of time, whilst pmcstat wakes up once a second on another CPU to do a counter read. >How-To-Repeat: * grab a multi-core device; * Grab some CPU chewing process that doesn't do any kind of blocking - ie, some minute long math problem; * run pmcstat in counting mode - pmcstat -p instructions -w 1 ./process * watch the counters look totally bogus. * See above for the sysctl line to enable pmc debugging and you'll see how bogus the sampling is. >Fix: I'm not sure. There may be multiple problems here: * One is ensuring the PMC stats are read from the CPU the pmc counter is actively active on, as it may be a different CPU to the thread calling pmc_read() -> PMC_OP_PMCRW; * Another is checking to see if the PMC is actually active at the present moment on _any_ CPU and if it is, fetch the statistics from said correct CPU. * I'm not sure what the deal is with running counting mode samples on a multi-core CPU with multiple threads running in the process under count. Ie, if you have 4 threads on 4 separate CPUs running and you're trying to count '-p instructions', then I think the right behaviour is to enable the instructions counter on -all- the CPUs with those threads active. So what should pmc_read() do? Does the kernel-side correctly read all the CPUs with threads active for that particular registered PMC? Or what is actually going on? >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/179827: [hwpmc] process-mode counters aren't correctly read on multi-core machines
The following reply was made to PR kern/179827; it has been noted by GNATS.
From: Adrian Chadd
To: hiren panchasara
Cc: bug-follo...@freebsd.org
Subject: Re: kern/179827: [hwpmc] process-mode counters aren't correctly
read on multi-core machines
Date: Sat, 22 Jun 2013 10:03:46 -0700
You can't do sleep() ; that yields the CPU.
Replace it with a busy loop that constantly does some math.
Adrian
On 22 June 2013 02:35, hiren panchasara wrote:
> This is what I am seeing on head:
>
> -bash-4.2$ uname -a
> FreeBSD head.box.some.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0
> r251604: Tue Jun 11 19:08:35 UTC 2013
> hir...@head.box.some.com:/home/hirenp/head/sys/amd64/compile/GENERIC
> amd64
> -bash-4.2$ sysctl hw.ncpu
> hw.ncpu: 24
> -bash-4.2$
>
> -bash-4.2$ sysctl -a | grep hwpmc
> kern.features.hwpmc_hooks: 1
> kern.hwpmc.softevents: 16
> kern.hwpmc.callchaindepth: 8
> kern.hwpmc.debugflags: csw=swo,swi pmc=ops
> kern.hwpmc.hashsize: 16
> kern.hwpmc.nsamples: 512
> kern.hwpmc.mtxpoolsize: 32
> kern.hwpmc.logbuffersize: 4
> kern.hwpmc.nbuffers: 64
> -bash-4.2$
>
> -bash-4.2$ cat count.c
> #include
> #include
> #include
>
> int main() {
>
> for (int i=0; i<60; i++) {
> sleep(1);
> }
>
> return 0;
> }
>
>
> -bash-4.2$ pmcstat -p instructions -w 1 ./count
> CSW:SWO:1: cpu=2 proc=0xfe0047ea6970 (2615, pmcstat) pp=0
> PMC:OPS:1: start pmc=0xfe005d81e800 mode=3 ri=21
> CSW:SWI:1: cpu=16 proc=0xfe0047afc970 (2616, pmcstat)
> pp=0xfe005dbd6c00
> CSW:SWO:1: cpu=2 proc=0xfe0047ea6970 (2615, pmcstat) pp=0
> CSW:SWI:1: cpu=16 ri=21 new=0
> CSW:SWO:1: cpu=16 proc=0xfe0047afc970 (2616, pmcstat)
> pp=0xfe005dbd6c00
> CSW:SWO:1: cpu=16 ri=21 tmp=6285116
> CSW:SWI:1: cpu=20 proc=0xfe0047afc970 (2616, pmcstat)
> pp=0xfe005dbd6c00
> CSW:SWI:1: cpu=20 ri=21 new=6285116
> CSW:SWO:1: cpu=20 proc=0xfe0047afc970 (2616, pmcstat)
> pp=0xfe005dbd6c00
> CSW:SWO:1: cpu=20 ri=21 tmp=6245302
> CSW:SWI:1: cpu=1 proc=0xfe0047afc970 (2616, pmcstat)
> pp=0xfe005dbd6c00
> CSW:SWI:1: cpu=1 ri=21 new=12530418
> CSW:SWO:1: cpu=1 proc=0xfe0047afc970 (2616, count) pp=0xfe005dbd6c00
> CSW:SWO:1: cpu=1 ri=21 tmp=11918927
>
> # PMC:OPS:1: rw id=-16579051 flags=0x20
> PMC:OPS:2: rw id=21 -> old 1751141
> CSW:SWO:1: cpu=12 proc=0xfe0047ea6970 (2615, pmcstat) pp=0
> CSWnstructions
> 244493:S45 WO:1: cpu=6 proc=0xfe0047ea6970 (2615, pmcstat)
> pp=0
> CSW:SWI:1: cpu=1 proc=0xfe0047afc970 (2616, count) pp=0xfe005dbd6c00
> CSW:SWI:1:
> c# p/instructionpu=s
> 1 ri=21 new=24449345
> PMC:OPS:1: rw id=-16579051 flags=0x20
> CSW:SWO:1: cpu=1 proc=0xfe0047afc970 (2616, count) pp=0xfe005dbd6c00
> PMC:OPS:2: rw id=21 -> old 1751141
> CSW:0 SWO:1: cpu=1 ri=21 tmp=97027040
> CSW:SWO:1: cpu=6 proc=0xfe0047ea6970 (2615, pmcstat) pp=0
>
> PMC# p/instruction:Os
> PS:1: rw id=-16579051 flags=0x20
> CSW:SWI:1: cpu=16 proc=0xfe0047afc970 (2616, count) pp=0xfe005dbd6c00
> PMC:OPS:2: rw id=21 -> old 73d9521
> C 9702704SW:0 SWI:1: cpu=16 ri=21 new=121476385
> CSW:SWO:1: cpu=6 proc=0xfe0047ea6970 (2615, pmcstat) pp=0
> CSW:SWO:1: cpu=16 proc=0xfe0047afc970 (2616, count) pp=0xfe005dbd6c00
> CSW:SWO:1: cpu=16 ri=21 tmp=121961432
>
> PM# p/instructionC:Os
> PS:1: rw id=-16579051 flags=0x20
> PMC:OPS:2: rw id=21 -> old e8290f9
> 12196143CS2 W:SWO:1: cpu=6 proc=0xfe0047ea6970 (2615, pmcstat)
> pp=0
> CSW:SWI:1: cpu=16 proc=0xfe0047afc970 (2616, count) pp=0xfe005dbd6c00
> CSW:SWI:1: cpu=16 ri=21 new=243437817
> CSW:SWO:1: cpu=16 proc=0xfe0047afc970 (2616, count) pp=0xfe005dbd6c00
> CSW:SWO:1: cpu=16 ri=21 tmp=56320362
>
> PM# p/instructionC:Os
> PS:1: rw id=-16579051 flags=0x20
> PMC:OPS:2: rw id=21 -> old 11ddf263
> 5632036CSW2 :SWO:1: cpu=6 proc=0xfe0047ea6970 (2615, pmcstat)
> pp=0
> CSW:SWI:1: cpu=16 proc=0xfe0047afc970 (2616, count) pp=0xfe005dbd6c00
> CSW:SWI:1: cpu=16 ri=21 new=299758179
> CSW:SWO:1: cpu=16 proc=0xfe0047afc970 (2616, count) pp=0xfe005dbd6c00
> CSW:SWO:1: cpu=16 ri=21 tmp=56408687
>
> PM# p/instructionC:Os
> PS:1: rw id=-16579051 flags=0x20
> PMC:OPS:2: rw id=21 -> old 153aacd2
> 5640868CSW7 :SWO:1: cpu=6 proc=0xfe0047ea6970 (2615, pmcstat)
> pp=0
> CSW:SWI:1: cpu=16 proc=0xfe0047afc970 (2616, count) pp=0xfe005dbd6c00
> CSW:SWI:1: cpu=16 ri=21 new=356166866
> CSW:SWO:1: cpu=16 proc=0xfe0047afc970 (2616, count) pp=0xfe005dbd6c00
&g
Re: kern/179827: [hwpmc] process-mode counters aren't correctly read on multi-core machines
The following reply was made to PR kern/179827; it has been noted by GNATS. From: Adrian Chadd To: hiren panchasara Cc: bug-follo...@freebsd.org Subject: Re: kern/179827: [hwpmc] process-mode counters aren't correctly read on multi-core machines Date: Sat, 22 Jun 2013 13:23:24 -0700 Right. Do that but with the test running in another window, so you don't get the message overlap. THen look at how the results show lots of '0' from pmcstat, and then correlate that with the one-second "PMC,OPS" sample lines. See how whenever they're run whilst the process is running (ie, the last event was SWI) and it hasn't yet been de-scheduled. because it's still running, the saved counter is never updated with the PMC counter and subsequent reads (until it does get de-scheduled!) return the same cached value. Hence, lots of '0's, followed by a big, big counter value. adrian ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/181132: [iwn] stream calculation is wrong for the Intel 4965
>Number: 181132 >Category: kern >Synopsis: [iwn] stream calculation is wrong for the Intel 4965 >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Aug 08 05:50:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release:-HEAD >Organization: >Environment: >Description: When the 4965 probes (and bootverbose is set), it sees 2 transmit radios and 3 receive radios. So it assumes that the hardware is a 2T3R device. Which is actually incorrect - even though it has three receive radios, it's still a two-stream receive device. >How-To-Repeat: * Bootverbose! * Probe/attach an Intel 4965 * See what's going on! >Fix: Until Intel 3x3 devices are supported, we should limit the TX/RX stream counts to 2. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/181311: chromium port - unable to click on window items
>Number: 181311 >Category: misc >Synopsis: chromium port - unable to click on window items >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Aug 15 00:30:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: adrian chadd >Release:9-stable >Organization: >Environment: >Description: I've just updated to the latest 9-stable pre-release binary package set (from bapt) and although chromium works, it won't let me click on various things. The big one in question is gmail - it won't let me click on emails in gmail. Buttons are fine. Just not window items that aren't links. Installed version: adrian@lucy:~]> pkg info | grep chrom chromium-28.0.1500.71_1Mostly BSD-licensed web browser based on WebKit and Gtk+ xf86-video-openchrome-0.3.3X.Org openChrome display driver >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/181346: [hwpmc] Sandy Bridge Xeon - workaround required for some perf events
>Number: 181346 >Category: misc >Synopsis: [hwpmc] Sandy Bridge Xeon - workaround required for some perf >events >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Aug 16 20:30:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: adrian chadd >Release: >Organization: >Environment: >Description: There's a workaround required for some events on Sandy bridge Xeon hardware. http://software.intel.com/en-us/articles/performance-monitoring-on-intel-xeon-processor-e5-family Here's the workaround packaged up in a linux-specific python script. ugh. https://github.com/andikleen/pmu-tools/blob/master/latego.py I have no idea about the specifics of the workaround; only that we should likely add support to hwpmc to do this. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/183260: [iwn] [4965] transmit seems to fail after a while
>Number: 183260 >Category: kern >Synopsis: [iwn] [4965] transmit seems to fail after a while >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Oct 24 06:00:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: adrian chadd >Release:-HEAD >Organization: >Environment: >Description: Transmit seems to fail after a while. Here's the output of tx_done whilst transmit is failing: Oct 23 15:46:26 lucy kernel: iwn_tx_data: qid 0 idx 180 len 52 nsegs 2 Oct 23 15:46:26 lucy kernel: iwn4965_tx_done: qid 0 idx 180 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:27 lucy kernel: iwn_tx_data: qid 0 idx 181 len 52 nsegs 2 Oct 23 15:46:27 lucy kernel: iwn4965_tx_done: qid 0 idx 181 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:28 lucy kernel: iwn_tx_data: qid 0 idx 182 len 52 nsegs 2 Oct 23 15:46:28 lucy kernel: iwn4965_tx_done: qid 0 idx 182 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:29 lucy kernel: wlan0: [f8:e4:fb:1a:49:79] AMRR: current rate 15, txcnt=11, retrycnt=0 . note that AMRR thinks things are A-OK. Oct 23 15:46:29 lucy kernel: iwn_tx_data: qid 0 idx 183 len 52 nsegs 2 Oct 23 15:46:29 lucy kernel: iwn4965_tx_done: qid 0 idx 183 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:30 lucy kernel: iwn_tx_data: qid 0 idx 184 len 52 nsegs 2 Oct 23 15:46:30 lucy kernel: iwn4965_tx_done: qid 0 idx 184 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:31 lucy kernel: iwn_tx_data: qid 0 idx 185 len 52 nsegs 2 Oct 23 15:46:31 lucy kernel: iwn4965_tx_done: qid 0 idx 185 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:32 lucy kernel: iwn_tx_data: qid 0 idx 186 len 52 nsegs 2 Oct 23 15:46:32 lucy kernel: iwn4965_tx_done: qid 0 idx 186 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:33 lucy kernel: iwn_tx_data: qid 0 idx 187 len 52 nsegs 2 Oct 23 15:46:33 lucy kernel: iwn4965_tx_done: qid 0 idx 187 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:34 lucy kernel: iwn_tx_data: qid 0 idx 188 len 52 nsegs 2 Oct 23 15:46:34 lucy kernel: iwn4965_tx_done: qid 0 idx 188 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:38 lucy kernel: iwn_tx_data: qid 0 idx 189 len 52 nsegs 2 Oct 23 15:46:38 lucy kernel: iwn4965_tx_done: qid 0 idx 189 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:39 lucy kernel: iwn_tx_data: qid 0 idx 190 len 52 nsegs 2 Oct 23 15:46:39 lucy kernel: iwn4965_tx_done: qid 0 idx 190 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:40 lucy kernel: iwn_tx_data: qid 0 idx 191 len 52 nsegs 2 Oct 23 15:46:40 lucy kernel: iwn4965_tx_done: qid 0 idx 191 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:41 lucy kernel: iwn_tx_data: qid 0 idx 192 len 52 nsegs 2 Oct 23 15:46:41 lucy kernel: iwn4965_tx_done: qid 0 idx 192 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:42 lucy kernel: iwn_tx_data: qid 0 idx 193 len 52 nsegs 2 Oct 23 15:46:42 lucy kernel: iwn4965_tx_done: qid 0 idx 193 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:43 lucy kernel: wlan0: [f8:e4:fb:1a:49:79] AMRR: current rate 15, txcnt=11, retrycnt=0 Oct 23 15:46:43 lucy kernel: iwn_tx_data: qid 0 idx 194 len 52 nsegs 2 Oct 23 15:46:43 lucy kernel: iwn4965_tx_done: qid 0 idx 194 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:44 lucy kernel: iwn_tx_data: qid 0 idx 195 len 52 nsegs 2 Oct 23 15:46:44 lucy kernel: iwn4965_tx_done: qid 0 idx 195 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:46 lucy kernel: iwn_tx_data: qid 0 idx 196 len 52 nsegs 2 Oct 23 15:46:46 lucy kernel: iwn4965_tx_done: qid 0 idx 196 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:46 lucy kernel: iwn_tx_data: qid 0 idx 197 len 52 nsegs 2 Oct 23 15:46:46 lucy kernel: iwn4965_tx_done: qid 0 idx 197 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:47 lucy kernel: iwn_tx_data: qid 0 idx 198 len 52 nsegs 2 Oct 23 15:46:47 lucy kernel: iwn4965_tx_done: qid 0 idx 198 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:48 lucy kernel: iwn_tx_data: qid 0 idx 199 len 52 nsegs 2 Oct 23 15:46:48 lucy kernel: iwn4965_tx_done: qid 0 idx 199 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:49 lucy kernel: iwn_tx_data: qid 0 idx 200 len 52 nsegs 2 Oct 23 15:46:49 lucy kernel: iwn4965_tx_done: qid 0 idx 200 retries 0 nkill 0 rate 8000 duration 0 status 8b ^C adrian@lucy:~/work/freebsd/ath/head/src/sys/modules]> tail -f /var/log/all.log Oct 23 15:49:00 lucy kernel: wlan0: [00:1f:3b:27:ae:88] amrr_node_init: non-11n node Oct 23 15:49:00 lucy kernel: wlan0: [00:1f:3b:27:ae:88] AMRR: nrates=0, initial rate 0 Oc
kern/183259: [iwn] [4965] transmit seems to fail after a while
>Number: 183259 >Category: kern >Synopsis: [iwn] [4965] transmit seems to fail after a while >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Oct 24 06:00:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: adrian chadd >Release:-HEAD >Organization: >Environment: >Description: Transmit seems to fail after a while. Here's the output of tx_done whilst transmit is failing: Oct 23 15:46:26 lucy kernel: iwn_tx_data: qid 0 idx 180 len 52 nsegs 2 Oct 23 15:46:26 lucy kernel: iwn4965_tx_done: qid 0 idx 180 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:27 lucy kernel: iwn_tx_data: qid 0 idx 181 len 52 nsegs 2 Oct 23 15:46:27 lucy kernel: iwn4965_tx_done: qid 0 idx 181 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:28 lucy kernel: iwn_tx_data: qid 0 idx 182 len 52 nsegs 2 Oct 23 15:46:28 lucy kernel: iwn4965_tx_done: qid 0 idx 182 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:29 lucy kernel: wlan0: [f8:e4:fb:1a:49:79] AMRR: current rate 15, txcnt=11, retrycnt=0 . note that AMRR thinks things are A-OK. Oct 23 15:46:29 lucy kernel: iwn_tx_data: qid 0 idx 183 len 52 nsegs 2 Oct 23 15:46:29 lucy kernel: iwn4965_tx_done: qid 0 idx 183 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:30 lucy kernel: iwn_tx_data: qid 0 idx 184 len 52 nsegs 2 Oct 23 15:46:30 lucy kernel: iwn4965_tx_done: qid 0 idx 184 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:31 lucy kernel: iwn_tx_data: qid 0 idx 185 len 52 nsegs 2 Oct 23 15:46:31 lucy kernel: iwn4965_tx_done: qid 0 idx 185 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:32 lucy kernel: iwn_tx_data: qid 0 idx 186 len 52 nsegs 2 Oct 23 15:46:32 lucy kernel: iwn4965_tx_done: qid 0 idx 186 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:33 lucy kernel: iwn_tx_data: qid 0 idx 187 len 52 nsegs 2 Oct 23 15:46:33 lucy kernel: iwn4965_tx_done: qid 0 idx 187 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:34 lucy kernel: iwn_tx_data: qid 0 idx 188 len 52 nsegs 2 Oct 23 15:46:34 lucy kernel: iwn4965_tx_done: qid 0 idx 188 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:38 lucy kernel: iwn_tx_data: qid 0 idx 189 len 52 nsegs 2 Oct 23 15:46:38 lucy kernel: iwn4965_tx_done: qid 0 idx 189 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:39 lucy kernel: iwn_tx_data: qid 0 idx 190 len 52 nsegs 2 Oct 23 15:46:39 lucy kernel: iwn4965_tx_done: qid 0 idx 190 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:40 lucy kernel: iwn_tx_data: qid 0 idx 191 len 52 nsegs 2 Oct 23 15:46:40 lucy kernel: iwn4965_tx_done: qid 0 idx 191 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:41 lucy kernel: iwn_tx_data: qid 0 idx 192 len 52 nsegs 2 Oct 23 15:46:41 lucy kernel: iwn4965_tx_done: qid 0 idx 192 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:42 lucy kernel: iwn_tx_data: qid 0 idx 193 len 52 nsegs 2 Oct 23 15:46:42 lucy kernel: iwn4965_tx_done: qid 0 idx 193 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:43 lucy kernel: wlan0: [f8:e4:fb:1a:49:79] AMRR: current rate 15, txcnt=11, retrycnt=0 Oct 23 15:46:43 lucy kernel: iwn_tx_data: qid 0 idx 194 len 52 nsegs 2 Oct 23 15:46:43 lucy kernel: iwn4965_tx_done: qid 0 idx 194 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:44 lucy kernel: iwn_tx_data: qid 0 idx 195 len 52 nsegs 2 Oct 23 15:46:44 lucy kernel: iwn4965_tx_done: qid 0 idx 195 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:46 lucy kernel: iwn_tx_data: qid 0 idx 196 len 52 nsegs 2 Oct 23 15:46:46 lucy kernel: iwn4965_tx_done: qid 0 idx 196 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:46 lucy kernel: iwn_tx_data: qid 0 idx 197 len 52 nsegs 2 Oct 23 15:46:46 lucy kernel: iwn4965_tx_done: qid 0 idx 197 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:47 lucy kernel: iwn_tx_data: qid 0 idx 198 len 52 nsegs 2 Oct 23 15:46:47 lucy kernel: iwn4965_tx_done: qid 0 idx 198 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:48 lucy kernel: iwn_tx_data: qid 0 idx 199 len 52 nsegs 2 Oct 23 15:46:48 lucy kernel: iwn4965_tx_done: qid 0 idx 199 retries 0 nkill 0 rate 8000 duration 0 status 8b Oct 23 15:46:49 lucy kernel: iwn_tx_data: qid 0 idx 200 len 52 nsegs 2 Oct 23 15:46:49 lucy kernel: iwn4965_tx_done: qid 0 idx 200 retries 0 nkill 0 rate 8000 duration 0 status 8b ^C adrian@lucy:~/work/freebsd/ath/head/src/sys/modules]> tail -f /var/log/all.log Oct 23 15:49:00 lucy kernel: wlan0: [00:1f:3b:27:ae:88] amrr_node_init: non-11n node Oct 23 15:49:00 lucy kernel: wlan0: [00:1f:3b:27:ae:88] AMRR: nrates=0, initial rate 0 Oc
kern/183428: [net80211] [iwn] Some APs seem to announce HT but no HT rates
>Number: 183428 >Category: kern >Synopsis: [net80211] [iwn] Some APs seem to announce HT but no HT rates >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Oct 29 04:00:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release:-HEAD >Organization: >Environment: >Description: I just came across an 802.11n AP that doesn't announce 802.11n rates. The net80211 code dutifully sets the channel up as an 11n channel and populates the HT rate set as empty. So, amrr gets very confused when this occurs. And so does iwn. There's two things to fix: * amrr should not treat the node as 11n if there are no 11n rates; * iwn should not assume that if the channel is 11n, that the rate is an MCS rate. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/183430: [iwn] latest change to the rate code setup uses 11n rates on an 11n channel when 11n rates aren't provided
>Number: 183430 >Category: misc >Synopsis: [iwn] latest change to the rate code setup uses 11n rates on >an 11n channel when 11n rates aren't provided >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Oct 29 04:00:01 UTC 2013 >Closed-Date: >Last-Modified: >Originator: adrian chadd >Release: >Organization: >Environment: -HEAD >Description: the latest changes in iwn messed up how the rates are calculated. the PLCP lookup code is doing the wrong thing - it assumes that an 11n channel will always have 11n traffic. However, some management traffic may be non-11n. So, support that. Some 11n APs get very unhappy if you send them 11n management frames, so don't do that. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/183645: [chrome] segfault in string operations
>Number: 183645 >Category: misc >Synopsis: [chrome] segfault in string operations >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Nov 04 01:20:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: adrian chadd >Release:11-CURRENT i386 >Organization: >Environment: FreeBSD lucy-11i386 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r257371M: Wed Oct 30 20:09:48 PDT 2013 adrian@lucy-11i386:/usr/home/adrian/work/freebsd/head/obj/usr/home/adrian/work/freebsd/head/src/sys/LUCY_11_i386 i386 >Description: This happened! :( I'm not sure whether it's a bug in chrome, or in our C++ library, or compiler, or what. Please let me know what extra debugging information I can provide. Thanks! -adrian adrian@lucy-11i386:~ % pkg info | grep chromium chromium-30.0.1599.101 Mostly BSD-licensed web browser based on WebKit and Gtk+ (gdb) bt #0 0x2d7d47ae in memcpy () from /lib/libc.so.7 #1 0x2d649454 in std::__1::basic_string, std::__1::allocator >::basic_s tring () from /usr/lib/libc++.so.1 #2 0x085f19e7 in ChromeMain () #3 0x08503527 in ChromeMain () #4 0x0a029c4d in utrie2_swap_46 () #5 0x0a02943a in utrie2_swap_46 () #6 0x0a0291df in utrie2_swap_46 () #7 0x0a027276 in utrie2_swap_46 () #8 0x08f3a15f in ChromeMain () #9 0x08e47efb in ChromeMain () #10 0x08e1be5f in ChromeMain () #11 0x08e4a55e in ChromeMain () #12 0x08e1c3a3 in ChromeMain () #13 0x08e1cf7b in ChromeMain () #14 0x08e1a95c in ChromeMain () #15 0x2ca838a1 in gtk_marshal_VOID__UINT_STRING () from /usr/local/lib/libgtk-x11-2.0.so.0 #16 0x2c8061fe in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.0 #17 0x2c81b72c in signal_emit_unlocked_R () from /usr/local/lib/libgobject-2.0.so.0 #18 0x2c81c3de in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 #19 0x2c81cc06 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 #20 0x2cbc4002 in gtk_widget_event () from /usr/local/lib/libgtk-x11-2.0.so.0 #21 0x2cbc3cf7 in gtk_widget_event () from /usr/local/lib/libgtk-x11-2.0.so.0 #22 0x2cbd68c7 in gtk_window_propagate_key_event () from /usr/local/lib/libgtk-x11-2.0.so.0 #23 0x08ddca99 in ChromeMain () #24 0x08ddbe1c in ChromeMain () #25 0x2ca838a1 in gtk_marshal_VOID__UINT_STRING () from /usr/local/lib/libgtk-x11-2.0.so.0 #26 0x2c8061fe in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.0 #27 0x2c81b72c in signal_emit_unlocked_R () from /usr/local/lib/libgobject-2.0.so.0 #28 0x2c81c3de in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 #29 0x2c81cc06 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 #30 0x2cbc4002 in gtk_widget_event () from /usr/local/lib/libgtk-x11-2.0.so.0 #31 0x2cbc3cf7 in gtk_widget_event () from /usr/local/lib/libgtk-x11-2.0.so.0 #32 0x2ca814bb in gtk_propagate_event () from /usr/local/lib/libgtk-x11-2.0.so.0 #33 0x2ca8113e in gtk_main_do_event () from /usr/local/lib/libgtk-x11-2.0.so.0 #34 0x09293394 in ChromeMain () #35 0x2cda241b in gdk_screen_get_setting () from /usr/local/lib/libgdk-x11-2.0.so.0 #36 0x2c88abea in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.0 ---Type to continue, or q to quit--- #37 0x2c88b00e in g_main_context_iterate () from /usr/local/lib/libglib-2.0.so.0 #38 0x2c88b09d in g_main_context_iteration () from /usr/local/lib/libglib-2.0.so.0 #39 0x092f8e58 in ChromeMain () #40 0x092f91bd in ChromeMain () #41 0x092ba176 in ChromeMain () #42 0x092d0cae in ChromeMain () #43 0x083b0e77 in ChromeMain () #44 0x0892c1db in ChromeMain () #45 0x08a55940 in ChromeMain () #46 0x0a4ff693 in utrie2_swap_46 () #47 0x08b51496 in ChromeMain () #48 0x08b50a4d in ChromeMain () #49 0x08075a4d in ChromeMain () #50 0x0807593a in ?? () #51 0x0001 in ?? () #52 0xbfbfdcb0 in ?? () #53 0xbfbfdcb8 in ?? () #54 0xbfbfdcb8 in ?? () #55 0xbfbfdcac in ?? () #56 0x in ?? () (gdb) >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/184104: [xorg] i830 display code hangs during startup
>Number: 184104 >Category: misc >Synopsis: [xorg] i830 display code hangs during startup >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Nov 20 08:00:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: adrian chadd >Release:-HEAD i386 >Organization: >Environment: FreeBSD sonia 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r258334: Tue Nov 19 08:32:56 PST 2013 adrian@sonia:/data/1/adrian/freebsd/head/obj/data/1/adrian/freebsd/head/src/sys/SONIA i386 >Description: CPU: CPU: Intel(R) Atom(TM) CPU N450 @ 1.66GHz (1666.51-MHz 686-class CPU) Display: vgapci0@pci0:0:2:0: class=0x03 card=0x83ac1043 chip=0xa0118086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller' class = display subclass = VGA vgapci1@pci0:0:2:1: class=0x038000 card=0x83ac1043 chip=0xa0128086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller' class = display Starting xorg simply hangs. See: http://people.freebsd.org/~adrian/ath/Xorg.0.log >How-To-Repeat: >Fix: Bill Paul fixed this for the exopc; the same bug and fix is here: http://people.freebsd.org/~wpaul/exopc/ However, it's not clear why it works. It may be something else besides the xorg driver as I have no issues with Linux + intel drivers on a 2011 era Ubuntu (but a 2011 era FreeBSD suffered the same fate; I ran with VESA since then.) >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
bin/184978: dhclient hostname changes can invalidate xauth sessions
>Number: 184978 >Category: bin >Synopsis: dhclient hostname changes can invalidate xauth sessions >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Dec 18 21:10:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release:-HEAD >Organization: >Environment: N/A - applies to 9.x, 10.x, 11.0 >Description: The hostname (re)setting via dhclient-script seems to cause the whole xauth session to suddenly be invalid. This prevents new X applications from starting. In a world where one can't just restart the X server without rebooting, this is a bit of a problem. >How-To-Repeat: Start an xauth session, then jump on a network whose DHCP server resets the hostname for you. >Fix: Changing the hostname back to the original hostname fixes things. I don't know whether disabling the hostname setup via dhclient is the right thing to do but it seems the only thing that works for me. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/187152: [i386] [acpi] resume from ACPI suspend (s3) sometimes results in all processes dying from sig 8 (SIGFPE)
>Number: 187152 >Category: kern >Synopsis: [i386] [acpi] resume from ACPI suspend (s3) sometimes results >in all processes dying from sig 8 (SIGFPE) >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Mar 01 02:00:00 UTC 2014 >Closed-Date: >Last-Modified: >Originator: adrian chadd >Release:11.0-CURRENT >Organization: >Environment: FreeBSD lucy-11i386 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r262523: Thu Feb 27 21:00:37 PST 2014 adrian@lucy-11i386:/usr/home/adrian/work/freebsd/head/obj/usr/home/adrian/work/freebsd/head/src/sys/LUCY_11_i386 i386 >Description: Sometimes a suspend/resume cycle will result in active processes dying from SIGFPE: Feb 27 19:16:26 lucy-11i386 kernel: pid 997 (sendmail), uid 0: exited on signal 8 Feb 27 19:16:26 lucy-11i386 kernel: pid 1173 (Xorg), uid 0: exited on signal 8 Feb 27 19:16:26 lucy-11i386 kernel: pid 901 (ntpd), uid 0: exited on signal 8 (core dumped) Feb 27 19:16:26 lucy-11i386 kernel: pid 1275 (upowerd), uid 0: exited on signal 8 (core dumped) Feb 27 19:16:26 lucy-11i386 kernel: pid 700 (devd), uid 0: exited on signal 8 (core dumped) . this results in a very un-useful system. >How-To-Repeat: Just suspend/resume a bunch. >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/160391: [ieee80211] [patch] Panic in mesh mode
Hi Edgar, Can you please provide; * A dmesg, just so we can see what/how many radios; * what do you mean by "create two mesh nodes" - do you mean two mesh nodes on the same board, one on each radio? Thanks, Adrian ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/160652: siba_bwn in GENERIC
The following reply was made to PR kern/160652; it has been noted by GNATS. From: Adrian Chadd To: bug-follo...@freebsd.org, cvs-...@yandex.ru Cc: Subject: Re: kern/160652: siba_bwn in GENERIC Date: Sun, 11 Sep 2011 20:12:56 +0800 How's this as an example (for sys/i386/conf/GENERIC): Index: GENERIC === --- GENERIC (revision 224905) +++ GENERIC (working copy) @@ -276,6 +276,11 @@ device ath_rate_sample # SampleRate tx rate control for ath #devicebwi # Broadcom BCM430x/BCM431x wireless NICs. #devicebwn # Broadcom BCM43xx wireless NICs. +#devicesiba_bwn# SIBA bus glue for the bwn(4) NIC. + # Please read bwn(4) before enabling this + # as it requires the siba_bwn and wlan_amrr + # kernel modules to be installed, as well as + # the net/bwn-firmware-kmod port. device ipw # Intel 2100 wireless NICs. device iwi # Intel 2200BG/2225BG/2915ABG wireless NICs. device iwn # Intel 4965/1000/5000/6000 wireless NICs. I'll have to commit something similar for other kernel config files. Adrian ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/160929: bsdinstall on 9.0-BETA2 incorrectly configures wpa/dhcp for wlan0
>Number: 160929
>Category: misc
>Synopsis: bsdinstall on 9.0-BETA2 incorrectly configures wpa/dhcp for
>wlan0
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Fri Sep 23 02:20:02 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Adrian Chadd
>Release:9.0-BETA2
>Organization:
>Environment:
FreeBSD viac3.home.cacheboy.net 9.0-BETA2 FreeBSD 9.0-BETA2 #0: Thu Sep 22
23:06:19 WST 2011 adr...@viac3.home.cacheboy.net:/usr/obj/usr/src/sys/VIAC3
i386
>Description:
When bsdinstall installed my system, it asked for wifi details.
It correctly configured and associated to my wifi during install, but it didn't
do so after a reboot.
/etc/rc.conf contained:
===
wlans_ath0="wlan0"
ifconfig_wlan0="WPADHCP"
===
I believe that should be "WPA DHCP" rather than "WPADHCP".
The install NIC was a D-Link DWA-552 later edition PCI 802.11ng NIC (AR9223.)
>How-To-Repeat:
* Boot 9.0-BETA2 off of USB stick
* Install to disk
* Post-configure wifi
* Reboot
>Fix:
>From IRC:
07:19 <@battlez> --- usr.sbin/bsdinstall/scripts/netconfig_ipv4 (revision
225733)
07:19 <@battlez> +++ usr.sbin/bsdinstall/scripts/netconfig_ipv4 (working copy)
07:19 <@battlez> @@ -45,7 +45,7 @@ esac
07:19 <@battlez>
07:19 <@battlez> dialog --backtitle 'FreeBSD Installer' --title 'Network
Configuration' --yesno 'Would you like to use DHCP to configure this
interface?' 0 0
07:19 <@battlez> if [ $? -eq $DIALOG_OK ]; then
07:19 <@battlez> - echo ifconfig_$INTERFACE=\"${IFCONFIG_PREFIX}DHCP\" >>
$BSDINSTALL_TMPETC/._rc.conf.net
07:19 <@battlez> + echo ifconfig_$INTERFACE=\"${IFCONFIG_PREFIX} DHCP\"
>> $BSDINSTALL_TMPETC/._rc.conf.net
07:20 <@battlez>
07:20 <@battlez> if [ ! -z $BSDINSTALL_CONFIGCURRENT ]; then
07:20 <@battlez> dialog --backtitle 'FreeBSD Installer'
--infobox "Acquiring DHCP lease..." 0 0
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/161526: script outputs corrupt if input is not from a terminal
>Number: 161526 >Category: misc >Synopsis: script outputs corrupt if input is not from a terminal >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Oct 12 22:10:07 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Adrian Wontroba >Release:RELENG_8 >Organization: na >Environment: FreeBSD awbsd.censored 8.2-STABLE FreeBSD 8.2-STABLE #0: Fri Oct 7 00:51:20 BST 2011 toor@awbsd.censored:/usr/obj/usr/src/sys/GENERIC i386 >Description: If the standard input for the current version of script (1.24.30.5) in RELENG_8 / 8-STABLE is not a terminal, in a simple case (running date) both the output file and the standard output from script are corrupt with multiple 5e 44 08 08 sequences inserted. The previous version of script (1.24.30.4) does not display this behaviour. Output is is similar irrespective of standard input redirection. I have been unable so far to produce a simple test case for my starting point of portupgrade hanging when run in a batch job. The examples below were produced using freshly compiled versions of the previous and current versions of script. I have already reverted /usr/bin/script on this system to the old version. current script without standard input redirection - works as expected [aw1@awbsd ~/script]$ /home/aw1/script/1.24.30.5/script -qa /tmp/56 date > /tmp/56o 2> /tmp/56e [aw1@awbsd ~/script]$ [aw1@awbsd /tmp]$ ls -l 56* -rw-r--r-- 1 aw1 wheel 36 Oct 12 22:17 56 -rw-r--r-- 1 aw1 wheel 0 Oct 12 22:17 56e -rw-r--r-- 1 aw1 wheel 30 Oct 12 22:17 56o [aw1@awbsd /tmp]$ for i in 56*; do echo $i; hd $i; done 56 64 61 74 65 0d 0a 57 65 64 20 4f 63 74 20 31 32 |date..Wed Oct 12| 0010 20 32 32 3a 31 37 3a 32 37 20 42 53 54 20 32 30 | 22:17:27 BST 20| 0020 31 31 0d 0a |11..| 0024 56e 56o 57 65 64 20 4f 63 74 20 31 32 20 32 32 3a 31 37 |Wed Oct 12 22:17| 0010 3a 32 37 20 42 53 54 20 32 30 31 31 0d 0a|:27 BST 2011..| 001e current script with standard input redirection - outputs corrupt [aw1@awbsd ~/script]$ /home/aw1/script/1.24.30.5/script -qa /tmp/55 date > /tmp/55o 2> /tmp/55e < /dev/null [aw1@awbsd ~/script]$ [aw1@awbsd /tmp]$ ls -l 55* -rw-r--r-- 1 aw1 wheel 516 Oct 12 22:11 55 -rw-r--r-- 1 aw1 wheel0 Oct 12 22:11 55e -rw-r--r-- 1 aw1 wheel 510 Oct 12 22:11 55o [aw1@awbsd /tmp]$ for i in 55*; do echo $i; hd $i; done 55 64 61 74 65 0d 0a 5e 44 08 08 5e 44 08 08 5e 44 |date..^D..^D..^D| 0010 08 08 5e 44 08 08 5e 44 08 08 5e 44 08 08 5e 44 |..^D..^D..^D..^D| * 01d0 08 08 5e 44 08 08 5e 44 08 08 5e 44 08 08 57 65 |..^D..^D..^D..We| 01e0 64 20 4f 63 74 20 31 32 20 32 32 3a 31 31 3a 31 |d Oct 12 22:11:1| 01f0 37 20 42 53 54 20 32 30 31 31 0d 0a 5e 44 08 08 |7 BST 2011..^D..| 0200 5e 44 08 08 |^D..| 0204 55e 55o 5e 44 08 08 5e 44 08 08 5e 44 08 08 5e 44 08 08 |^D..^D..^D..^D..| * 01d0 5e 44 08 08 5e 44 08 08 57 65 64 20 4f 63 74 20 |^D..^D..Wed Oct | 01e0 31 32 20 32 32 3a 31 31 3a 31 37 20 42 53 54 20 |12 22:11:17 BST | 01f0 32 30 31 31 0d 0a 5e 44 08 08 5e 44 08 08|2011..^D..^D..| 01fe the previous version of script (1.24.30.4) does not display this behaviour, previous script without standard input redirection [aw1@awbsd ~/script]$ /home/aw1/script/1.24.30.4/script -qa /tmp/46 date > /tmp/46o 2> /tmp/46e [aw1@awbsd ~/script]$ [aw1@awbsd /tmp]$ ls -l 46* -rw-r--r-- 1 aw1 wheel 36 Oct 12 22:14 46 -rw-r--r-- 1 aw1 wheel 0 Oct 12 22:14 46e -rw-r--r-- 1 aw1 wheel 30 Oct 12 22:14 46o [aw1@awbsd /tmp]$ for i in 46*; do echo $i; hd $i; done 46 64 61 74 65 0d 0a 57 65 64 20 4f 63 74 20 31 32 |date..Wed Oct 12| 0010 20 32 32 3a 31 34 3a 33 39 20 42 53 54 20 32 30 | 22:14:39 BST 20| 0020 31 31 0d 0a |11..| 0024 46e 46o 57 65 64 20 4f 63 74 20 31 32 20 32 32 3a 31 34 |Wed Oct 12 22:14| 0010 3a 33 39 20 42 53 54 20 32 30 31 31 0d 0a|:39 BST 2011..| 001e previous script with standard input redirection [aw1@awbsd ~/script]$ /home/aw1/script/1.24.30.4/script -qa /tmp/45 date > /tmp/45o 2> /tmp/45e < /dev/null [aw1@awbsd ~/script]$ [aw1@awbsd /tmp]$ ls -l 45* -rw-r--r-- 1 aw1 wheel 36 Oct 12 22:08 45 -rw-r--r-- 1 aw1 wheel 0 Oct 12 22:08 45e -rw-r--r-- 1 aw1 wheel 30 Oct 12 22:08 45o [aw1@awbsd /tmp]$ for i in 45*; do echo $i; hd $i; done 45 64 61 74 65 0d 0a 57 65 64 20 4f 63 74 20 31 32 |date..Wed Oct 12| 0010 20 32 32 3a 30 38 3a 34 31 20 42 53 54 20 32 30 | 22:08:41 BST 20| 0020
kern/162647: [ath] 11n TX aggregation session / TX hang
>Number: 162647 >Category: kern >Synopsis: [ath] 11n TX aggregation session / TX hang >Confidential: no >Severity: non-critical >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Nov 18 02:20:02 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release:10.0-CURRENT >Organization: FreeBSD >Environment: FreeBSD unknown 10.0-CURRENT FreeBSD 10.0-CURRENT #37: Thu Jan 1 08:00:00 WST 1970 adrian@dummy:/home/adrian/work/freebsd/git/adrianchadd-freebsd-work/obj/mipseb/mips.mipseb/home/adrian/work/freebsd/git/adrianchadd-freebsd-work/adrianchadd-freebsd-work/sys/RSPRO mips (it's a recent -HEAD, ignore the date.) hostap: AR9227 ath1: irq 1 at device 18.0 on pci0 ath1: [HT] enabling HT modes ath1: [HT] enabling short-GI in 20MHz mode ath1: [HT] 2 RX streams; 2 TX streams ath1: AR9227 mac 384.2 RF5133 phy 15.15 This also includes my git fixes for correctly handling packet queue flushes during reset, but this bug will occur regardless. >Description: A node flush is causing the BA window to be completely messed up, resulting in TX timeouts. It's currently unknown why ath_tx_tid_drain() was called - that's called from: * ath_tx_txq_drain() * ath_tx_node_flush() The former is called during ath_tx_draintxq(); the latter is called from ath_node_cleanup(). So either it's being called during ath_reset(sc, ATH_RESET_DEFAULT or ATH_RESET_FULL); or ic_node_cleanup. A log snippet: ath1: ath_tx_aggr_comp_aggr: TID 0: send BAR; seq 3678 ath1: ath_tx_aggr_comp_aggr: TID 0: send BAR; seq 3718 ath1: ath_tx_aggr_comp_aggr: TID 0: send BAR; seq 3742 ath1: ath_tx_aggr_comp_aggr: TID 0: send BAR; seq 3784 ath1: stuck beacon; resetting (bmiss count 4) ath1: ath_tx_tid_drain: node 0xc0927000: tid 0: txq_depth=2, txq_aggr_depth=2, sched=0, paused=0, hwq_depth=2, incomp=0, baw_head=103, baw_tail=38 txa_start=3396, ni_txseqs=3861 ath1: ath_tx_tid_drain: wasn't added: seqno 3459 ath1: ath_tx_tid_drain: wasn't added: seqno 3460 . . ath1: ath_tx_tid_drain: wasn't added: seqno 3857 ath1: ath_tx_tid_drain: wasn't added: seqno 3858 ath1: ath_tx_tid_drain: wasn't added: seqno 3859 ath1: ath_tx_tid_drain: wasn't added: seqno 3860 ath1: ath_tx_default_comp: dobaw should've been cleared! ath1: ath_tx_default_comp: dobaw should've been cleared! ath1: ath_tx_default_comp: dobaw should've been cleared! ath1: ath_tx_default_comp: dobaw should've been cleared! ath1: ath_tx_default_comp: dobaw should've been cleared! ath1: ath_tx_default_comp: dobaw should've been cleared! ath1: ath_tx_default_comp: dobaw should've been cleared! ath1: ath_tx_default_comp: dobaw should've been cleared! ath1: device timeout >How-To-Repeat: Just general hostap use. The question is how/why the node flush occured. >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/162648: [ath] AR9227 ADC DC calibration failure
>Number: 162648 >Category: misc >Synopsis: [ath] AR9227 ADC DC calibration failure >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Nov 18 04:00:22 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release:10.0-CURRENT >Organization: >Environment: Mips, etc. ath1: irq 1 at device 18.0 on pci0 ath1: [HT] enabling HT modes ath1: [HT] enabling short-GI in 20MHz mode ath1: [HT] 2 RX streams; 2 TX streams ath1: AR9227 mac 384.2 RF5133 phy 15.15 >Description: This is a failed ADC DC calibration: wlan1: [00:03:7f:12:e2:3a] HT bss occupancy change: 1 sta, 1 ht, 0 ht40, HT protmode now 0x2 ar5416GetMibCycleCountsPct: cycle counter wrap. ExtBusy = 0 ar5416ResetCalValid: Resetting Cal 4 state for channel 2437/0x20480 ar5416DoCalibration: ADC DC Calibration, state 1, calValid 0x8 ar5416SetupMeasurement: start ADC DC calibration ar9287olcTemperatureCompensation: initPDADC=125, currPDADC=120 ar9287olcTemperatureCompensation: delta=3 NF calibrated [ctl] [chain 0] is -123 NF calibrated [ctl] [chain 1] is -121 NF calibrated [ext] [chain 0] is -123 NF calibrated [ext] [chain 1] is -122 CCA: [0: -123][1: -121][3: -123][4: -121] 2437 raw nf -123 adjust 27 ar5416DoCalibration: ADC DC Calibration, state 2, calValid 0x8 ar5416DoCalibration: sample 0 of 1 finished 0: Chn 0 oddi=0x11a421e8; eveni=0x11a3b3d3; oddq=0x1198f4e5; evenq=0x1198f059; 0: Chn 1 oddi=0x13ac3b5b; eveni=0x13abe3a7; oddq=0x129faaac; evenq=0x129fa663; 0: Chn 2 oddi=0x; eveni=0x; oddq=0x; evenq=0x; Starting ADC DC Offset Cal for Chain 0 pwr_meas_odd_i = 295969256 pwr_meas_even_i = 295941075 pwr_meas_odd_q = 295236837 pwr_meas_even_q = 295235673 dc_offset_mismatch_i = 0x0047 dc_offset_mismatch_q = 0x0012 ADC DC Offset Cal done for Chain 0Starting ADC DC Offset Cal for Chain 1 pwr_meas_odd_i = 330054491 pwr_meas_even_i = 330032039 pwr_meas_odd_q = 312453804 pwr_meas_even_q = 312452707 dc_offset_mismatch_i = 0x00a1 dc_offset_mismatch_q = 0x0011 ADC DC Offset Cal done for Chain 1 ath1: stuck beacon; resetting (bmiss count 4) . then: ar5416SetupMeasurement: start ADC DC calibrationar5416GetMibCycleCountsPct: cycle counter wrap. ExtBusy = 0 ar5416DoCalibration: ADC DC Calibration, state 2, calValid 0x0 ar5416DoCalibration: sample 0 of 1 finished 0: Chn 0 oddi=0x0057; eveni=0x0086; oddq=0x031d; evenq=0x01ba; 0: Chn 1 oddi=0x025f; eveni=0x02d5; oddq=0xfe85; evenq=0xfdcf; 0: Chn 2 oddi=0x; eveni=0x; oddq=0x; evenq=0x; Starting ADC DC Offset Cal for Chain 0 pwr_meas_odd_i = 87 pwr_meas_even_i = 134 pwr_meas_odd_q = 797 pwr_meas_even_q = 442 dc_offset_mismatch_i = 0x dc_offset_mismatch_q = 0x0005 ADC DC Offset Cal done for Chain 0 Starting ADC DC Offset Cal for Chain 1 pwr_meas_odd_i = 607 pwr_meas_even_i = 725 pwr_meas_odd_q = -379 pwr_meas_even_q = -561 dc_offset_mismatch_i = 0x0001 dc_offset_mismatch_q = 0x0002 ADC DC Offset Cal done for Chain 1 >How-To-Repeat: . just run it as a hostap? >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/163082: [ath] ar9285 diversity fixes
>Number: 163082 >Category: misc >Synopsis: [ath] ar9285 diversity fixes >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Dec 05 16:00:27 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release:-HEAD >Organization: >Environment: n/a >Description: AR9285 diversity needs to be tidied up: >How-To-Repeat: >Fix: TODO List: * RX diversity should not be controlled by "txantenna". Add an "RX diversity" knob that uses a HAL call, rather than overriding the TX antenna switch code. * Modify the combined diversity stuff to only be enabled when STA mode is enabled. It won't work for modes where multiple nodes are being listened to. * .. perhaps disable it when channel scanning? * And then add a HAL config bit to allow "combining" diversity to be enabled, and leave it disabled by default. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/163573: [ath] hostap mode TX buffer hang
>Number: 163573 >Category: kern >Synopsis: [ath] hostap mode TX buffer hang >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Dec 23 19:20:07 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release:FreeBSD-10.0, on a TP-WR1043ND router. >Organization: FreeBSD >Environment: FreeBSD home-11bg-ap 10.0-CURRENT FreeBSD 10.0-CURRENT #39: Thu Jan 1 08:00:00 WST 1970 adrian@dummy:/home/adrian/work/freebsd/git/adrianchadd-freebsd-work/obj/mipseb/mips.mipseb/home/adrian/work/freebsd/git/adrianchadd-freebsd-work/adrianchadd-freebsd-work/sys/TP-WN1043ND mips . it's a recent -HEAD (to this date stamp), from my git tree. Ignore the actual datestamp there. >Description: When testing 802.11n hostap mode, the TX side still occasionally hangs. This is again due to the "busy" buffer management code being slightly wrong, allowing a "busy" buffer to stay busy and eventually clogging up the free TX buffer ring. This occurs with IEEE80211_SUPPORT_TDMA, as the busy buffer code isn't included otherwise. (It should be though, due to how the MAC behaves. But that's a different problem.) The relevant output from "sysctl dev.ath.0.txagg=1" is: HW TXQ 0: axq_depth=2, axq_aggr_depth=2 HW TXQ 1: axq_depth=0, axq_aggr_depth=0 HW TXQ 2: axq_depth=0, axq_aggr_depth=0 HW TXQ 3: axq_depth=0, axq_aggr_depth=0 HW TXQ 8: axq_depth=0, axq_aggr_depth=0 Busy: 0 Total TX buffers: 1; Total TX buffers busy: 1 . the fact that there's only 1 total buffer in the free list, and that one is busy, indicates that things were going pear shaped. Also, athstats can be helpful: # athstats | grep tx .. 294 tx stopped 'cuz no xmit buffer .. >How-To-Repeat: Just exchange a bunch of traffic whilst in a lossy 802.11 network. It should eventually get angry and stop transmitting. ifconfig wlan0 down / up will flush the TX buffer queue. Enable both 802.11 and TDMA in the kernel configuration file (ATH_ENABLE_11N and IEEE80211_SUPPORT_TDMA.) Configure the unit as a hostap - in non-hostap mode, the interface resets will cause the TX buffer queue to be flushed. Sit back and watch the fireworks. >Fix: Not yet. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/163574: [net80211] overly-frequent HT occupancy changes
>Number: 163574 >Category: misc >Synopsis: [net80211] overly-frequent HT occupancy changes >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Dec 23 19:40:11 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release:FreeBSD-10.0, on a TP-WR1043ND router. >Organization: FreeBSD >Environment: FreeBSD home-11bg-ap 10.0-CURRENT FreeBSD 10.0-CURRENT #39: Thu Jan 1 08:00:00 WST 1970 adrian@dummy:/home/adrian/work/freebsd/git/adrianchadd-freebsd-work/obj/mipseb/mips.mipseb/home/adrian/work/freebsd/git/adrianchadd-freebsd-work/adrianchadd-freebsd-work/sys/TP-WN1043ND mips >Description: When running this tplink in occupied 2.4GHz space, the AP instance frequently bounces between these states: wlan0: [00:19:e0:66:66:68] HT bss occupancy change: 2 sta, 2 ht, 1 ht40, non-HT sta present, HT protmode now 0x13 wlan0: [00:19:e0:66:66:68] HT bss occupancy change: 2 sta, 2 ht, 1 ht40, non-HT sta present, HT protmode now 0x11 wlan0: [00:19:e0:66:66:68] HT bss occupancy change: 2 sta, 2 ht, 1 ht40, non-HT sta present, HT protmode now 0x13 wlan0: [00:19:e0:66:66:68] HT bss occupancy change: 2 sta, 2 ht, 1 ht40, non-HT sta present, HT protmode now 0x11 wlan0: [00:19:e0:66:66:68] HT bss occupancy change: 2 sta, 2 ht, 1 ht40, non-HT sta present, HT protmode now 0x13 wlan0: [00:19:e0:66:66:68] HT bss occupancy change: 2 sta, 2 ht, 1 ht40, non-HT sta present, HT protmode now 0x11 wlan0: [00:19:e0:66:66:68] HT bss occupancy change: 2 sta, 2 ht, 1 ht40, non-HT sta present, HT protmode now 0x13 . I'm not sure whether it's a problem but it is occuring very very frequently and this may be interfering with station operation. >How-To-Repeat: * enable 11n * throw the AP into a busy 2.4ghz environment with non-11n stuff around you * wlandebug +11n >Fix: Not known. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/163689: [ath] TX timeouts when sending probe/mgmt frames during scanning
>Number: 163689 >Category: misc >Synopsis: [ath] TX timeouts when sending probe/mgmt frames during >scanning >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Dec 29 01:10:12 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release:10.0-CURRENT >Organization: >Environment: 10.0-CURRENT, i386, etc. >Description: When aggregation is enabled, frames that are queued to the software queue require a call to ath_txq_sched() in order to schedule them to the hardware. This is currently done by implication - to clarify, the only times frames are queued to the software queue is if the hardware queue is currently busy or paused. If this isn't the case, the frames are directly dispatched to the hardware. ath_txq_sched() is then called by the TXQ completion code in ath_tx_processq(). Unfortunately, during channel scanning, some frames make it to the software queue with no subsequent frames in the hardware queue. This means that ath_tx_processq() never occurs and thus ath_txq_sched() never occurs. This results in TX timeouts, along with: TODS 00:03:7f:0b:62:88->00:19:e0:66:66:68(00:19:e0:66:66:68) data QoS [TID 0] 0M c819 3a01 0019 e066 6668 0003 7f0b 6288 0019 e066 6668 1009 adde ath1: ath_tx_tid_drain: node 0xc77a2000: tid 0: txq_depth=0, txq_aggr_depth=0, sched=1, paused=0, hwq_depth=0, incomp=0, baw_head=77, baw_tail=77 txa_start=1740, ni_txseqs=1740 TODS 00:03:7f:0b:62:88->00:19:e0:66:66:68(00:19:e0:66:66:68) data QoS [TID 0] 0M c819 3a01 0019 e066 6668 0003 7f0b 6288 0019 e066 6668 c00a adde ar5416PerCalibrationN: NF calibration didn't finish; delaying CCA ath1: ath_tx_tid_drain: node 0xc77a2000: tid 0: txq_depth=0, txq_aggr_depth=0, sched=1, paused=0, hwq_depth=0, incomp=0, baw_head=100, baw_tail=100 txa_start=1763, ni_txseqs=1763 TODS 00:03:7f:0b:62:88->00:19:e0:66:66:68(00:19:e0:66:66:68) data QoS [TID 0] 0M c819 3a01 0019 e066 6668 0003 7f0b 6288 0019 e066 6668 600c adde ath1: ath_tx_tid_drain: node 0xc77a2000: tid 0: txq_depth=0, txq_aggr_depth=0, sched=1, paused=0, hwq_depth=0, incomp=0, baw_head=85, baw_tail=85 txa_start=1876, ni_txseqs=1876 TODS 00:03:7f:0b:62:88->00:19:e0:66:66:68(00:19:e0:66:66:68) data QoS [TID 0] 0M c819 3a01 0019 e066 6668 0003 7f0b 6288 0019 e066 6668 c017 adde ath1: ath_tx_tid_drain: node 0xc77a2000: tid 0: txq_depth=0, txq_aggr_depth=0, sched=1, paused=0, hwq_depth=0, incomp=0, baw_head=85, baw_tail=85 txa_start=1876, ni_txseqs=1876 TODS 00:03:7f:0b:62:88->00:19:e0:66:66:68(00:19:e0:66:66:68) data QoS [TID 0] 0M c819 3a01 0019 e066 6668 0003 7f0b 6288 0019 e066 6668 e01a adde ath1: ath_tx_tid_drain: node 0xc77a2000: tid 0: txq_depth=0, txq_aggr_depth=0, sched=1, paused=0, hwq_depth=0, incomp=0, baw_head=85, baw_tail=85 txa_start=1876, ni_txseqs=1876 TODS 00:03:7f:0b:62:88->00:19:e0:66:66:68(00:19:e0:66:66:68) data QoS [TID 0] 0M c819 3a01 0019 e066 6668 0003 7f0b 6288 0019 e066 6668 001e adde ath1: ath_tx_tid_drain: node 0xc77a2000: tid 0: txq_depth=0, txq_aggr_depth=0, sched=1, paused=0, hwq_depth=0, incomp=0, baw_head=7, baw_tail=7 txa_start=1926, ni_txseqs=1926 TODS 00:03:7f:0b:62:88->00:19:e0:66:66:68(00:19:e0:66:66:68) data QoS [TID 0] 0M c819 3a01 0019 e066 6668 0003 7f0b 6288 0019 e066 6668 4021 adde . this only reliably occurs once aggregation is established. >How-To-Repeat: * Associate to an 11n enabled access point * Pass some TX traffic to ensure that aggregation is established (wlandebug +11n first, so you get told of this.) * Then start a ping on the station, whilst running "ifconfig wlanX scan" * see it log these errors. >Fix: It's a little more complicated than it needs to be. The above situation is purely the data frames from ping. The trouble is that it's also probe frames, and anything else that's low traffic. I've seen it also with probe frames, with extremely busy/crowded air. This is just the easiest way to reliably trigger it. It's fixed if ath_txq_sched() is called appropriately, but there's no appropriate, non-hackish way to call it at the present moment. It needs the txq in question and that currently isn't available in ath_start() or ath_raw_xmit(). Furthermore, right now the only place it gets called is via the taskqueue and that happens once per ath_tx_processq() call, so we don't have to worry about it running in parallel. To solve this, we may not be able to easily get away with that assumption. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/164382: [ath] crash when down/deleting a vap - inside ieee80211_input_mimo_all()
>Number: 164382 >Category: misc >Synopsis: [ath] crash when down/deleting a vap - inside >ieee80211_input_mimo_all() >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Jan 22 19:50:10 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release:9.0-RC2, with -HEAD ath/net80211 >Organization: FreeBSD >Environment: FreeBSD marilyn 9.0-RC3-p1 FreeBSD 9.0-RC3-p1 #4: Sat Jan 21 20:56:40 PST 2012 root@marilyn:/usr/src/sys/i386/compile/MARILYN i386 >Description: I saw a crash inside the net80211 stack when either deleting or down'ing a vap. Unread portion of the kernel message buffer: KDB: stack backtrace: #0 0xc0727697 at kdb_backtrace+0x47 #1 0xc073b675 at _witness_debugger+0x25 #2 0xc073cb8e at witness_warn+0x1fe #3 0xc095e465 at trap+0x195 #4 0xc09478ac at calltrap+0x6 #5 0xc77e2bf1 at ieee80211_free_node_debug+0xb1 #6 0xc77ce017 at ieee80211_input_mimo_all+0xe7 #7 0xc77cdf22 at ieee80211_input_all+0x32 #8 0xc784dcc5 at ath_rx_proc+0xc45 #9 0xc784d071 at ath_rx_tasklet+0x101 #10 0xc073446b at taskqueue_run_locked+0xeb #11 0xc0734ec7 at taskqueue_thread_loop+0x67 #12 0xc06c76b8 at fork_exit+0xb8 #13 0xc0947924 at fork_trampoline+0x8 The debugging indicated something rather amusing at this point. ath0: ath_node_alloc: an 0xc7adf000 ieee80211_ref_node: 0xc7adf000: ieee80211_reset_bss /usr/home/adrian/work/freebsd/ath/head/src/sys/modules/wl an/../../net80211/ieee80211_node.c:434 wlan0: Ethernet address: 00:03:7f:11:a3:f3 ath0: ath_init: if_flags 0x8803 ath0: ath_stop_locked: invalid 0 if_flags 0x8803 ath0: ath_newstate: INIT -> INIT ath0: ath_newstate: RX filter 0x6497 bssid 00:00:00:00:00:00 aid 0x0 ath0: ath_newstate: INIT -> SCAN ath0: ath_newstate: RX filter 0x6497 bssid 00:00:00:00:00:00 aid 0x0 ath0: ath_node_alloc: an 0xc7aea000 . now at this point, there are two sets of messages which overlap, indicating that they ran concurrently: ieee80211_ref_node: 0xc7aea000: ieee80211_create_ibss /usr/home/adrian/work/freebsd/ath/head/src/sys/modules/ wlan/../../net802 ieee80211_ref_node: 0xc7adf000: ieee80211_input_mimo_all /usr/home/adrian/work/freebsd/ath/head/src/sys/modul es/wlan/../../net 11/ieee80211_node.c:412 80211/ieee80211_input.c:143 ath0: ath_node_free: ni 0xc7adf000 . and bang: Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex ath0_node_lock (ath0_node_lock) r = 0 (0xc79316c0) locked @ /usr/home/adrian/work/freeb sd/ath/head/src/sys/modules/wlan/../../net80211/ieee80211_node.c:1702 I'm gathering here that the delete was ongoing whilst traffic was being processed via ath_rx_tasklet() and the underlying vap was either deleted or the vap->iv_bss node was changed. There seems to be a larger class of bugs where the vap->iv_bss node is changed in parallel with some other process (eg beacon free/alloc) without suitable locking. >How-To-Repeat: It's difficult to reproduce. I reproduced it in a lab environment with lots of busy air. I guess anything that triggers constant incoming traffic and keeps the RX queue deep is going to make triggering this bug. What needs to happen: * ath_rx_tasklet() needs to take a while to run; * the ifconfig process (and net80211 taskqueue) needs to be scheduled on another CPU, so it can run _in parallel_ with the ath taskqueue (which ath_rx_tasklet() runs in) * somehow you have to get a vap down/delete in during this RX. >Fix: I think the RX path should be properly aborted during a a vap down/delete. This doesn't just mean stopping the hardware (which is what ath_stop_locked() currently does) but also waiting for the ath_rx_tasklet() and the TX completion tasklet to complete. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/165021: [ath] ath device timeout during scan/attach, if wlan_ccmp/wlan_tkip isn't loaded
>Number: 165021 >Category: misc >Synopsis: [ath] ath device timeout during scan/attach, if >wlan_ccmp/wlan_tkip isn't loaded >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Feb 12 03:00:25 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release:9.0-RELEASE >Organization: >Environment: 9.0-RELEASE i386, but with -HEAD net80211/ath driver. >Description: If wlan_tkip/wlan_ccmp aren't loaded but are required by the hostap, the station mode code will: * attempt to associate * succeed * mark wlanX as UP * note that the required encryption type is not active * mark wlanX as DOWN . then 5 seconds later, "ath0: device timeout" shows up. >How-To-Repeat: * compile ath/net80211 as modules * load wlan and ath/ath_pci - but don't load wlan_wep/wlan_tkip/wlan_ccmp * attempt to associate to a network which requires encryption >Fix: After enabling debugging, I discovered this sequence of events: * a frame was being queued to the hardware - in this instance, a DISCONNECT frame; * the state would then transition to DOWN; * the IER was disabled - ie, HAL_INT_GLOBAL was cleared and something called ath_hal_intrset(); so the interrupt wouldn't occur; * the watchdog timer would kick in and call ath_reset(); * there'd be at least one completed frame in the TX queue, status OK - so it did go out. The actual cause seems to be that the state transition is going from RUN -> INIT, and this is causing interrupts to be disabled. ath_newstate() is causing a state transition to INIT, which disables interrupts and blocks the ath taskqueue. Trouble is, this doesn't stop/flush any of the currently pending hardware TX and this is what's eventually causing the watchdog timeout - although the hardware has completed the TX, the driver has disabled all methods of actually being notified about it. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/165060: [ath] vap->iv_bss race conditions causing crashes inside ath_beacon_alloc and similar
>Number: 165060 >Category: misc >Synopsis: [ath] vap->iv_bss race conditions causing crashes inside >ath_beacon_alloc and similar >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Feb 12 23:40:05 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release:9.0-RELEASE, running -HEAD ath/net80211 >Organization: >Environment: >Description: There are a variety of crashes inside the ath driver which can be traced down to races between iv->iv_bss modify/reallocate/free. >From an email I sent to freebsd-wireless: I've noticed some kernel panics in net80211/ath in -HEAD. It in all instances boils down to a now-invalid ieee80211_node - either it's partially allocated/copied, or it's been recently freed. This became increasingly obvious when doing DFS CAC, as the kernel was now changing the channel quite frequently on me whilst simulating/processing radar events. I've since found I can mostly reproduce it in the lab (when surrounded by ridiculous levels of RX intereference traffic, triggering all kinds of events) whilst creating/destroying VAPs. Now that I have debugging code in place (which as a side effect makes it very difficult now to cause a crash, let alone tickle the race condition) it's glaringly obvious what's going on. There's five contexts stuff can occur, at least in the net80211/ath case: * the swi (ie ath_intr(), ath_beacon_proc) * the ath taskqueue; * the net80211 taskqueue; * the ioctl() context, coming up from a userland process; * a callout running in the clock thread. Now, callouts should _hopefully_ be grabbing and releasing locks correctly. We've found a few spots where they weren't (leading to quite silly state races and crashes.) I'm going to ignore the obvious possible problems with multiple concurrent processes doing ioctl()s. l'm simply going to operate on the principle that the multiple-ioctl() path is fine. It seems that -obtaining- references to vap->iv_bss aren't locked. So in (say) ieee80211_sta_join1() the iv_bss node can be dereferenced and freed. If this is going on concurrently with (say) something going on in the net80211 taskqueue (eg a newstate call) then I _think_ it's possible for the ath_newstate() code to get a reference to vap->iv_bss simultaneously with it being freed in ieee80211_sta_join1() (or similar.) So the ath_newstate() code will be assigned a 'ni' that has just been freed. I've seen another crash in the net80211_ht code where it _looks_ like the bss node wasn't entirely setup - bsschan was 0x - so the kernel paniced hard there. This likely explains a lot of the "weird stuff" people have been reporting. I also think the bgscan race is related to this - I can't help but wonder if the bgscan callout/event is also coinciding with wpa_supplicant doing stuff, and a race condition ends up leaving the vap w/ the sta power save flag set. I don't yet have a solution to all of this - I just wanted to brain dump what I've seen thus far. >How-To-Repeat: It's unfortunately not easy to reproduce in a clean environment. It seemed very easy to reproduce in a radio-noisy environment where the RX handler is constantly being scheduled. >Fix: Someone pointed this out: Here is my brain dump. While ago usb wifi drivers had the slimier issue (race in 80211 stack). It's worth checking this rev. http://svnweb.freebsd.org/base?view=revision&revision=212127 >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/165220: [ath] "ath_rx_tasklet: sc_inreset_cnt > 0; skipping" messages
>Number: 165220 >Category: kern >Synopsis: [ath] "ath_rx_tasklet: sc_inreset_cnt > 0; skipping" messages >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Feb 17 03:00:21 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release:9.0-RELEASE i386, with -HEAD net80211/ath >Organization: >Environment: >Description: There are far too many of the following messages showing up: [100191] ath0: ath_rx_tasklet: sc_inreset_cnt > 0; skipping [100191] ath0: ath_rx_tasklet: sc_inreset_cnt > 0; skipping [100191] ath0: ath_rx_tasklet: sc_inreset_cnt > 0; skipping [100191] ath0: ath_rx_tasklet: sc_inreset_cnt > 0; skipping [100191] ath0: ath_start: sc_inreset_cnt > 0; bailing [100191] ath0: ath_rx_tasklet: sc_inreset_cnt > 0; skipping [100191] ath0: ath_rx_tasklet: sc_inreset_cnt > 0; skipping [100191] ath0: ath_rx_tasklet: sc_inreset_cnt > 0; skipping . What's happening is that a bunch of TX or RX completion is occuring at the same time as a channel change/reset. The previous code just had these run concurrently, causing all kinds of random and weird behaviour. I introduced some debugging in FreeBSD-HEAD that tries to (a) stop these and (b) log when they occur, so I could actually try finding/figuring out what's going on. This is one of these cases. :-) >How-To-Repeat: Just run ath :-) >Fix: The problem is that although interrupts are disabled in reset, the ath taskqueue may currently be running and this means existing TX completion and RX will occur. I think the fix is to do this: * grab the PCU lock * disable interrupts * grab the reset counter * stop the ath taskqueue and wait for pending tasks to complete . but is this still racy? A patch I've done to do the above in ath_reset() and ath_chan_change() reduces the instances of this quite heavily but it still occasionally turns up. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/165306: [ath] race conditions between scanning and beacon timeout programming
>Number: 165306 >Category: kern >Synopsis: [ath] race conditions between scanning and beacon timeout >programming >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Feb 20 02:40:09 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release:9.0-RELEASE i386 w/ HEAD net80211/ath >Organization: >Environment: >Description: There seem to be issues where net80211 doesn't quite get the "beacon miss" notification. It stays associated, the beacon interrupt/notification isn't occuring. Adding on reset/beacon debugging (0x20 + 0x80) on ath0 (sysctl dev.ath.0.debug=0xa0) didn't show any beacon miss interrupts, software or hardware. This is with one VAP STA on an AR9280. What I think is happening is: * the transition to -> RUN doesn't program in any beacon timers by default - it waits for the first beacon to be RX'ed before it programs in timers; * but if it loses connectivity during a scan, the beacon timers won't ever be reprogrammed, as no beacons will occur. So it stays associated. >How-To-Repeat: The above should be doable to reproduce - just enable beacon debugging, then do a scan and kill the AP whilst the station is scanning. >Fix: It may be that we need to: * program in some beacon TSF value for the initial state transition to RUN, and hope that a new beacon will come in and reprogram the timers. * .. or also enable swbeacon support too for single-VAP STA mode? >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/165382: [kern] taskqueue_unblock doesn't unblock currently queued tasks
>Number: 165382 >Category: misc >Synopsis: [kern] taskqueue_unblock doesn't unblock currently queued tasks >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Feb 22 02:00:24 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release:9.0-RELEASE >Organization: >Environment: >Description: This is more a note than a bug. taskqueue_block() only marks newly queued items as PENDING. If a task is queued to the taskqueue to be run, taskqueue_block() doesn't stop that from occuring. For example, take a single-thread taskqueue: * task A is queued - wakeup_one() is called * task B is queued - wakeup_one() is called * task A starts to run * taskqueue_block() is called from another thread * task C is queued - but instead is marked as PENDING * task A completes * task B completes * task C waits for taskqueue_unblock() to occur. This means that code which calls taskqueue_block() can't assume that once currently running tasks are completed, nothing further will be done. It can only assume that once currently QUEUED tasks are completed, nothing further will be queued. These two are subtly different. >How-To-Repeat: N/A >Fix: N/A >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/165475: [ath] operational mode change doesn't poke the underlying rate control module hard enough
>Number: 165475 >Category: misc >Synopsis: [ath] operational mode change doesn't poke the underlying rate >control module hard enough >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Feb 25 19:50:11 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release:9.0-RELEASE, w/ -HEAD net80211/ath >Organization: >Environment: >Description: This reared its ugly head when testing with an AR5211 (11b/11a, no 11g.) Specifically: * the operational mode change has occured (sc->sc_currates is pointing to the 11b table); * ath_sample_node->ratemask is 0xff for some reason - likely indicating it was assembled from the 11a rate able (which in ath_hal/ar5211/ar5211_phy.c has 8 11a rates in it); * so ath_rate_findrate() thinks best_rix is fine and the current rate table mapping is fine. This is likely very similar to other issues with rate control in ath being slightly weird after an operational mode change, if the NIC hasn't transitioned back into the original operating mode. The rate control code isn't informed of this (it only gets told of association/reassociation, and ath_rate_sample is only updating the rate table on _new_ associations) so it doesn't realise it has to rethink its current rate table setup. >How-To-Repeat: Setup: * net80211/ath and kernel built with full debugging, assert, witness, etc * associated to an 11a AP (so it has the 11a OFDM table) * running iperf * the session hangs for some reason, I'm not quite sure yet * .. then the bgscan code kicks in and starts scanning * .. and for some reason, the NIC is in 11b mode now, and tries TX'ing * But the "best rix" in ath_rate_findrate (in ath_rate_sample) is referencing an 11a rate, not an 11b rate - ie, rix > the current greatest rix in the config. * .. so things panic. >Fix: I'm not yet sure. Because of background scanning, it's entirely possible the NIC will spend a non-zero amount of time off channel, TX'ing things which SHOULD have fixed rates. The ath_rate module code isn't currently informed about channel changes, as the channel change doesn't inform all associated nodes of this fact. Any rate control lookups during off-channel times will cause things to be confused. I should first check whether this crash occured with the NIC being in off-channel mode. If so, it shouldn't have tried TXing a data frame at this point. No, i just checked - ni->ni_vap->iv_flags is 0x430c4010 - and 0x80 is IEEE80211_F_SCAN; 0x100 is IEEE80211_F_ASCAN. So first let's see if _why_ the NIC is in 11b mode can be made obvious. Then, once that's done, figure out why the transition didn't trigger a rate control update. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/165517: [net80211] bgscan isn't triggered when invalid beacons are being sent
>Number: 165517 >Category: kern >Synopsis: [net80211] bgscan isn't triggered when invalid beacons are >being sent >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Feb 28 02:40:07 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release:-CURRENT >Organization: >Environment: 9.0-RELEASE with HEAD net80211/ath >Description: I was trying to figure out why bgscan isn't working in some instances. What's happening is this: * the bgscan is triggered via sta_recv_mgmt(), on a valid beacon frame * but if the beacon frame isn't valid, it fails an earlier check, so the ieee80211_bg_scan() call is never made. >How-To-Repeat: Find an AP whose beacons fail the check. >Fix: * Fix ieee80211_parse_beacon() if it needs to be fixed * potentially ignore the beacon contents _but_ still trigger a background scan if possible. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/165642: kde4: keeps locking the screen.
>Number: 165642 >Category: misc >Synopsis: kde4: keeps locking the screen. >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Mar 03 00:10:06 UTC 2012 >Closed-Date: >Last-Modified: >Originator: adrian chadd >Release:FreeBSD-9.0 RELEASE >Organization: >Environment: >Description: I'm running this on both a Thinkpad T60 and T40. In both instances, I've installed kde4 via pkg_add -vr (so binary packages) after installing 9.0-RELEASE. The screen "locks" (as in asks for a password) very frequently. It's easily triggerable by using the function key. But i've seen it do it at odd moments too. I'll then be greeted by a large spam of notifications about power saving. (This is with AC plugged in.) I'd like to assist in debugging why this is occuring but I have no idea where to begin. :) >How-To-Repeat: Hit "fn" on said thinkpad models. >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/165866: [ath] TX hangs, requiring a "scan" to properly reset the interface
>Number: 165866
>Category: kern
>Synopsis: [ath] TX hangs, requiring a "scan" to properly reset the
>interface
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Thu Mar 08 23:40:10 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Adrian Chadd
>Release:FreeBSD-HEAD
>Organization:
>Environment:
FreeBSD home-11bg-ap 10.0-CURRENT FreeBSD 10.0-CURRENT #18 r232400:232625M: Wed
Dec 31 16:00:00 PST 1969
adrian@dummy:/home/adrian/work/freebsd/svn/obj/mipseb/mips.mipseb/usr/home/adrian/work/freebsd/svn/src/sys/TP-WN1043ND
mips
>Description:
I've been seeing TX hangs during my tests.
Investigating showed that the TX queue would grow and busy buffers would stay
busy.
Eg, from sysctl dev.ath.0.txagg=1:
HW TXQ 0: axq_depth=0, axq_aggr_depth=0
HW TXQ 1: axq_depth=184, axq_aggr_depth=0
HW TXQ 2: axq_depth=0, axq_aggr_depth=0
HW TXQ 3: axq_depth=0, axq_aggr_depth=0
HW TXQ 8: axq_depth=1, axq_aggr_depth=0
Busy: 14
Total TX buffers: 15; Total TX buffers busy: 1
This occured even with a completely idle access point that only responded to
probe requests - ie, no active associations.
the only way to flush things was a 'scan' - this forcibly flushes the TX queue
and pending frames are either handled or deleted.
I then flipped on reset debugging (sysctl dev.ath.0.debug=0x20) and forced a
scan whenever I saw this occur.
I also dumped the relevant registers when this occured. I found that the TXDP
for this queue was completely in the wrong place.
I also found that the TX descriptor list made no sense - there were incomplete
and complete descriptor lists in the same TX queue, as well as NULL link
pointers half way through the list.
So, I figured something is splicing the list together incorrectly.
>How-To-Repeat:
This kernel was compiled with TDMA support, so the ATH_BUF_BUSY flag would be
set.
* set it up on a 2.4GHz channel;
* make sure there's lots of STAs and APs around;
* notice the high level of probe request traffic;
* .. wait.
>Fix:
This particular patch seems to quieten down the issues. I'm going to run this a
bit more and see what happens.
Index: if_ath_tx.c
===
--- if_ath_tx.c (revision 232400)
+++ if_ath_tx.c (working copy)
@@ -623,19 +623,22 @@
ath_txq_restart_dma(struct ath_softc *sc, struct ath_txq *txq)
{
struct ath_hal *ah = sc->sc_ah;
- struct ath_buf *bf;
+ struct ath_buf *bf, *bf_last;
ATH_TXQ_LOCK_ASSERT(txq);
/* This is always going to be cleared, empty or not */
txq->axq_flags &= ~ATH_TXQ_PUTPENDING;
+ /* XXX make this ATH_TXQ_FIRST */
bf = TAILQ_FIRST(&txq->axq_q);
+ bf_last = ATH_TXQ_LAST(txq, axq_q_s);
+
if (bf == NULL)
return;
ath_hal_puttxbuf(ah, txq->axq_qnum, bf->bf_daddr);
- txq->axq_link = &bf->bf_lastds->ds_link;
+ txq->axq_link = &bf_last->bf_lastds->ds_link;
ath_hal_txstart(ah, txq->axq_qnum);
}
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/165895: [ath] overly busy cabq can tie up all tx buffers
>Number: 165895 >Category: kern >Synopsis: [ath] overly busy cabq can tie up all tx buffers >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Mar 10 01:50:01 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release:FreeBSD-HEAD >Organization: >Environment: -MIPS, AR9130 AP (TP-WR1043nd) >Description: In a congested air environment with a very busy broadcast traffic LAN (in my instance, a _lot_ of IPv4 ARP and IPv6 ND frames) the CABQ can fill up with traffic and tie up all the tx buffers. This stops things such as management traffic (ie, probe response/authentication frames) from successfully transmitting. >How-To-Repeat: * AR9130 AP * _VERY_ busy 2.4GHz environment * configure in HT/40 mode * inject a lot of broadcast traffic sysctl dev.ath.0.txagg will show the CABQ (queue 8) will be constantly filled with traffic. >Fix: In the short term, we should just limit the amount of data going into the multicast queue. This includes power save traffic, so we need to be careful. In the longer term, when we decouple ath_buf TX from actual software TX queues, we may wish to buffer some frames in the avp->av_mcastq before we assign them a hardware TX ath_buf + descriptor. We still will have a problem with traffic filling up. There may be a radio configuration issue causing it to think the air is overly congested. I'll investigate that in a separate PR. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/165951: [ath] [ar913x] DDR flush isn't being done for the WMAC
>Number: 165951 >Category: kern >Synopsis: [ath] [ar913x] DDR flush isn't being done for the WMAC >Confidential: no >Severity: non-critical >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Mar 11 22:20:09 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Adrian Chadd >Release:-HEAD >Organization: >Environment: MIPS, AR913x AP >Description: The AR913x WMAC sits off the Atheros Host Bus (AHB), along with the usb, gmac, etc. The APB (peripheral bus) contains the UART, etc and is a part of the AHB. Trouble is, the AHB code in -HEAD includes the USB because the USB IRQ sits inside the APB MISC interrupt status word. The other peripherals (GMAC0, GMAC1, WMAC/PCI, etc) are primary MIPS IRQs. So the AHB devices (besides USB) sit off the nexus, rather than off the AHB. There's no AHB glue, per se, and thus there's no convenient place to put the WMAC DDR flush. For the AR713x/AR71xx there's a PCIe/PCI bus nexus and the IP2 flush is done there. >How-To-Repeat: >Fix: I'm not sure yet. I think the right thing to do is: * create the AHB bus; * have the IRQ handling done inside AHB - mapping the MISC interrupts to say IRQ 15 - 31; * Create APB; * Have the APB peripherals now use the MISC interrupts that are between AHB IRQs 15->31; * Have USB also use the relevant MISC interrupt that's between 15 and 31; * The APB interrupt code would just punt to the AHB. >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
