Re: [RFT] net80211 TX serialisation, take #4
Here we go: http://people.freebsd.org/~adrian/ath/20130225-net80211-txlock.diff See what you think. Adrian ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Current problem reports assigned to freebsd-wireless@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o kern/176238 wireless [ath] [patch] Correct buffer size calculation and simp o kern/176201 wireless [net80211] [patch] 11n station includes unrelated ht p o kern/176104 wireless [iwn] iwn0: iwn_intr: fatal firmware error o kern/175870 wireless [iwn] /etc/rc.d/netif restart cause system crash o kern/175722 wireless [ath]lot of bad seriesx hwrate in kernel messages o kern/175446 wireless [ath] high volumes of PHY errors lead to BB/MAC hangs o kern/175227 wireless [ath] beacon timers aren't necessarily reprogrammed af o kern/175183 wireless [iwn] iwn(4) becomes unresponsive during initial confi o kern/175053 wireless [iwn] iwn firmware error on 9-stable with Ultimate-N 6 o kern/174891 wireless [ieee80211] struct ieee80211_node is freed during acti o kern/174722 wireless [wlan] can't use channel 12 and 13 (14) with my wifi i o kern/174661 wireless [wlan] lost alias on wlan interface o kern/174283 wireless [net80211] panics in ieee80211_ff_age() and ieee80211_ o kern/174276 wireless [ath] if_ath memory modified after free o kern/174273 wireless [net80211] taking down a net80211 node with active fas o kern/173917 wireless [iwn] wpa-supplicant issues on iwn o kern/173898 wireless [iwn] [patch] iwn(4) DOES support 6235 chip. o kern/173883 wireless [ath] ath0: unable to attach - pci issue? o kern/173711 wireless [ath] powerd kills ath on the Asus EeePC 1005HA o kern/173342 wireless PS-Poll isn't working o kern/173336 wireless [ath] Atheros card improper device poweroff handling o o kern/172955 wireless [ath] 11n does not work in adhoc mode o kern/172706 wireless [wpi] wpi0 fails to load firmware when using country o kern/172672 wireless [ubt] Bluetooth device recognised but not working o kern/172661 wireless hostapd(8) securing wireless adapter in HostAP mode is o kern/172338 wireless [ath] [net80211] CCMP IV transmit counters are not cor o kern/171598 wireless [ath] TP-Link TL-WN951N W-LAN PCI Adapter 300 MBit stu o kern/171235 wireless [ath] ath loses connection, system freezes on netif re o kern/170889 wireless [ath] ath driver uses some uninitilized memory o kern/170620 wireless [ath] LOR and deadlock when multiple vaps are used o kern/170573 wireless [iwi] Intel 2200BG iwi NIC hangs with need multicast c o kern/170513 wireless [ath] ath logs: ath_tx_aggr_comp_aggr: AR5416 bug: o kern/170433 wireless [ath] TX hang after a stuck beacon message with active o kern/170397 wireless [ath] [patch] Uninitialized variables in ah_eeprom_928 o kern/170302 wireless [ath] 802.11n frames are not being transmitted with mu o kern/170281 wireless [ath] 802.11n locks up on aggregation setup (ampdutx) o kern/170098 wireless [ath] [net80211] VAPs (Virtual access points) with Ath o kern/170066 wireless [ral] ral(4) rt61pci Linksys freezes the machine as so o kern/169432 wireless [ath] BAR TX hang when aggregation session is reset du p kern/169362 wireless [ath] AR5416: radar pulse PHY errors sometimes include o kern/169336 wireless [ath] ANI isn't triggering in a busy/noisy environment o kern/169199 wireless [ath] Cannot set up static ip addresses for wireless w o kern/169084 wireless [ath] suspend/resume doesn't cause a rescan; the assoc o kern/168530 wireless [ath] Broken WEP probably o kern/168393 wireless AR9285: suspend/resume sometimes fails o kern/168170 wireless [net80211] ieee80211_send_bar() doesn't complete corre o kern/167870 wireless [ath] adhoc wifi client does not join an existing IBSS o kern/167834 wireless [ath] kickpcu; 'handled 0 packets' o kern/167828 wireless [iwn] iwn(4) doesn't recover automatically after firmw o kern/167798 wireless ifconfig(8): problem with ifconfig list scan command o kern/167491 wireless [ath] TID != hardware queue TID in ath_tx_aggr_comp_ag o kern/167113 wireless [ath] AR5210: stuck TX seems to be occuring, without o kern/167080 wireless [ath] channel switch on another VAP break channel setu o kern/166684 wireless [ath] [net80211] mgmtrate/mcastrate isn't updated base p kern/166642 wireless [ieee80211] [patch] in 802.11n mode for FreeBSD AP, ha o kern/166641 wireless [ieee80211] [patch] mbuf/cluster leak in AP mode in 80 p kern/166357 wireless [ath] 802.11n TX stall when the first frame in the BAW o kern/166286 wireless [net80211] [ath] initial switch to HT40 isn't causing p kern/166190 wireless [ath] TX hangs and frames stuck in TX queue o kern/166086 wireless [Patch][ath] Reflect state of rfkill switch in
Re: [RFT] net80211 TX serialisation, take #4
On Mon, Feb 25, 2013 at 12:27 AM, Adrian Chadd adr...@freebsd.org wrote:
The trouble with using a queue is that things will dequeue frames out
of order, bceause multiple dequeue contexts (ie, each call to
driver_start / driver_transmit) will execute in-parallel.
Actually, to prevent that, there is an extra queue.
To begin
driver_queue:packet1--packet2--3--4--...
working_queue:empty
hadware_queue:empty
After multiple thread dequeue
lock dequeue enqueue unlock
lock dequeue enqueue unlock
They look like,
driver_queue:2--3--4--...
working_queue:1--2 (the lock preserves the order)
hardware_queue: empty
If a thread has packet #1 finished first, there is no problem.
If a thread has packet #2 finished first, it will try to dequeue the
packet #1 (head of the queue) from the working_queue. But the packet
isn't marked as completed, so it will just return.
Queue still look like
driver_queue:2--3--4--...
(of course, other threads are processing remaining packets,
but to simplify, no change in driver_queue.)
working_queue: 1--2
hardware: empty
Later, once the thread with #1 finished processing, it will
lock while (completed) {dequeue enqueue} unlock
At the end, queue look like,
driver_queue:2--3--4--...
working_queue: empty
hardware_queue: 1--2 (the lock preserves the order)
Just wanted to clarify. I will soon test the latest txlock patch.
AK
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
