#
331722 |
|
29-Mar-2018 |
eadler |
Revert r330897:
This was intended to be a non-functional change. It wasn't. The commit message was thus wrong. In addition it broke arm, and merged crypto related code.
Revert with prejudice.
This revert skips files touched in r316370 since that commit was since MFCed. This revert also skips files that require $FreeBSD$ property changes.
Thank you to those who helped me get out of this mess including but not limited to gonzo, kevans, rgrimes.
Requested by: gjb (re)
|
#
330897 |
|
14-Mar-2018 |
eadler |
Partial merge of the SPDX changes
These changes are incomplete but are making it difficult to determine what other changes can/should be merged.
No objections from: pfg
|
#
302408 |
|
07-Jul-2016 |
gjb |
Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle. Prune svn:mergeinfo from the new branch, as nothing has been merged here.
Additional commits post-branch will follow.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
288095 |
|
22-Sep-2015 |
adrian |
net80211: include one copy of struct ieee80211_beacon_offsets into ieee80211vap
Submitted by: Andriy Voskoboinyk <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3658
|
#
287197 |
|
27-Aug-2015 |
glebius |
Replay r286410. Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack.
Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it.
Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details:
- The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters.
Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl.
Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann, Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing.
Reviewed by: adrian Sponsored by: Netflix Sponsored by: Nginx, Inc.
|
#
286835 |
|
17-Aug-2015 |
adrian |
Remove most of the references of ifp->if_softc and replace with references to ic->ic_softc.
This is in preparation for gleb's ifnet work.
Tested:
* ath(4), STA mode * ath(4), hostap mode * make universe
|
#
286437 |
|
07-Aug-2015 |
adrian |
Revert the wifi ifnet changes until things are more baked and tested.
* 286410 * 286413 * 286416
The initial commit broke a variety of debug and features that aren't in the GENERIC kernels but are enabled in other platforms.
|
#
286410 |
|
07-Aug-2015 |
glebius |
Change KPI of how device drivers that provide wireless connectivity interact with the net80211 stack.
Historical background: originally wireless devices created an interface, just like Ethernet devices do. Name of an interface matched the name of the driver that created. Later, wlan(4) layer was introduced, and the wlanX interfaces become the actual interface, leaving original ones as "a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer and a driver became a mix of methods that pass a pointer to struct ifnet as identifier and methods that pass pointer to struct ieee80211com. From user point of view, the parent interface just hangs on in the ifconfig list, and user can't do anything useful with it.
Now, the struct ifnet goes away. The struct ieee80211com is the only KPI between a device driver and net80211. Details:
- The struct ieee80211com is embedded into drivers softc. - Packets are sent via new ic_transmit method, which is very much like the previous if_transmit. - Bringing parent up/down is done via new ic_parent method, which notifies driver about any changes: number of wlan(4) interfaces, number of them in promisc or allmulti state. - Device specific ioctls (if any) are received on new ic_ioctl method. - Packets/errors accounting are done by the stack. In certain cases, when driver experiences errors and can not attribute them to any specific interface, driver updates ic_oerrors or ic_ierrors counters.
Details on interface configuration with new world order: - A sequence of commands needed to bring up wireless DOESN"T change. - /etc/rc.conf parameters DON'T change. - List of devices that can be used to create wlan(4) interfaces is now provided by net.wlan.devices sysctl.
Most drivers in this change were converted by me, except of wpi(4), that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing changes to at least 8 drivers. Thanks to Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in testing. Details here:
https://wiki.freebsd.org/projects/ifnet/net80211
Still, drivers: ndis, wtap, mwl, ipw, bwn, wi, upgt, uath were not tested. Changes to mwl, ipw, bwn, wi, upgt are trivial and chances of problems are low. The wtap wasn't compilable even before this change. But the ndis driver is complex, and it is likely to be broken with this commit. Help with testing and debugging it is appreciated.
Differential Revision: D2655, D2740 Sponsored by: Nginx, Inc. Sponsored by: Netflix
|
#
283744 |
|
29-May-2015 |
glebius |
Use device_printf() instead of if_printf(). No functional changes.
|
#
265588 |
|
07-May-2014 |
adrian |
Add casts to have it compile on amd64 without complaining about mismatched types.
Tested:
* AR9280, TDMA slave, amd64.
|
#
257176 |
|
26-Oct-2013 |
glebius |
The r48589 promised to remove implicit inclusion of if_var.h soon. Prepare to this event, adding if_var.h to files that do need it. Also, include all includes that now are included due to implicit pollution via if_var.h
Sponsored by: Netflix Sponsored by: Nginx, Inc.
|
#
250865 |
|
21-May-2013 |
adrian |
Enable the use of TDMA on an 802.11n channel (with aggregation disabled, of course.)
There's a few things that needed to happen:
* In case someone decides to set the beacon transmission rate to be at an MCS rate, use the MCS-aware version of the duration calculation to figure out how long the received beacon frame was.
* If TxOP enforcing is available on the hardware and we're doing TDMA, enable it after a reset and set the TDMA guard interval to zero. This seems to behave fine.
TODO:
* Although I haven't yet seen packet loss, the PHY errors that would be triggered (specifically Transmit-Override-Receive) aren't enabled by the 11n HAL. I'll have to do some work to enable these PHY errors for debugging.
What broke:
* My recent changes to the TX queue handling has resulted in the driver not keeping the hardware queue properly filled when doing non-aggregate traffic. I have a patch to commit soon which fixes this situation (albeit by reminding me about how my ath driver locking isn't working out, sigh.)
So if you want to test this without updating to the next set of patches that I commit, just bump the sysctl dev.ath.X.hwq_limit from 2 to 32.
Tested:
* AR5416 <-> AR5416, with ampdu disabled, HT40, 5GHz, MCS12+Short-GI. I saw 30mbit/sec in both directions using a bidirectional UDP test.
|
#
248671 |
|
23-Mar-2013 |
adrian |
Overhaul the TXQ locking (again!) as part of some beacon/cabq timing related issues.
Moving the TX locking under one lock made things easier to progress on but it had one important side-effect - it increased the latency when handling CABQ setup when sending beacons.
This commit introduces a bunch of new changes and a few unrelated changs that are just easier to lump in here.
The aim is to have the CABQ locking separate from other locking. The CABQ transmit path in the beacon process thus doesn't have to grab the general TX lock, reducing lock contention/latency and making it more likely that we'll make the beacon TX timing.
The second half of this commit is the CABQ related setup changes needed for sane looking EDMA CABQ support. Right now the EDMA TX code naively assumes that only one frame (MPDU or A-MPDU) is being pushed into each FIFO slot. For the CABQ this isn't true - a whole list of frames is being pushed in - and thus CABQ handling breaks very quickly.
The aim here is to setup the CABQ list and then push _that list_ to the hardware for transmission. I can then extend the EDMA TX code to stamp that list as being "one" FIFO entry (likely by tagging the last buffer in that list as "FIFO END") so the EDMA TX completion code correctly tracks things.
Major:
* Migrate the per-TXQ add/removal locking back to per-TXQ, rather than a single lock.
* Leave the software queue side of things under the ATH_TX_LOCK lock, (continuing) to serialise things as they are.
* Add a new function which is called whenever there's a beacon miss, to print out some debugging. This is primarily designed to help me figure out if the beacon miss events are due to a noisy environment, issues with the PHY/MAC, or other.
* Move the CABQ setup/enable to occur _after_ all the VAPs have been looked at. This means that for multiple VAPS in bursted mode, the CABQ gets primed once all VAPs are checked, rather than being primed on the first VAP and then having frames appended after this.
Minor:
* Add a (disabled) twiddle to let me enable/disable cabq traffic. It's primarily there to let me easily debug what's going on with beacon and CABQ setup/traffic; there's some DMA engine hangs which I'm finally trying to trace down.
* Clear bf_next when flushing frames; it should quieten some warnings that show up when a node goes away.
Tested:
* AR9280, STA/hostap, up to 4 vaps (staggered) * AR5416, STA/hostap, up to 4 vaps (staggered)
TODO:
* (Lots) more AR9380 and later testing, as I may have missed something here. * Leverage this to fix CABQ hanling for AR9380 and later chips. * Force bursted beaconing on the chips that default to staggered beacons and ensure the CABQ stuff is all sane (eg, the MORE bits that aren't being correctly set when chaining descriptors.)
|
#
243642 |
|
27-Nov-2012 |
adrian |
Pull out the debugging code from the critical path and make sure it happens _after_ all of the time delta calculations.
|
#
243614 |
|
27-Nov-2012 |
adrian |
* Fix another culprit of my "committed from the wrong directory" nonsense; now this works for non-debug and debug builds.
* Add a comment reminding me (or someone) to audit all of the relevant math to ensure there's no weird wrapping issues still lurking about.
But yes, this does seem to be mostly working.
Pointy-hat-to: adrian, yet again
|
#
243606 |
|
27-Nov-2012 |
adrian |
Correct some debugging output.
|
#
243597 |
|
27-Nov-2012 |
adrian |
Fix build
|
#
243592 |
|
27-Nov-2012 |
adrian |
Improve the TDMA debugging:
* add some further debugging prints, which are quite nice to have * add in ALQ hooks (optional!) to allow for the TDMA information to be logged in-line with the TX and RX descriptor information.
|
#
243590 |
|
27-Nov-2012 |
adrian |
Fix the TDMA nexttbtt programming for 802.11n chips.
The existing logic wrapped programming nexttbtt at 65535 TU. This is not good enough for the 11n chips, whose nexttbtt register (GENERIC_TIMER_0) has an initial value from 0..2^31-1 TSF. So converting the TU to TSF had the counter wrap at (65535 << 10) TSF.
Once this wrap occured, the nexttbtt value was very very low, much lower than the current TSF value. At this point, the nexttbtt timer would constantly fire, leading to the TX queue being constantly gated open.. and when this occured, the sender was not correctly transmitting in its slot but just able to continuously transmit. The master would then delay transmitting its beacon until after the air became free (which I guess would be after the burst interval, before the next burst interval would quickly follow) and that big delta in master beacon TX would start causing big swings in the slot timing adjustment.
With this change, the nexttbtt value is allowed to go all the way up to the maximum value permissable by the 32 bit representation. I haven't yet tested it to that point; I really should. The AR5212 HAL now filters out values above 65535 TU for the beacon configuration (and the relevant legal values for SWBA, DBA and NEXTATIM) and the AR5416 HAL just dutifully programs in what it should.
With this, TDMA is now useful on the 802.11n chips.
Tested:
* AR5416, AR9280 TDMA slave * AR5413 TDMA slave
|
#
243427 |
|
23-Nov-2012 |
adrian |
Use a 64 bit TSF write to update the TSF adjust, rather than a 32 bit TSF write.
The TSF_L32 update is fine for the AR5413 (and later, I guess) 11abg NICs however on the 11n NICs this didn't work. The TSF writes were causing a much larger time to be skipped, leading to the timing to never converge.
I've tested this 64 bit TSF read, adjust and write on both the 11n NICs and the AR5413 NIC I've been using for testing. It works fine on each.
This patch allows the AR5416/AR9280 to be used as a TDMA member. I don't yet know why the AR9280 is ~7uS accurate rather than ~3uS; I'll look into it soon.
Tested:
* AR5413, TDMA slave (~ 3us accuracy) * AR5416, TDMA slave (~ 3us accuracy) * AR9280, TDMA slave (~ 7us accuracy)
|
#
243426 |
|
23-Nov-2012 |
adrian |
Fix up the nexttbtt -> TSF delta calculation to not wrap ridiculously on the 802.11n NICs.
The 802.11n NICs return a TBTT value that continues far past the 16 bit HAL_BEACON_PERIOD time (in TU.) The code would constrain nextslot to HAL_BEACON_PERIOD, but it wasn't constraining nexttbtt - the pre-11n NICs would only return TU values from 0 -> HAL_BEACON_PERIOD. Thus, when nexttbtt exceeded 64 milliseconds, it would not wrap (but nextslot did) which lead to a huge tsfdelta.
So until the slot calculation is converted to work in TSF rather than a mix of TSF and TU, "make" the nexttbtt values match the TU assumptions for pre-11n NICs.
This fixes the crazy deltatsf calculations but it doesn't fix the non-convergent tsfdelta issue. That'll be fixed in a subsequent commit.
|
#
235679 |
|
20-May-2012 |
adrian |
Migrate the TDMA management functions out of if_ath.c into if_ath_tdma.c.
There's some TX path TDMA code in if_ath_tx.c which should be migrated out, but first I should likely try and verify/fix/repair the TDMA support in 9.x and -HEAD.
|