The assumption is that during the hw config, transmission was
already stopped by mac80211. But during channel type change,
the mac80211 continue to transmit frames. The driver like ath9k
does chip reset while doing channel set. This could leads to
buffer overflow at driver side. And also after configuring the channel
and before doing rate updation, the frames are continued to xmit
with older rates. This patch ensures that the frames are always
xmitted with updated rates and avoid buffer overflow.
Signed-off-by: Rajkumar Manoharan <[email protected]>
---
v2: Removed new stop queue reason code by netif
net/mac80211/mlme.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 60a6f27..a1deb33 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -232,6 +232,9 @@ static u32 ieee80211_enable_ht(struct ieee80211_sub_if_data *sdata,
WARN_ON(!ieee80211_set_channel_type(local, sdata, channel_type));
}
+ netif_tx_stop_all_queues(sdata->dev);
+
+ drv_flush(local, false);
/* channel_type change automatically detected */
ieee80211_hw_config(local, 0);
@@ -245,6 +248,8 @@ static u32 ieee80211_enable_ht(struct ieee80211_sub_if_data *sdata,
rcu_read_unlock();
}
+ netif_tx_wake_all_queues(sdata->dev);
+
ht_opmode = le16_to_cpu(hti->operation_mode);
/* if bss configuration changed store the new one */
--
1.7.6.1
On Mon, 2011-08-29 at 17:03 +0530, Rajkumar Manoharan wrote:
> The assumption is that during the hw config, transmission was
> already stopped by mac80211. But during channel type change,
> the mac80211 continue to transmit frames. The driver like ath9k
> does chip reset while doing channel set. This could leads to
> buffer overflow at driver side. And also after configuring the channel
> and before doing rate updation, the frames are continued to xmit
> with older rates. This patch ensures that the frames are always
> xmitted with updated rates and avoid buffer overflow.
>
> Signed-off-by: Rajkumar Manoharan <[email protected]>
> ---
> v2: Removed new stop queue reason code by netif
> net/mac80211/mlme.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index 60a6f27..a1deb33 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -232,6 +232,9 @@ static u32 ieee80211_enable_ht(struct ieee80211_sub_if_data *sdata,
> WARN_ON(!ieee80211_set_channel_type(local, sdata, channel_type));
> }
>
> + netif_tx_stop_all_queues(sdata->dev);
> +
> + drv_flush(local, false);
doesn't that also need synchronize_net()?
johannes
On Mon, 2011-08-29 at 17:03 +0530, Rajkumar Manoharan wrote:
> The assumption is that during the hw config, transmission was
> already stopped by mac80211. But during channel type change,
> the mac80211 continue to transmit frames. The driver like ath9k
> does chip reset while doing channel set. This could leads to
> buffer overflow at driver side. And also after configuring the channel
> and before doing rate updation, the frames are continued to xmit
> with older rates. This patch ensures that the frames are always
> xmitted with updated rates and avoid buffer overflow.
>
> Signed-off-by: Rajkumar Manoharan <[email protected]>
> ---
> v2: Removed new stop queue reason code by netif
why did you do that?
> + netif_tx_stop_all_queues(sdata->dev);
> +
> + drv_flush(local, false);
> /* channel_type change automatically detected */
> ieee80211_hw_config(local, 0);
it seems to me that if the driver queues were full & stopped, this
happens, then flush will clear the queues & start them, and you'll start
queues during flush again...
johannes