Previous RX error checking was done exclusive-or for different error
types and caused DFS pulse events to be dropped when other error
flags (e.g. CRC) were set simultaneously.
This patch decouples PHY error processing from other types and ensures
that all pulses detected by HW are accounted by the pattern detector.
Signed-off-by: Zefir Kurtisi <[email protected]>
---
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
index 09b8c9d..92e0042 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
@@ -530,7 +530,11 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct ath_rx_status *rxs,
*/
if (rxsp->status11 & AR_CRCErr)
rxs->rs_status |= ATH9K_RXERR_CRC;
- else if (rxsp->status11 & AR_PHYErr) {
+ else if (rxsp->status11 & AR_DecryptCRCErr)
+ rxs->rs_status |= ATH9K_RXERR_DECRYPT;
+ else if (rxsp->status11 & AR_MichaelErr)
+ rxs->rs_status |= ATH9K_RXERR_MIC;
+ if (rxsp->status11 & AR_PHYErr) {
phyerr = MS(rxsp->status11, AR_PHYErrCode);
/*
* If we reach a point here where AR_PostDelimCRCErr is
@@ -552,11 +556,7 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct ath_rx_status *rxs,
rxs->rs_status |= ATH9K_RXERR_PHY;
rxs->rs_phyerr = phyerr;
}
-
- } else if (rxsp->status11 & AR_DecryptCRCErr)
- rxs->rs_status |= ATH9K_RXERR_DECRYPT;
- else if (rxsp->status11 & AR_MichaelErr)
- rxs->rs_status |= ATH9K_RXERR_MIC;
+ };
}
if (rxsp->status11 & AR_KeyMiss)
--
1.7.4.1
Hi,
That's interesting. I have found the AR9280 to do the same. I hadn't gone digging into it though, I've been busy with other things but it was on my todo list. So thankyou for finding it. :-)
Specifically (and this is all under BSD):
* I'd start rx'ing radar errors;
* then they'd become crc errors;
* after some indeterminate amount of time, they'd drift back to being radar errors.
I'll reproduce it on the AR9280 and let you know how it goes.
Thanks for digging into it!
Adrian
________________________________________
From: Zefir Kurtisi [[email protected]]
Sent: Tuesday, 28 February 2012 3:57 AM
To: Chadd, Adrian
Cc: [email protected]; [email protected]; [email protected]; Rodriguez, Luis
Subject: Re: [PATCH] ath9k: decouple RX error checking for DFS
Hi Adrian,
finally found an AR9280 and repeated the tests simultaneously, i.e. identical radar pulses go to AR9390 and AR9280.
After several hours of continuous radar firing (pulse count in the 1M range), it looks like the AR9280 does not suffer from the reported problem, i.e. the PHY error is never reported in combination with other RX errors.
The AR9390 OTOH always follows the following scheme:
* it starts as expected with radar pulses being reported as PHY errors (RX descriptor word 11 set to status11=0x511)
* after a short time (about 80% probability within 5-20 mins) a single CRC error is reported (status11=0x005)
* the CRC error flag becomes sticky thereafter, all further radar pulses are reported with status11=0x515, i.e. PHY *and* CRC error
The posted patch fixes this issue for monitor mode. Not sure about implications for the soon to follow master mode, though.
On 02/27/2012 05:00 PM, Chadd, Adrian wrote:
> Hi,
>
> Hm, so the AR9003 series NICs set PHY error _and_ decrypt/CRC error? On radar frames?
>
> Interesting! Have you checked to see if the AR9280 does the same?
>
>
>
> Adrian
Hi Adrian,
finally found an AR9280 and repeated the tests simultaneously, i.e. identical radar pulses go to AR9390 and AR9280.
After several hours of continuous radar firing (pulse count in the 1M range), it looks like the AR9280 does not suffer from the reported problem, i.e. the PHY error is never reported in combination with other RX errors.
The AR9390 OTOH always follows the following scheme:
* it starts as expected with radar pulses being reported as PHY errors (RX descriptor word 11 set to status11=0x511)
* after a short time (about 80% probability within 5-20 mins) a single CRC error is reported (status11=0x005)
* the CRC error flag becomes sticky thereafter, all further radar pulses are reported with status11=0x515, i.e. PHY *and* CRC error
The posted patch fixes this issue for monitor mode. Not sure about implications for the soon to follow master mode, though.
On 02/27/2012 05:00 PM, Chadd, Adrian wrote:
> Hi,
>
> Hm, so the AR9003 series NICs set PHY error _and_ decrypt/CRC error? On radar frames?
>
> Interesting! Have you checked to see if the AR9280 does the same?
>
>
>
> Adrian
Hi,
Hm, so the AR9003 series NICs set PHY error _and_ decrypt/CRC error? On radar frames?
Interesting! Have you checked to see if the AR9280 does the same?
Adrian
________________________________________
From: Zefir Kurtisi [[email protected]]
Sent: Monday, 27 February 2012 3:52 AM
To: [email protected]
Cc: [email protected]; [email protected]; Rodriguez, Luis; Chadd, Adrian; Zefir Kurtisi
Subject: [PATCH] ath9k: decouple RX error checking for DFS
Previous RX error checking was done exclusive-or for different error
types and caused DFS pulse events to be dropped when other error
flags (e.g. CRC) were set simultaneously.
This patch decouples PHY error processing from other types and ensures
that all pulses detected by HW are accounted by the pattern detector.
Signed-off-by: Zefir Kurtisi <[email protected]>
---
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
index 09b8c9d..92e0042 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
@@ -530,7 +530,11 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct ath_rx_status *rxs,
*/
if (rxsp->status11 & AR_CRCErr)
rxs->rs_status |= ATH9K_RXERR_CRC;
- else if (rxsp->status11 & AR_PHYErr) {
+ else if (rxsp->status11 & AR_DecryptCRCErr)
+ rxs->rs_status |= ATH9K_RXERR_DECRYPT;
+ else if (rxsp->status11 & AR_MichaelErr)
+ rxs->rs_status |= ATH9K_RXERR_MIC;
+ if (rxsp->status11 & AR_PHYErr) {
phyerr = MS(rxsp->status11, AR_PHYErrCode);
/*
* If we reach a point here where AR_PostDelimCRCErr is
@@ -552,11 +556,7 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct ath_rx_status *rxs,
rxs->rs_status |= ATH9K_RXERR_PHY;
rxs->rs_phyerr = phyerr;
}
-
- } else if (rxsp->status11 & AR_DecryptCRCErr)
- rxs->rs_status |= ATH9K_RXERR_DECRYPT;
- else if (rxsp->status11 & AR_MichaelErr)
- rxs->rs_status |= ATH9K_RXERR_MIC;
+ };
}
if (rxsp->status11 & AR_KeyMiss)
--
1.7.4.1
On 28 February 2012 07:59, Chadd, Adrian <[email protected]> wrote:
> Hi,
>
> That's interesting. I have found the AR9280 to do the same. I hadn't gone digging into it though, I've been busy with other things but it was on my todo list. So thankyou for finding it. :-)
Well, now I've looked at it. :-)
>
> Specifically (and this is all under BSD):
>
> * I'd start rx'ing radar errors;
> * then they'd become crc errors;
> * after some indeterminate amount of time, they'd drift back to being radar errors.
I see this exact behaviour on the AR5416. I'll test on the AR9130,
AR9160 and AR9280 next week.
I'll chat with you next week about extending it to generate the chirp
pulses and random interval PRI pulses. (And fixes to make it compile
on FreeBSD rather than Linux; I have it running on FreeBSD, but it
required some "fixes" to the source and Makefile.)
Thanks for doing the legwork on the USRP radar pulse generation stuff!
Adrian