#
eb3821e6 |
|
03-Nov-2023 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
Revert "[ath] Attempt to fix epoch handling." This reverts commit af2441fbc7fa9e522e7f8697e5a181bdd4ff9e00. Sponsored by: The FreeBSD Foundation MFC after: 3 days
|
#
685dc743 |
|
16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line .c pattern Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/
|
#
4d846d26 |
|
10-May-2023 |
Warner Losh <imp@FreeBSD.org> |
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause. Discussed with: pfg MFC After: 3 days Sponsored by: Netflix
|
#
f858e928 |
|
22-May-2021 |
Adrian Chadd <adrian@FreeBSD.org> |
[ath] Handle STA + AP beacon programming without stomping over HW AP beacon programming I've been using STA+AP modes at home for a couple years now and I've been finding and fixing a lot of weird corner cases. This is the eventual patchset I've landed on. * Don't force beacon resync in STA mode if we're using sw beacon tracking. This stops a variety of stomping issues when the STA VAP is reconfigured; the AP hardware beacons were being stomped on! * Use the first AP VAP to configure beacons on, rather than the first VAP. This prevents weird behaviour in ath_beacon_config() when the hardware is being reconfigured and the STA VAP was the first one created. * Ensure the beacon interval / timing programming is within the AR9300 HAL bounds by masking off any flags that may have been there before shifting the value up to 1/8 TUs rather than the 1 TU resolution the previous chips used. Now I don't get weird beacon reprogramming during startup, STA state changes and hardware recovery which showed up as HI-LARIOUS beacon configurations and STAs that would just disconnect from the AP very frequently. Tested: * AR9344/AR9380, STA and AP and STA+AP modes
|
#
68545bc4 |
|
08-Dec-2020 |
Adrian Chadd <adrian@FreeBSD.org> |
[ath] Don't use hard-coded values in the sanity check. Don't use hard-coded values in the phy error and receive antenna checks.
|
#
857e0646 |
|
06-Jun-2020 |
Adrian Chadd <adrian@FreeBSD.org> |
[if_ath] Don't update the beacon bits from beacon frames in hostapd mode. This logic is running the beacon receive bits in STA+AP mode on both the STA and AP side. The STA side sees its beacons from the BSS fine; the AP side is seeing other beacons on the same channel but with the BSS node for some odd reason. (I think it's a valid reason, but I currently forget what that valid reason is.) So, just to be cleaner about things, don't run the nexttbtt/etc bits at all if we're in hostap mode. If I ever get mesh working then maybe I'll make sure it works right on mesh+ap and mesh+sta modes. Whilst here, log the VAP i'm being called on to make it clearer what is going on. I may end up adding a VAP dprintf version of this at some point. Tested: * AR9380, STA (DWDS client) + hostap on the same NIC
|
#
f6287cc6 |
|
01-Jun-2020 |
Adrian Chadd <adrian@FreeBSD.org> |
[ath] Don't re-program the beacon timers if we miss a beacon in software-beacon STA mode. This is something I added a few years ago to handle resyncing the beacon if we miss a beacon or need to sync after association/reassociation/powersave. However, if we're doing STA+AP mode (eg DWDS) then we don't want to reprogram the beacons here; this may upset normal AP operation. I missed checking for the sc->sc_swbmiss flag so I was reinitialising the beacon timers after every beacon miss / TSFOOR option, and that isn't likely good. This plus ensuring that STA's are created with "-beacon" to disable BMISS/TSFOOR processing will hopefully quieten some of the issues I've seen with missed beacons / TSFOOR (out of range) interrupts coming in when operating in STA mode. Tested: * AR9380/AR9580, STA+AP modes
|
#
af2441fb |
|
20-Feb-2020 |
Adrian Chadd <adrian@FreeBSD.org> |
[ath] Attempt to fix epoch handling. The epoch stuff with taskqueues works fine if the driver never calls the receive path in other contexts, but this driver does. If there was a chip reset during active receive then part of the reset will call the receive path to flush out any active packets before reinitialising the receive queue and that needs to be done with the epoch held. So: * make the receive task a normal task again * explicitly call epoch enter/exit around the legacy and newer DMA receive paths * add a couple of epoch asserts to ensure that the receive packet path itself is called with epoch held. This fixes it on my Atom eeepc laptop (circa 2010!) that I did all of my initial 802.11n work in this driver and net80211. Tested: * AR9285, STA mode TODO: * Test on EDMA chipset (AR9380) * Test in AP/adhoc modes, just to be sure (eg for beacon receive processing in particular.)
|
#
6c3e93cb |
|
11-Feb-2020 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Use NET_TASK_INIT() and NET_GROUPTASK_INIT() for drivers that process incoming packets in taskqueue context. Reviewed by: hselasky Differential Revision: https://reviews.freebsd.org/D23518
|
#
5ab0c843 |
|
24-Jan-2020 |
Gleb Smirnoff <glebius@FreeBSD.org> |
ath(4) processing input packets in taskqueue. Enter network epoch before calling ieee80211_input_mimo().
|
#
7d450faa |
|
04-May-2019 |
Adrian Chadd <adrian@FreeBSD.org> |
[ath] [ath_rate] Fix ANI calibration during non-ACTIVE states; start poking at rate control These are some fun issues I've found with my upstairs wifi link at such a ridiculous low signal level (like, < 5dB.) * Add per-station tx/rx rssi statistics, in potential preparation to use that in the RX rate control. * Call the rate control on each received frame to let it potentially use it as a hint for what rates to potentially use. It's a no-op right now. * Do ANI calibration during scan as well. The ath_newstate() call was disabling the ANI timer and only re-enabling it during transitions to _RUN. This has the unfortunate side-effect that if ANI deafened the NIC because of interference and it disassociated, it wouldn't be reset and the scan would never hear beacons. The ANI configuration is stored at least globally on some HALs and per-channel on others. Because of this a NIC reset wouldn't help; the ANI parameters would simply be programmed back in. Now, I have a feeling I also need to do this during AUTH/ASSOC too and maybe, if I'm feeling clever, I need to reset the ANI parameters on a given channel during a transition through INIT or if the VAP is destroyed/re-created. However for now this gets me out of the immediate weeds with connectivity upstairs (and thus I /can/ commit); I'll keep chipping away at tidying this stuff up in subsequent commits. Tested: * AR9344 (Wasp), 2G STA mode
|
#
a8083b9c |
|
20-Apr-2019 |
Adrian Chadd <adrian@FreeBSD.org> |
[ath] [ath_hal] [ath_hal_9300] Extend the start PCU receive to handle resetting ANI. One of the fun issues with scanning has been how the existing ANI values were programmed into the hardware when channels were changed. If you're on a really crappy channel and ANI has made you deaf then when you scan you continue to be deaf on all channels. This code passes in a flag to startpcureceive which in AR5416 and later is also used to enable ANI. This allows it to know if it's a normal operation or a scan operation. This fixes my situation at home where a temporary spot of a device going deaf due to interference starts scanning and .. can't hear anything until I restart. Now, this isn't the full fix - ideally: (a) all the ANI config and per-channel information would be migrated to the shared HAL stuff and enabled for all of the NICs; (b) when a station reassociates and some other error conditions (like missed beacons, NF calibration failures, etc) a knob to reset ANI parameters would likely help recovery. But hey, I'm committing bits of code again! woo! Tested: * AR9344 (2G), STA operation
|
#
718cf2cc |
|
27-Nov-2017 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
sys/dev: further adoption of SPDX licensing ID tags. Mainly focus on files that use BSD 2-Clause license, however the tool I was using misidentified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
|
#
7b6899bf |
|
25-May-2017 |
Adrian Chadd <adrian@FreeBSD.org> |
[ath] fix short-GI wireshark flag. Yes, HAL_RX_GI means "short guard interval."
|
#
f46839b9 |
|
24-May-2017 |
Adrian Chadd <adrian@FreeBSD.org> |
[ath] [ath_hal] retire AH_SUPPORT_AR5416 changing anything. Yes, the memory bloat is large, but it's 2017 and I'll fix it later by making it runtime configurable / per-chip configurable if I ever need to.
|
#
dc87d071 |
|
27-Nov-2016 |
Adrian Chadd <adrian@FreeBSD.org> |
[ath] include logging of TU versions of the TSF values. The beacon programming side of things deals in TUs and 1/8th TUs, so it's good to se the TU value here when debugging beaconing issues.
|
#
0cbe6805 |
|
03-Nov-2016 |
Adrian Chadd <adrian@FreeBSD.org> |
[ath] add the MIMO per-chain RSSI and noise floor information. This is a long time coming. The general pieces have been floating around in a local repo since circa 2012 when I dropped the net80211 support into the tree. This allows the per-chain RSSI and NF to show up in 'ifconfig wlanX list sta'. I haven't yet implemented the EVM hookups so that'll show up; that'll come later. Thanks to Susie Hellings <susie@susie.id.au> who did the original work on this a looong time ago for a company we both worked at.
|
#
f6b6084b |
|
02-May-2016 |
Pedro F. Giffuni <pfg@FreeBSD.org> |
dev/ath: minor spelling fixes in comments. No functional change. Reviewed by: adrian
|
#
31021a2b |
|
20-Apr-2016 |
Andriy Voskoboinyk <avos@FreeBSD.org> |
net80211: replace internal LE_READ_*/LE_WRITE_* macro with system le*dec / le*enc functions. Replace net80211 specific macros with system-wide bytestream encoding/decoding functions: - LE_READ_2 -> le16dec - LE_READ_4 -> le32dec - LE_WRITE_2 -> le16enc - LE_WRITE_4 -> le32enc + drop ieee80211_input.h include, where it was included for these operations only. Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D6030
|
#
afa44333 |
|
08-Apr-2016 |
Adrian Chadd <adrian@FreeBSD.org> |
[ath] Only process beacon frames for the IBSS/BSSID if appropriate. * Don't use arbitrary frames for the average RX RSSI - only frames from the current BSSID * Don't log / do the syncbeacon logic for another BSSID and definitely don't do the syncbeacon call if we miss beacons outside of STA mode. * Don't do the IBSS merge bits if the current node plainly won't ever match our current BSS (ie, the IBSS doesn't have to match, but all the same bits that we check in ieee80211_ibss_merge() have to match.) Tested: * ath(4), AR9380, IBSS mode, surrounded by a lot of IBSS 11ac networks. Sponsored by: Eva Automation, Inc.
|
#
94a88508 |
|
25-Nov-2015 |
Adrian Chadd <adrian@FreeBSD.org> |
[ath] listen to all beacons in IBSS and software beacon miss. I added MYBEACON support a while ago to listen to beacons that are only for your configured BSSID. For AR9380 and later NICs this results in a lot less chip wakeups in station mode as it then only shows you beacons that are destined to you. However in IBSS mode you really do want to hear all beacons so you can do IBSS merges. Oops. So only use MYBEACON for STA + not-scanning, and just use BEACON for the other modes it used to use BEACON for. This doesn't completely fix IBSS merges though - there are still some conditions to chase down and fix.
|
#
b45de1eb |
|
23-Nov-2015 |
Adrian Chadd <adrian@FreeBSD.org> |
[ath] migrate ioctl and busdma memory operations out into separate source files. This should be a big no-op pass; and reduces the size of if_ath.c. I'm hopefully soon going to take a whack at the USB support for ath(4) and this'll require some reuse of the busdma memory code.
|
#
7a79cebf |
|
27-Aug-2015 |
Gleb Smirnoff <glebius@FreeBSD.org> |
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.
|
#
3797bf08 |
|
16-Aug-2015 |
Adrian Chadd <adrian@FreeBSD.org> |
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
|
#
ba2c1fbc |
|
07-Aug-2015 |
Adrian Chadd <adrian@FreeBSD.org> |
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.
|
#
79d2c5e8 |
|
07-Aug-2015 |
Gleb Smirnoff <glebius@FreeBSD.org> |
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
|
#
76e6fd5d |
|
29-May-2015 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Use device_printf() instead of if_printf(). No functional changes.
|
#
c79f192c |
|
25-May-2015 |
Adrian Chadd <adrian@FreeBSD.org> |
Begin plumbing ieee80211_rx_stats through the receive path. Smart NICs with firmware (eg wpi, iwn, the new atheros parts, the intel 7260 series, etc) support doing a lot of things in firmware. This includes but isn't limited to things like scanning, sending probe requests and receiving probe responses. However, net80211 doesn't know about any of this - it still drives the whole scan/probe infrastructure itself. In order to move towards suppoting smart NICs, the receive path needs to know about the channel/details for each received packet. In at least the iwn and 7260 firmware (and I believe wpi, but I haven't tried it yet) it will do the scanning, power-save and off-channel buffering for you - all you need to do is handle receiving beacons and probe responses on channels that aren't what you're currently on. However the whole receive path is peppered with ic->ic_curchan and manual scan/powersave handling. The beacon parsing code also checks ic->ic_curchan to determine if the received beacon is on the correct channel or not.[1] So: * add freq/ieee values to ieee80211_rx_stats; * change ieee80211_parse_beacon() to accept the 'current' channel as an argument; * modify the iv_input() and iv_recv_mgmt() methods to include the rx_stats; * add a new method - ieee80211_lookup_channel_rxstats() - that looks up a channel based on the contents of ieee80211_rx_stats; * if it exists, use it in the mgmt path to switch the current channel (which still defaults to ic->ic_curchan) over to something determined by rx_stats. This is enough to kick-start scan offload support in the Intel 7260 driver that Rui/I are working on. It also is a good start for scan offload support for a handful of existing NICs (wpi, iwn, some USB parts) and it'll very likely dramatically improve stability/performance there. It's not the whole thing - notably, we don't need to do powersave, we should not scan all channels, and we should leave probe request sending to the firmware and not do it ourselves. But, this allows for continued development on the above features whilst actually having a somewhat working NIC. TODO: * Finish tidying up how the net80211 input path works. Right now ieee80211_input / ieee80211_input_all act as the top-level that everything feeds into; it should change so the MIMO input routines are those and the legacy routines are phased out. * The band selection should be done by the driver, not by the net80211 layer. * ieee80211_lookup_channel_rxstats() only determines 11b or 11g channels for now - this is enough for scanning, but not 100% true in all cases. If we ever need to handle off-channel scan support for things like static-40MHz or static-80MHz, or turbo-G, or half/quarter rates, then we should extend this. [1] This is a side effect of frequency-hopping and CCK modes - you can receive beacons when you think you're on a different channel. In particular, CCK (which is used by the low 11b rates, eg beacons!) is decodable from adjacent channels - just at a low SNR. FH is a side effect of having the hardware/firmware do the frequency hopping - it may pick up beacons transmitted from other FH networks that are in a different phase of hopping frequencies.
|
#
2127b2e2 |
|
18-Sep-2014 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Mechanically convert to if_inc_counter().
|
#
add58488 |
|
07-May-2014 |
Adrian Chadd <adrian@FreeBSD.org> |
There's no need to be this paranoid - ni is deferenced before this point. Coverity ID: CID 1211937
|
#
67aaf739 |
|
05-May-2014 |
Adrian Chadd <adrian@FreeBSD.org> |
Modify the RX path to keep the previous RX descriptor around once it's used. It turns out that the RX DMA engine does the same last-descriptor-link- pointer-re-reading trick that the TX DMA engine. That is, the hardware re-reads the link pointer before it moves onto the next descriptor. Thus we can't free a descriptor before we move on; it's possible the hardware will need to re-read the link pointer before we overwrite it with a new one. Tested: * AR5416, STA mode TODO: * more thorough AP and STA mode testing! * test on other pre-AR9380 NICs, just to be sure. * Break out the RX descriptor grabbing bits from the RX completion bits, like what is done in the RX EDMA code, so .. * .. the RX lock can be held during ath_rx_proc(), but not across packet input.
|
#
8cc3f9c9 |
|
29-Apr-2014 |
Adrian Chadd <adrian@FreeBSD.org> |
* Modify the beacon interval in debugging to be ni_intval, not 102400 * Be paranoid about avoiding divide-by-zero. Tested: * AR9380, STA mode
|
#
f5c30c4e |
|
29-Apr-2014 |
Adrian Chadd <adrian@FreeBSD.org> |
Bring over some initial power save management support, reset path fixes and beacon programming / debugging into the ath(4) driver. The basic power save tracking: * Add some new code to track the current desired powersave state; and * Add some reference count tracking so we know when the NIC is awake; then * Add code in all the points where we're about to touch the hardware and push it to force-wake. Then, how things are moved into power save: * Only move into network-sleep during a RUN->SLEEP transition; * Force wake the hardware up everywhere that we're about to touch the hardware. The net80211 stack takes care of doing RUN<->SLEEP<->(other) state transitions so we don't have to do it in the driver. Next, when to wake things up: * In short - everywhere we touch the hardware. * The hardware will take care of staying awake if things are queued in the transmit queue(s); it'll then transit down to sleep if there's nothing left. This way we don't have to track the software / hardware transmit queue(s) and keep the hardware awake for those. Then, some transmit path fixes that aren't related but useful: * Force EAPOL frames to go out at the lowest rate. This improves reliability during the encryption handshake after 802.11 negotiation. Next, some reset path fixes! * Fix the overlap between reset and transmit pause so we don't transmit frames during a reset. * Some noisy environments will end up taking a lot longer to reset than normal, so extend the reset period and drop the raise the reset interval to be more realistic and give the hardware some time to finish calibration. * Skip calibration during the reset path. Tsk! Then, beacon fixes in station mode! * Add a _lot_ more debugging in the station beacon reset path. This is all quite fluid right now. * Modify the STA beacon programming code to try and take the TU gap between desired TSF and the target TU into account. (Lifted from QCA.) Tested: * AR5210 * AR5211 * AR5212 * AR5413 * AR5416 * AR9280 * AR9285 TODO: * More AP, IBSS, mesh, TDMA testing * Thorough AR9380 and later testing! * AR9160 and AR9287 testing Obtained from: QCA
|
#
76039bc8 |
|
26-Oct-2013 |
Gleb Smirnoff <glebius@FreeBSD.org> |
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.
|
#
216ca234 |
|
12-Jun-2013 |
Adrian Chadd <adrian@FreeBSD.org> |
Migrate the LNA mixing diversity machinery from the AR9285 HAL to the driver. The AR9485 chip and AR933x SoC both implement LNA diversity. There are a few extra things that need to happen before this can be flipped on for those chips (mostly to do with setting up the different bias values and LNA1/LNA2 RSSI differences) but the first stage is putting this code into the driver layer so it can be reused. This has the added benefit of making it easier to expose configuration options and diagnostic information via the ioctl API. That's not yet being done but it sure would be nice to do so. Tested: * AR9285, with LNA diversity enabled * AR9285, with LNA diversity disabled in EEPROM
|
#
3df7a8ab |
|
04-Jun-2013 |
Adrian Chadd <adrian@FreeBSD.org> |
Implement a bit of a hack to store the AR9285/AR9485 RX LNA configuration in the RX antenna field. The AR9285/AR9485 use an LNA mixer to determine how to combine the signals from the two antennas. This is encoded in the RSSI fields (ctl/ext) for chain 2. So, let's use that here. This maps RX antennas 0->3 to the RX mixer configuration used to receive a frame. There's more that can be done but this is good enough to diagnose if the hardware is doing "odd" things like trying to receive frames on LNA2 (ie, antenna 2 or "alt" antenna) when there's only one antenna connected. Tested: * AR9285, STA mode
|
#
2c47932c |
|
07-May-2013 |
Adrian Chadd <adrian@FreeBSD.org> |
Implement STBC receive frame statistics. The AR9280 and later can receive STBC. This adds some statistics tracking to count these frames. A patch to athstats will be forthcoming.
|
#
8cc724d9 |
|
04-Apr-2013 |
Adrian Chadd <adrian@FreeBSD.org> |
Fix the busdma logic to work with EDMA chipsets when using bounce buffers (ie, >4GB on amd64.) The underlying problem was that PREREAD doesn't sync the mbuf with the DMA memory (ie, bounce buffer), so the bounce buffer may have had stale information. Thus it was always considering the buffer completed and things just went off the rails. This change does the following: * Make ath_rx_pkt() always consume the mbuf somehow; it no longer passes error mbufs (eg CRC errors, crypt errors, etc) back up to the RX path to recycle. This means that a new mbuf is always allocated each time, but it's cleaner. * Push the RX buffer map/unmap to occur in the RX path, not ath_rx_pkt(). Thus, ath_rx_pkt() now assumes (a) it has to consume the mbuf somehow, and (b) that it's already been unmapped and synced. * For the legacy path, the descriptor isn't mapped, it comes out of coherent, DMA memory anyway. So leave it there. * For the EDMA path, the RX descriptor has to be cleared before its passed to the hardware, so that when we check with a POSTREAD sync, we actually get either a blank (not finished) or a filled out descriptor (finished.) Otherwise we get stale data in the DMA memory. * .. so, for EDMA RX path, we need PREREAD|PREWRITE to sync the data -> DMA memory, then POSTREAD|POSTWRITE to finish syncing the DMA memory -> data. * Whilst we're here, make sure that in EDMA buffer setup (ie, bzero'ing the descriptor part) is done before the mbuf is map/synched. NOTE: there's been a lot of commits besides this one with regards to tidying up the busdma handling in ath(4). Please check the recent commit history. Discussed with and thanks to: scottl Tested: * AR5416 (non-EDMA) on i386, with the DMA tag for the driver set to 2^^30, not 2^^32, STA * AR9580 (EDMA) on i386, as above, STA * User - tested AR9380 on amd64 with 32GB RAM. PR: kern/177530
|
#
18303fd8 |
|
02-Apr-2013 |
Adrian Chadd <adrian@FreeBSD.org> |
Add a missing unmap; if we're freeing this mbuf then we must really both sync/unmap the dmamap before freeing it.
|
#
f0db652c |
|
19-Mar-2013 |
Adrian Chadd <adrian@FreeBSD.org> |
Break out the RX completion path into "FIFO check / refill" and "complete RX frames." The 128 entry RX FIFO is really easy to fill up and miss refilling when it's done in the ath taskq - as that gets blocked up doing RX completion, TX completion and other random things. So the 128 entry RX FIFO now gets emptied and refilled in the ath_intr() task (and it grabs / releases locks, so now ath_intr() can't just be a FAST handler yet!) but the locks aren't held for very long. The completion part is done in the ath taskqueue context. Details: * Create a new completed frame list - sc->sc_rx_rxlist; * Split the EDMA RX process queue into two halves - one that processes the RX FIFO and refills it with new frames; another that completes the completed frame list; * When tearing down the driver, flush whatever is in the deferred queue as well as what's in the FIFO; * Create two new RX methods - one that processes all RX queues, one that processes the given RX queue. When MSI is implemented, we get told which RX queue the interrupt came in on so we can specifically schedule that. (And I can do that with the non-MSI path too; I'll figure that out later.) * Convert the legacy code over to use these new RX methods; * Replace all the instances of the RX taskqueue enqueue with a call to a relevant RX method to enqueue one or all RX queues. Tested: * AR9380, STA * AR9580, STA * AR5413, STA
|
#
0e168bb8 |
|
11-Mar-2013 |
Adrian Chadd <adrian@FreeBSD.org> |
Add a few new fields to the RX vendor radiotap header: * a flags field that lets me know what's going on; * the hardware ratecode, unmolested by conversion to a bitrate; * the HAL rs_flags field, useful for debugging; * specifically mark aggregate sub-frames. This stuff sorely needs tidying up - it's missing some important stuff (eg numdelims) and it would be nice to put the flags at the beginning rather than at the end. Tested: * AR9380, STA mode, 2x2 HT40, monitoring RSSI and EVM values
|
#
1896b088 |
|
10-Mar-2013 |
Adrian Chadd <adrian@FreeBSD.org> |
Add three-stream EVM values.
|
#
1844ff16 |
|
16-Feb-2013 |
Adrian Chadd <adrian@FreeBSD.org> |
* Reduce the PCU lock overhead a little by only re-acquiring it if we actually do have to reinitialise the RX side of things after an RX descriptor EOL error. * Revert a change of mine from quite a while ago - don't shortcut the RX initialisation path. There's a RX FIFO bug in the earlier chips (I'm not sure when it was fixed in this series, but it's fixed with the AR9380 and later) which causes the same RX descriptor to be written to over and over. This causes the descriptor to be marked as "done", and this ends up causing the whole RX path to go very strange. This should fixed the "kickpcu; handled X packets" message spam where "X" is consistently small.
|
#
b8f355bf |
|
30-Jan-2013 |
Adrian Chadd <adrian@FreeBSD.org> |
Work around some rather unfortunate race conditions inside net80211. Right now, ic_curchan seems to be updated rather quickly (ie, during the ioctl) and before the driver gets notified of what's going on. So what I was seeing was: * NIC was in channel X; * It generates PHY errors for channel X; * an ioctl comes along from userland and changes things to channel Y; * .. this updates ic_curchan, but hasn't yet reset the hardware; * in parallel, RX is occuring and it looks at ic_curchan; * .. which is channel Y, so events get stamped with that now. Sigh.
|
#
233af52d |
|
13-Jan-2013 |
Adrian Chadd <adrian@FreeBSD.org> |
If we're doing a kickpcu, make sure we flush the whole RX list rather than stopping after 128 frames. Whilst here, add in some code that lets me optionally flip back to the original behaviour of calling ath_startrecv().
|
#
f29c6bde |
|
08-Jan-2013 |
Adrian Chadd <adrian@FreeBSD.org> |
If spectral scan is enabled, ensure radar report PHY errors are also enabled.
|
#
55caa1df |
|
03-Jan-2013 |
Adrian Chadd <adrian@FreeBSD.org> |
For PHY error frames, populate the configured channel flags rather than based on the received frame. PHY errors don't have the relevant HT or 40MHz MCS flag set.
|
#
c6499ecc |
|
04-Dec-2012 |
Gleb Smirnoff <glebius@FreeBSD.org> |
Mechanically substitute flags from historic mbuf allocator with malloc(9) flags in sys/dev.
|
#
bb327d28 |
|
16-Nov-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
ALQ logging enhancements: * upon setup, tell the alq code what the chip information is. * add TX/RX path logging for legacy chips. * populate the tx/rx descriptor length fields with a best-estimate. It's overly big (96 bytes when AH_SUPPORT_AR5416 is enabled) but it'll do for now. Whilst I'm here, add CURVNET_RESTORE() here during probe/attach as a partial solution to fixing crashes during attach when the attach fails. There are other attach failures that I have to deal with; those'll come later.
|
#
b69b0dcc |
|
08-Nov-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Add some hooks into the driver to attach, detach and record EDMA descriptor events. This is primarily for the TX EDMA and TX EDMA completion. I haven't yet tied it into the EDMA RX path or the legacy TX/RX path. Things that I don't quite like: * Make the pointer type 'void' in ath_softc and have if_ath_alq*() return a malloc'ed buffer. That would remove the need to include if_ath_alq.h in if_athvar.h. * The sysctl setup needs to be cleaned up.
|
#
516f6796 |
|
14-Oct-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Break the RX processing up into smaller chunks of 128 frames each. Right now processing a full 512 frame queue takes quite a while (measured on the order of milliseconds.) Because of this, the TX processing ends up sometimes preempting the taskqueue: * userland sends a frame * it goes in through net80211 and out to ath_start() * ath_start() will end up either direct dispatching or software queuing a frame. If TX had to wait for RX to finish, it would add quite a few ms of additional latency to the packet transmission. This in the past has caused issues with TCP throughput. Now, as part of my attempt to bring sanity to the TX/RX paths, the first step is to make the RX processing happen in smaller 'parts'. That way when TX is pushed into the ath taskqueue, there won't be so much latency in the way of things. The bigger scale change (which will come much later) is to actually process the frames in the ath_intr taskqueue but process _frames_ in the ath driver taskqueue. That would reduce the latency between processing and requeuing new descriptors. But that'll come later. The actual work: * Add ATH_RX_MAX at 128 (static for now); * break out of the processing loop if npkts reaches ATH_RX_MAX; * if we processed ATH_RX_MAX or more frames during the processing loop, immediately reschedule another RX taskqueue run. This will handle the further frames in the taskqueue. This should have very minimal impact on the general throughput case, unless the scheduler is being very very strange or the ath taskqueue ends up spending a lot of time on non-RX operations (such as TX completion.)
|
#
03682514 |
|
24-Sep-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Migrate the ath(4) KTR logging to use an ATH_KTR() macro. This should eventually be unified with ATH_DEBUG() so I can get both from one macro; that may take some time. Add some new probes for TX and TX completion.
|
#
b5c5592d |
|
28-Aug-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Remove extra debugging - there's no longer any need.
|
#
a1760308 |
|
06-Aug-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Remove unnecessary debugging printf()s.
|
#
1006fc0c |
|
23-Jul-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Modify ath_descdma_setup() to take a descriptor size parameter. The AR9300 and later descriptors are 128 bytes, however I'd like to make sure that isn't used for earlier chips. * Populate the TX descriptor length field in the softc with sizeof(ath_desc) * Use this field when allocating the TX descriptors * Pre-AR93xx TX/RX descriptors will use the ath_desc size; newer ones will query the HAL for these sizes.
|
#
c7f5bb7a |
|
15-Jul-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Handle RX Keymiss events. The AR9003 series NICs implement a separate RX error to signal that a Keycache miss occured. The earlier NICs would not set the key index valid bit. I'll dig into the difference between "no key index bit set" and "keycache miss".
|
#
2633dc93 |
|
10-Jul-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Migrate the ATH_KTR_* fields out to if_ath_debug.h .
|
#
d434a377 |
|
09-Jul-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Convert sc_rxpending to a per-EDMA queue, and use that for the legacy code. Prepare ath_rx_pkt() to handle multiple RX queues, and default the legacy RX queue to use the HP queue.
|
#
3d184db2 |
|
09-Jul-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Further preparations for the RX EDMA support. Break out the DMA descriptor setup/teardown code into a method. The EDMA RX code doesn't allocate descriptors, just ath_buf entries.
|
#
d60a0680 |
|
09-Jul-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Extend the RX HAL API to include the RX queue identifier. The AR93xx and later chips support two RX FIFO queues - a high and low priority queue. For legacy chips, just assume the queues are high priority. This is inspired by the reference driver but is a reimplementation of the API and code.
|
#
f8cc9b09 |
|
03-Jul-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Begin abstracting out the RX path in preparation for RX EDMA support. The RX EDMA support requires a modified approach to the RX descriptor handling. Specifically: * There's now two RX queues - high and low priority; * The RX queues are implemented as FIFOs; they're now an array of pointers to buffers; * .. and the RX buffer and descriptor are in the same "buffer", rather than being separate. So to that end, this commit abstracts out most of the RX related functions from the bulk of the driver. Notably, the RX DMA/buffer allocation isn't updated, primarily because I haven't yet fleshed out what it should look like. Whilst I'm here, create a set of matching but mostly unimplemented EDMA stubs. Tested: * AR9280, station mode TODO: * Thorough AP and other mode testing for non-EDMA chips; * Figure out how to allocate RX buffers suitable for RX EDMA, including correctly setting the mbuf length to compensate for the RX descriptor and completion status area.
|
#
d77363ad |
|
24-Jun-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Change the ath_dfs_process_phy_err() method to take an mbuf rather than a buffer pointer. For large radar pulses, the AR9130 and later will return a series of FFT results for software processing. These can overflow a single 2KB buffer on longer pulses. This would result in undefined buffer behaviour.
|
#
e1b5ab97 |
|
24-Jun-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Introduce an optional ath(4) radiotap vendor extension. This includes a few new fields in each RXed frame: * per chain RX RSSI (ctl and ext); * current RX chainmask; * EVM information; * PHY error code; * basic RX status bits (CRC error, PHY error, etc). This is primarily to allow me to do some userland PHY error processing for radar and spectral scan data. However since EVM and per-chain RSSI is provided, others may find it useful for a variety of tasks. The default is to not compile in the radiotap vendor extensions, primarily because tcpdump doesn't seem to handle the particular vendor extension layout I'm using, and I'd rather not break existing code out there that may be (badly) parsing the radiotap data. Instead, add the option 'ATH_ENABLE_RADIOTAP_VENDOR_EXT' to your kernel configuration file to enable these options.
|
#
891f9ad6 |
|
16-Jun-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
.. and this wasn't supposed to be in the previous commit either.
|
#
af0c4b9e |
|
16-Jun-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
oops, remove this, it wasn't supposed to be committed.
|
#
14d33c7e |
|
04-Jun-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Create a function - ath_tx_kick() - which is called where ath_start() is called to "kick" along TX. For now, schedule a taskqueue call. Later on I may go back to the direct call of ath_rx_tasklet() - but for now, this will do. I've tested UDP and TCP TX. UDP TX still achieves 240MBit, but TCP TX gets stuck at around 100MBit or so, instead of the 150MBit it should be at. I'll re-test with no ACPI/power/sleep states enabled at startup and see what effect it has. This is in preparation for supporting an if_transmit() path, which will turn ath_tx_kick() into a NUL operation (as there won't be an ifnet queue to service.) Tested: * AR9280 STA TODO: * test on AR5416, AR9160, AR928x STA/AP modes PR: kern/168649
|
#
470a7f41 |
|
04-Jun-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Migrate the TX path to a taskqueue for now, until a better way of implementing parallel TX and TX/RX completion can be done without simply abusing long-held locks. Right now, multiple concurrent ath_start() entries can result in frames being dequeued out of order. Well, they're dequeued in order fine, but if there's any preemption or race between CPUs between: * removing the frame from the ifnet, and * calling and runningath_tx_start(), until the frame is placed on a software or hardware TXQ Then although dequeueing the frame is in-order, queueing it to the hardware may be out of order. This is solved in a lot of other drivers by just holding a TX lock over a rather long period of time. This lets them continue to direct dispatch without races between dequeue and hardware queue. Note to observers: if_transmit() doesn't necessarily solve this. It removes the ifnet from the main path, but the same issue exists if there's some intermediary queue (eg a bufring, which as an aside also may pull in ifnet when you're using ALTQ.) So, until I can sit down and code up a much better way of doing parallel TX, I'm going to leave the TX path using a deferred taskqueue task. What I will likely head towards is doing a direct dispatch to hardware or software via if_transmit(), but it'll require some driver changes to allow queues to be made without using the really large ath_buf / ath_desc entries. TODO: * Look at how feasible it'll be to just do direct dispatch to ath_tx_start() from if_transmit(), avoiding doing _any_ intermediary serialisation into a global queue. This may break ALTQ for example, so I have to be delicate. * It's quite likely that I should break up ath_tx_start() so it deposits frames onto the software queues first, and then only fill in the 802.11 fields when it's being queued to the hardware. That will make the if_transmit() -> software queue path very quick and lightweight. * This has some very bad behaviour when using ACPI and Cx states. I'll do some subsequent analysis using KTR and schedgraph and file a follow-up PR or two. PR: kern/168649
|
#
803f0c59 |
|
21-May-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Re-add 'ic' and properly wrap it in the SUPERG macro.
|
#
62763b61 |
|
20-May-2012 |
Bernhard Schmidt <bschmidt@FreeBSD.org> |
Remove unused variable.
|
#
d542f7f6 |
|
20-May-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Migrate the per-frame code out from ath_rx_proc() to ath_rx_pkt(). This will (eventually) be used by the EDMA RX path used by the AR93xx and later NICs.
|
#
a35dae8d |
|
19-May-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
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.
|
#
e60c4fc2 |
|
19-May-2012 |
Adrian Chadd <adrian@FreeBSD.org> |
Migrate the bulk of the RX routines out from if_ath.c to if_ath_rx.[ch]. * migrate the rx processing out into if_ath_rx.c * migrate the TSF functions into if_ath_tsf.h, as inlines This is in prepration for supporting the EDMA RX routines, required to support the AR93xx series NICs. TODO: * ath_start() shouldn't be private, but it's called as part of the RX path. I should likely migrate ath_rx_tasklet() back into if_ath.c and then return this to be 'static'. The RX code really shouldn't need to see TX routines (and vice versa.) * ath_beacon_* should be in if_ath_beacon.[ch]. * ath_tdma_* should be in if_ath_tdma.[ch] ...
|