[PATCH 1/2] ath9k: fix possible hang on flush

[PATCH 1/2] ath9k: fix possible hang on flush

[Tim Harvey]

If a flush is requested, make sure to clear the descriptor once we've
processed it.

This resolves a hang that will occur if all RX descriptors are full when a
flush is requested.

Signed-off-by: Tim Harvey <tharvey@gateworks.com>
---
 drivers/net/wireless/ath/ath9k/recv.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 6c9accd..e77a253 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -1113,14 +1113,13 @@ requeue_drop_frag:
 		}
 requeue:
 		list_add_tail(&bf->list, &sc->rx.rxbuf);
-		if (flush)
-			continue;
 
 		if (edma) {
 			ath_rx_edma_buf_link(sc, qtype);
 		} else {
 			ath_rx_buf_relink(sc, bf);
-			ath9k_hw_rxena(ah);
+			if (!flush)
+				ath9k_hw_rxena(ah);
 		}
 	} while (1);
 
-- 
1.8.3.2

[PATCH 2/2] ath9k: add a recv budget

[Tim Harvey]

Implement a recv budget so that in cases of high traffic we still allow other
taskets to get processed.

Without this, we can encounter a host of issues during high wireless traffic
reception depending on system load including rcu stall's detected (ARM),
soft lockups, failure to service critical tasks such as watchdog resets,
and triggering of the tx stuck tasklet.

The same thing was proposed previously by Ben:
 http://www.spinics.net/lists/linux-wireless/msg112891.html

The only difference here is that I make sure only processed packets are counted
in the budget by checking at the end of the rx loop.

Signed-off-by: Tim Harvey <tharvey@gateworks.com>
---
 drivers/net/wireless/ath/ath9k/recv.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index e77a253..19df969 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -975,6 +975,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
 	u64 tsf = 0;
 	unsigned long flags;
 	dma_addr_t new_buf_addr;
+	unsigned int budget = 512;
 
 	if (edma)
 		dma_type = DMA_BIDIRECTIONAL;
@@ -1121,6 +1122,9 @@ requeue:
 			if (!flush)
 				ath9k_hw_rxena(ah);
 		}
+
+		if (!budget--)
+			break;
 	} while (1);
 
 	if (!(ah->imask & ATH9K_INT_RXEOL)) {
-- 
1.8.3.2

Re: [PATCH 2/2] ath9k: add a recv budget

[Felix Fietkau]

On 2014-04-22 01:14, Tim Harvey wrote:
> Implement a recv budget so that in cases of high traffic we still allow other
> taskets to get processed.
> 
> Without this, we can encounter a host of issues during high wireless traffic
> reception depending on system load including rcu stall's detected (ARM),
> soft lockups, failure to service critical tasks such as watchdog resets,
> and triggering of the tx stuck tasklet.
> 
> The same thing was proposed previously by Ben:
>  http://www.spinics.net/lists/linux-wireless/msg112891.html
> 
> The only difference here is that I make sure only processed packets are counted
> in the budget by checking at the end of the rx loop.
> 
> Signed-off-by: Tim Harvey <tharvey@gateworks.com>
For both patches:
Acked-by: Felix Fietkau <nbd@openwrt.org>

Re: [PATCH 2/2] ath9k: add a recv budget

[Tim Harvey]

On Tue, Apr 22, 2014 at 2:09 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2014-04-22 01:14, Tim Harvey wrote:
>> Implement a recv budget so that in cases of high traffic we still allow other
>> taskets to get processed.
>>
>> Without this, we can encounter a host of issues during high wireless traffic
>> reception depending on system load including rcu stall's detected (ARM),
>> soft lockups, failure to service critical tasks such as watchdog resets,
>> and triggering of the tx stuck tasklet.
>>
>> The same thing was proposed previously by Ben:
>>  http://www.spinics.net/lists/linux-wireless/msg112891.html
>>
>> The only difference here is that I make sure only processed packets are counted
>> in the budget by checking at the end of the rx loop.
>>
>> Signed-off-by: Tim Harvey <tharvey@gateworks.com>
> For both patches:
> Acked-by: Felix Fietkau <nbd@openwrt.org>
>

+cc ath9k-devel@lists.ath9k.org
+cc Ben Greear

Any other ack's or comments on these? These address some fairly
long-standing bugs.

Tim

Re: [PATCH 2/2] ath9k: add a recv budget

[Felix Fietkau]

On 2014-04-29 14:04, Tim Harvey wrote:
> On Tue, Apr 22, 2014 at 2:09 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>> On 2014-04-22 01:14, Tim Harvey wrote:
>>> Implement a recv budget so that in cases of high traffic we still allow other
>>> taskets to get processed.
>>>
>>> Without this, we can encounter a host of issues during high wireless traffic
>>> reception depending on system load including rcu stall's detected (ARM),
>>> soft lockups, failure to service critical tasks such as watchdog resets,
>>> and triggering of the tx stuck tasklet.
>>>
>>> The same thing was proposed previously by Ben:
>>>  http://www.spinics.net/lists/linux-wireless/msg112891.html
>>>
>>> The only difference here is that I make sure only processed packets are counted
>>> in the budget by checking at the end of the rx loop.
>>>
>>> Signed-off-by: Tim Harvey <tharvey@gateworks.com>
>> For both patches:
>> Acked-by: Felix Fietkau <nbd@openwrt.org>
>>
> 
> +cc ath9k-devel@lists.ath9k.org
> +cc Ben Greear
> 
> Any other ack's or comments on these? These address some fairly
> long-standing bugs.
No need for further ack's or comments, since the change has been picked
up by John already.

- Felix

Re: [PATCH 2/2] ath9k: add a recv budget

[Adrian Chadd]

On 21 April 2014 16:14, Tim Harvey <tharvey@gateworks.com> wrote:
> Implement a recv budget so that in cases of high traffic we still allow other
> taskets to get processed.
>
> Without this, we can encounter a host of issues during high wireless traffic
> reception depending on system load including rcu stall's detected (ARM),
> soft lockups, failure to service critical tasks such as watchdog resets,
> and triggering of the tx stuck tasklet.

Are you also force rescheduling the Rx tasklet if you break?

You can definitely hit a race condition where you get RXEOL and RXDESC
before you run the scheduled RX tasklet. In that instance you may not
get any further interrupts until you re-poke the RX DMA engine. Adding
a FIFO entry may be enough, but it certainly isn't enough (ie, no
FIFOs) on pre-AR93xx chips.

(I've done the same thing in FreeBSD for the same reasons. It's ..
delicate to get right.)


-a

Re: [PATCH 1/2] ath9k: fix possible hang on flush

[Tim Harvey]

On Mon, Apr 21, 2014 at 4:14 PM, Tim Harvey <tharvey@gateworks.com> wrote:
> If a flush is requested, make sure to clear the descriptor once we've
> processed it.
>
> This resolves a hang that will occur if all RX descriptors are full when a
> flush is requested.
>
> Signed-off-by: Tim Harvey <tharvey@gateworks.com>
> ---
>  drivers/net/wireless/ath/ath9k/recv.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
> index 6c9accd..e77a253 100644
> --- a/drivers/net/wireless/ath/ath9k/recv.c
> +++ b/drivers/net/wireless/ath/ath9k/recv.c
> @@ -1113,14 +1113,13 @@ requeue_drop_frag:
>                 }
>  requeue:
>                 list_add_tail(&bf->list, &sc->rx.rxbuf);
> -               if (flush)
> -                       continue;
>
>                 if (edma) {
>                         ath_rx_edma_buf_link(sc, qtype);
>                 } else {
>                         ath_rx_buf_relink(sc, bf);
> -                       ath9k_hw_rxena(ah);
> +                       if (!flush)
> +                               ath9k_hw_rxena(ah);
>                 }
>         } while (1);
>
> --
> 1.8.3.2
>

+cc ath9k-devel@lists.ath9k.org

Tim