* Re: [RFC PATCH 10/17] zd1211rw: implement beacon fetching and handling ieee80211_get_buffered_bc()
From: Christian Lamparter @ 2011-01-06 21:46 UTC (permalink / raw)
To: Jussi Kivilinna; +Cc: linux-wireless, Daniel Drake, Ulrich Kunitz
In-Reply-To: <20110104234910.25309.19235.stgit@fate.lan>
On Wednesday 05 January 2011 00:49:10 Jussi Kivilinna wrote:
> diff --git a/drivers/net/wireless/zd1211rw/zd_mac.c b/drivers/net/wireless/zd1211rw/zd_mac.c
> index aace010..a3c7e8f 100644
> --- a/drivers/net/wireless/zd1211rw/zd_mac.c
> +++ b/drivers/net/wireless/zd1211rw/zd_mac.c
> @@ -958,16 +958,46 @@ static int zd_op_config(struct ieee80211_hw *hw, u32 changed)
> return zd_chip_set_channel(&mac->chip, conf->channel->hw_value);
> }
>
> +static void zd_beacon_done(struct zd_mac *mac)
> +{
this is an interesting one...
Since zd_beacon_done also uploads the next beacon so long in advance,
there could be an equally long race between the outdated state of the
next beacon's DTIM broadcast traffic indicator (802.11-2007 7.3.2.6)
which -in your case- was uploaded almost a beacon interval ago and
the xmit of ieee80211_get_buffered_bc *now*.
The dtim bc/mc bit might be not set, when a mc/bc arrived after the
beacon was uploaded, but before the "beacon done event" from the
hardware. So, dozing stations don't expect the broadcast traffic
and of course, they might miss it completely.
It's probably better to fix this in mac80211 (see the attached hack).
> + /*
> + * Send out buffered broad- and multicast frames.
> + */
> + while (!ieee80211_queue_stopped(mac->hw, 0)) {
> + skb = ieee80211_get_buffered_bc(mac->hw, mac->vif);
> + if (!skb)
> + break;
> + zd_op_tx(mac->hw, skb);
> + }
> +
> + /*
> + * Fetch next beacon so that tim_count is updated.
> + */
> + beacon = ieee80211_beacon_get(mac->hw, mac->vif);
> + if (!beacon)
> + return;
Ideally, you should assign a proper sequence # to beacon frames too.
(802.11-2007 7.1.3.4.1)
But as before, the long time between the upload and the actual beacon
xmit by the hardware make things really difficult. If you just call
"create_tx_desc_seq" right now, "theoretically" you have to buffer
all management and other Non-QoS data frames until the beacon was sent.
However, no one would do that :D. Either the hardware/firmware
controls the sequence counter or it's simply not implemented
(and nobody cares ;) ).
In fact, you could just as well drop "[09/17] zd1211rw: implement
seq_num for IEEE80211_TX_CTL_ASSIGN_SEQ"... unless of course, I'm
an idiot and there is a really clever way around these issues.
Regards,
Chr
---
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index c47d7c0..f71ed31 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -225,6 +225,7 @@ struct ieee80211_if_ap {
struct sk_buff_head ps_bc_buf;
atomic_t num_sta_ps; /* number of stations in PS mode */
int dtim_count;
+ bool dtim_bc_mc;
};
struct ieee80211_if_wds {
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 5950e3a..26b688b 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2178,6 +2178,8 @@ static void ieee80211_beacon_add_tim(struct ieee80211_if_ap *bss,
if (bss->dtim_count == 0 && !skb_queue_empty(&bss->ps_bc_buf))
aid0 = 1;
+ bss->dtim_bc_mc = aid0 == 1;
+
if (have_bits) {
/* Find largest even number N1 so that bits numbered 1 through
* (N1 x 8) - 1 in the bitmap are 0 and number N2 so that bits
@@ -2540,7 +2542,7 @@ ieee80211_get_buffered_bc(struct ieee80211_hw *hw,
if (sdata->vif.type != NL80211_IFTYPE_AP || !beacon || !beacon->head)
goto out;
- if (bss->dtim_count != 0)
+ if (bss->dtim_count != 0 || !bss->dtim_bc_mc)
goto out; /* send buffered bc/mc only after DTIM beacon */
while (1) {
^ permalink raw reply related
* Re: [RFC PATCH 13/17] zd1211rw: use stack for small cmd-buffers
From: Jussi Kivilinna @ 2011-01-06 21:53 UTC (permalink / raw)
To: Dan Williams; +Cc: Johannes Berg, linux-wireless, Daniel Drake, Ulrich Kunitz
In-Reply-To: <1294340139.5021.8.camel@dcbw.foobar.com>
Quoting Dan Williams <dcbw@redhat.com>:
> On Wed, 2011-01-05 at 10:27 +0100, Johannes Berg wrote:
>> On Wed, 2011-01-05 at 01:49 +0200, Jussi Kivilinna wrote:
>> > Use stack for allocing small < 64 byte arrays.
>>
>> I don't think this is valid -- DMA memory can't be from the stack.
Oh, my reply to Johannes didn't go to list.
>
> It's almost certainly not valid. You'll get BUGs from the kernel in
> this case, though it'll still probably work.
Ok, will not use stack for urb transfer_buffers.
-Jussi
^ permalink raw reply
* Re: [RFC PATCH 10/17] zd1211rw: implement beacon fetching and handling ieee80211_get_buffered_bc()
From: Johannes Berg @ 2011-01-06 21:55 UTC (permalink / raw)
To: Christian Lamparter
Cc: Jussi Kivilinna, linux-wireless, Daniel Drake, Ulrich Kunitz
In-Reply-To: <201101062246.38932.chunkeey@googlemail.com>
On Thu, 2011-01-06 at 22:46 +0100, Christian Lamparter wrote:
> Ideally, you should assign a proper sequence # to beacon frames too.
> (802.11-2007 7.1.3.4.1)
>
> But as before, the long time between the upload and the actual beacon
> xmit by the hardware make things really difficult. If you just call
> "create_tx_desc_seq" right now, "theoretically" you have to buffer
> all management and other Non-QoS data frames until the beacon was sent.
>
> However, no one would do that :D. Either the hardware/firmware
> controls the sequence counter or it's simply not implemented
> (and nobody cares ;) ).
Yeah ... it turns out that nobody cares. It's probably easier/better to
actually send beacons with seqno 0 instead of trying to hack around it.
> diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
> index c47d7c0..f71ed31 100644
> --- a/net/mac80211/ieee80211_i.h
> +++ b/net/mac80211/ieee80211_i.h
> @@ -225,6 +225,7 @@ struct ieee80211_if_ap {
> struct sk_buff_head ps_bc_buf;
> atomic_t num_sta_ps; /* number of stations in PS mode */
> int dtim_count;
> + bool dtim_bc_mc;
> };
>
> struct ieee80211_if_wds {
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> index 5950e3a..26b688b 100644
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -2178,6 +2178,8 @@ static void ieee80211_beacon_add_tim(struct ieee80211_if_ap *bss,
> if (bss->dtim_count == 0 && !skb_queue_empty(&bss->ps_bc_buf))
> aid0 = 1;
>
> + bss->dtim_bc_mc = aid0 == 1;
> +
> if (have_bits) {
> /* Find largest even number N1 so that bits numbered 1 through
> * (N1 x 8) - 1 in the bitmap are 0 and number N2 so that bits
> @@ -2540,7 +2542,7 @@ ieee80211_get_buffered_bc(struct ieee80211_hw *hw,
> if (sdata->vif.type != NL80211_IFTYPE_AP || !beacon || !beacon->head)
> goto out;
>
> - if (bss->dtim_count != 0)
> + if (bss->dtim_count != 0 || !bss->dtim_bc_mc)
> goto out; /* send buffered bc/mc only after DTIM beacon */
Hmm, interesting. That makes some sense I guess. Luckily, I have
hardware offload for this (extra queue) so I don't have to worry about
it :-)
johannes
^ permalink raw reply
* Re: Question about iwl3945
From: Larry Finger @ 2011-01-06 22:23 UTC (permalink / raw)
To: Johannes Berg; +Cc: wireless
In-Reply-To: <1294347881.25228.0.camel@jlt3.sipsolutions.net>
On 01/06/2011 03:04 PM, Johannes Berg wrote:
> On Thu, 2011-01-06 at 14:58 -0600, Larry Finger wrote:
>> Is there any reason why the Intel3495 wireless card using the iwl3945 driver
>> with kernel 2.6.34 does not work in AP mode using hostapd? The message is
>>
>> nl80211: Failed to set interface wlan0 into AP mode
>> nl80211 driver initialization failed.
>
> Neither 3945 nor 4965 can ever support AP mode due to firmware
> restrictions, sorry.
Thanks. Don't worry, I'm not trying to convert a $600 laptop into a $30 access
point! In fact, I already own 4 APs. A year ago, I wrote a howto for the
openSUSE forums, and someone is trying to follow my prescription. He had some
nasty things to say about the 3945 when I gave him the bad news. Unfortunately,
he will be buying another wifi card and not an AP.
Larry
^ permalink raw reply
* [PATCH] p54: fix sequence no. accounting off-by-one error
From: Christian Lamparter @ 2011-01-06 22:47 UTC (permalink / raw)
To: linux-wireless; +Cc: linville
P54_HDR_FLAG_DATA_OUT_SEQNR is meant to tell the
firmware that "the frame's sequence number has
already been set by the application."
Whereas IEEE80211_TX_CTL_ASSIGN_SEQ is set for
frames which lack a valid sequence number and
either the driver or firmware has to assign one.
Yup, it's the exact opposite!
Cc: <stable@kernel.org>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
Patch looks fairly harmless, so what can possibly go wrong ;)
---
diff --git a/drivers/net/wireless/p54/txrx.c b/drivers/net/wireless/p54/txrx.c
index 76b2318..f618b96 100644
--- a/drivers/net/wireless/p54/txrx.c
+++ b/drivers/net/wireless/p54/txrx.c
@@ -618,7 +618,7 @@ static void p54_tx_80211_header(struct p54_common *priv, struct sk_buff *skb,
else
*burst_possible = false;
- if (info->flags & IEEE80211_TX_CTL_ASSIGN_SEQ)
+ if (!(info->flags & IEEE80211_TX_CTL_ASSIGN_SEQ))
*flags |= P54_HDR_FLAG_DATA_OUT_SEQNR;
if (info->flags & IEEE80211_TX_CTL_PSPOLL_RESPONSE)
^ permalink raw reply related
* Re: ath9k and stuck xmit queue?
From: Ben Greear @ 2011-01-06 23:39 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
In-Reply-To: <4D23C3A9.9020007@candelatech.com>
On 01/04/2011 05:04 PM, Ben Greear wrote:
> I added a patch to my tree to print out some extra info,
> in particular the 'axq-stopped' bit. I notice that when
> I have 60 STA interfaces sometimes it seems to get stuck
> and cannot send any data. A printout of the debug in that
> case is below.
I found a similar scenario, but to me even weirder:
Note that the queue is stopped, but has no depth, and not
even any pending frames?
I do notice that the hw-tx-start is less than the number of
processed descriptors. That seems to normally go along with
the tx-hang issues..perhaps caused by chip resets or similar?
hw-tx-start: 53128 0 0 37325
hw-tx-proc-desc: 53103 0 0 37200
txq-memory-address: de70b3d0 de70b464 de70b33c de70b2a8
axq-qnum: 2 3 1 0
axq-depth: 0 0 0 0
axq-ampdu_depth: 0 0 0 0
axq-stopped 1 0 0 0
tx-in-progress 0 0 0 0
pending-frames 0 0 0 0
txq_headidx: 0 0 0 0
txq_tailidx: 0 0 0 0
axq_q empty: 0 1 1 0
axq_acq empty: 1 1 1 1
txq_fifo_pending: 1 1 1 1
txq_fifo[0] empty: 1 1 1 1
txq_fifo[1] empty: 1 1 1 1
txq_fifo[2] empty: 1 1 1 1
txq_fifo[3] empty: 1 1 1 1
txq_fifo[4] empty: 1 1 1 1
txq_fifo[5] empty: 1 1 1 1
txq_fifo[6] empty: 1 1 1 1
txq_fifo[7] empty: 1 1 1 1
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [ath9k] skbuff alloc of size 3872 failed
From: Ben Greear @ 2011-01-06 23:53 UTC (permalink / raw)
To: Matt Turner; +Cc: linux-wireless, ath9k-devel, Michael Guntsche, Eric Dumazet
In-Reply-To: <AANLkTi=GUN7=AQAAvmgADgwHtcquNiZbWEtgCoJpC4Fv@mail.gmail.com>
On 12/22/2010 11:22 AM, Matt Turner wrote:
> With the ath9k driver, I get "skbuff alloc of size 3872 failed"
>
> I hit this again today after not using wireless for quite sometime. It
> looks like it was originally reported against 2.6.35-rc1. Eric Dumazet
> provided a patch which fixed the issue, but apparently it's still not
> upstream. Why is this?
>
> If it is suitable for upstream inclusion, please take my Tested-by:
> Matt Turner<mattst88@gmail.com>
>
> https://patchwork.kernel.org/patch/104271/
I applied this patch and it seems to work fine, but there
were some questions by Eric in the patchwork thread that should probably
be answered by ath9k folks.
For instance:
IEEE80211_MAX_MPDU_LEN being 3840 + somebits is suspect, since it doesnt
match 802.11 specs.
It should be more close of 2304 + MAC header (32bytes) + FCS (4 bytes) ?
Eric: If the patch is fine as is, and if you are too busy to
submit it, I can do so with your Signed-off-by if you want.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [ath9k] skbuff alloc of size 3872 failed
From: Eric Dumazet @ 2011-01-07 0:04 UTC (permalink / raw)
To: Ben Greear; +Cc: Matt Turner, linux-wireless, ath9k-devel, Michael Guntsche
In-Reply-To: <4D2655E6.3020304@candelatech.com>
Le jeudi 06 janvier 2011 à 15:53 -0800, Ben Greear a écrit :
> On 12/22/2010 11:22 AM, Matt Turner wrote:
> > With the ath9k driver, I get "skbuff alloc of size 3872 failed"
> >
> > I hit this again today after not using wireless for quite sometime. It
> > looks like it was originally reported against 2.6.35-rc1. Eric Dumazet
> > provided a patch which fixed the issue, but apparently it's still not
> > upstream. Why is this?
> >
> > If it is suitable for upstream inclusion, please take my Tested-by:
> > Matt Turner<mattst88@gmail.com>
> >
> > https://patchwork.kernel.org/patch/104271/
>
> I applied this patch and it seems to work fine, but there
> were some questions by Eric in the patchwork thread that should probably
> be answered by ath9k folks.
>
> For instance:
>
> IEEE80211_MAX_MPDU_LEN being 3840 + somebits is suspect, since it doesnt
> match 802.11 specs.
>
> It should be more close of 2304 + MAC header (32bytes) + FCS (4 bytes) ?
>
>
> Eric: If the patch is fine as is, and if you are too busy to
> submit it, I can do so with your Signed-off-by if you want.
>
Well, problem is I dont have this hardware and various reports were very
confusing.
Certainly a word from authors/maintainers of this driver is wanted ;)
Thanks !
^ permalink raw reply
* Re: [ath9k-devel] [ath9k] skbuff alloc of size 3872 failed
From: Luis R. Rodriguez @ 2011-01-07 0:05 UTC (permalink / raw)
To: Ben Greear
Cc: Matt Turner, ath9k-devel, linux-wireless, Eric Dumazet,
Michael Guntsche
In-Reply-To: <4D2655E6.3020304@candelatech.com>
On Thu, Jan 6, 2011 at 3:53 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 12/22/2010 11:22 AM, Matt Turner wrote:
>> With the ath9k driver, I get "skbuff alloc of size 3872 failed"
>>
>> I hit this again today after not using wireless for quite sometime. It
>> looks like it was originally reported against 2.6.35-rc1. Eric Dumazet
>> provided a patch which fixed the issue, but apparently it's still not
>> upstream. Why is this?
>>
>> If it is suitable for upstream inclusion, please take my Tested-by:
>> Matt Turner<mattst88@gmail.com>
>>
>> https://patchwork.kernel.org/patch/104271/
>
> I applied this patch and it seems to work fine, but there
> were some questions by Eric in the patchwork thread that should probably
> be answered by ath9k folks.
>
> For instance:
>
> IEEE80211_MAX_MPDU_LEN being 3840 + somebits is suspect, since it doesnt
> match 802.11 specs.
>
> It should be more close of 2304 + MAC header (32bytes) + FCS (4 bytes) ?
>
>
> Eric: If the patch is fine as is, and if you are too busy to
> submit it, I can do so with your Signed-off-by if you want.
Eric, also please make sure you read and understand what using a SOB means:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=689e2371095cc5dfea9927120009341f369159aa;hb=HEAD#l309
Luis
^ permalink raw reply
* Re: [ath9k-devel] [ath9k] skbuff alloc of size 3872 failed
From: Eric Dumazet @ 2011-01-07 0:09 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Ben Greear, Matt Turner, ath9k-devel, linux-wireless,
Michael Guntsche
In-Reply-To: <AANLkTin1cpOwdwhHudcVhdckMgPpYcZGgRJkN+MpmrVm@mail.gmail.com>
Le jeudi 06 janvier 2011 à 16:05 -0800, Luis R. Rodriguez a écrit :
> Eric, also please make sure you read and understand what using a SOB means:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=689e2371095cc5dfea9927120009341f369159aa;hb=HEAD#l309
>
> Luis
You must be kidding.
^ permalink raw reply
* Re: [ath9k-devel] [ath9k] skbuff alloc of size 3872 failed
From: Luis R. Rodriguez @ 2011-01-07 0:12 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ben Greear, Matt Turner, ath9k-devel, linux-wireless,
Michael Guntsche
In-Reply-To: <1294358995.2704.16.camel@edumazet-laptop>
On Thu, Jan 6, 2011 at 4:09 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 06 janvier 2011 à 16:05 -0800, Luis R. Rodriguez a écrit :
>
>> Eric, also please make sure you read and understand what using a SOB means:
>>
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=689e2371095cc5dfea9927120009341f369159aa;hb=HEAD#l309
>>
>> Luis
>
> You must be kidding.
Heh actually sorry, I confused you with a first-patch-submitter.
Luis
^ permalink raw reply
* Re: [RFC v2] cfg80211: Add HT BSS attributes
From: Sujith @ 2011-01-07 0:32 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Johannes Berg, Jouni.Malinen, linux-wireless
In-Reply-To: <AANLkTim9iM0rLgg5PoVJvuq7WHBnCuf4=aemKAUt3gb8@mail.gmail.com>
Luis R. Rodriguez wrote:
> On Thu, Jan 6, 2011 at 12:28 AM, Sujith <m.sujith@gmail.com> wrote:
> > From: Sujith Manoharan <Sujith.Manoharan@atheros.com>
> >
> > Add two new per-BSS attributes to allow configuration of
> > HT capabilites and operational parameters by hostapd.
> >
> > Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
> > ---
> > v2: Initialize values and set the parameters in managed mode also.
>
> Can you split this up into two patches, one for cfg80211 and another
> for mac80211?
Hm, I sent a mail yesterday dropping this patch,
looks like it never reached the list.
Sujith
^ permalink raw reply
* [RFC v2] cfg80211: Add HT BSS attributes
From: Sujith @ 2011-01-07 0:33 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <19749.37051.292861.996698@gargle.gargle.HOWL>
(Resend to list).
Sujith wrote:
> Sujith wrote:
> > From: Sujith Manoharan <Sujith.Manoharan@atheros.com>
> >
> > Add two new per-BSS attributes to allow configuration of
> > HT capabilites and operational parameters by hostapd.
>
> Ok, looks like this is not needed after all.
> When operating in AP mode, an associated station's HT caps is
> notified to the driver through sta_add() anyway.
>
> The main motive for this patch was that ath9k_htc required the
> HT params of the current BSS and it turns out that the firmware
> doesn't do anything with the information. :)
>
> Sujith
^ permalink raw reply
* [PATCH 1/3] ath9k: Decrease skb size to fit into one page.
From: greearb @ 2011-01-07 0:46 UTC (permalink / raw)
To: linux-wireless; +Cc: ath9k-devel, Ben Greear, Eric Dumazet
From: Ben Greear <greearb@candelatech.com>
Patch is from Eric Dumazet, as described here:
https://patchwork.kernel.org/patch/104271/
Reported-by: Michael Guntsche <mike@it-loops.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
NOTE: This needs review by ath9k and/or other informed
people.
:100644 100644 b2497b8... 270661d... M drivers/net/wireless/ath/ath9k/recv.c
drivers/net/wireless/ath/ath9k/recv.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index b2497b8..270661d 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -230,11 +230,11 @@ static int ath_rx_edma_init(struct ath_softc *sc, int nbufs)
int error = 0, i;
u32 size;
-
- common->rx_bufsize = roundup(IEEE80211_MAX_MPDU_LEN +
- ah->caps.rx_status_len,
- min(common->cachelsz, (u16)64));
-
+ size = roundup(IEEE80211_MAX_MPDU_LEN + ah->caps.rx_status_len,
+ min(common->cachelsz, (u16)64));
+ common->rx_bufsize = max_t(u32, size,
+ SKB_MAX_ORDER(NET_SKB_PAD
+ + common->cachelsz, 0));
ath9k_hw_set_rx_bufsize(ah, common->rx_bufsize -
ah->caps.rx_status_len);
--
1.7.2.3
^ permalink raw reply related
* [PATCH 3/3] ath9k: Keep track of stations for debugfs.
From: greearb @ 2011-01-07 0:46 UTC (permalink / raw)
To: linux-wireless; +Cc: ath9k-devel, Ben Greear
In-Reply-To: <1294361165-15308-1-git-send-email-greearb@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
The stations hold the ath_node, which holds the tid
and other xmit logic structures. In order to debug
stuck xmit logic, we need a way to print out the tid
state for the stations.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 deda815... a34141a... M drivers/net/wireless/ath/ath9k/ath9k.h
:100644 100644 faf84e4... 8e29fb9... M drivers/net/wireless/ath/ath9k/debug.c
:100644 100644 b716ffb... a3e5539... M drivers/net/wireless/ath/ath9k/main.c
drivers/net/wireless/ath/ath9k/ath9k.h | 4 +
drivers/net/wireless/ath/ath9k/debug.c | 100 +++++++++++++++++++++++++++++++-
drivers/net/wireless/ath/ath9k/main.c | 20 ++++++-
3 files changed, 120 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index deda815..a34141a 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -592,6 +592,10 @@ struct ath_softc {
struct work_struct paprd_work;
struct work_struct hw_check_work;
struct completion paprd_complete;
+#ifdef CONFIG_ATH9K_DEBUGFS
+#define ATH9K_MAX_STATIONS 1024
+ struct ieee80211_sta *stations[ATH9K_MAX_STATIONS]; /* dbg purposes */
+#endif
bool paprd_pending;
u32 intrstatus;
diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index faf84e4..8e29fb9 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -587,6 +587,8 @@ static const struct file_operations fops_wiphy = {
sc->debug.stats.txstats[WME_AC_BK].elem, \
sc->debug.stats.txstats[WME_AC_VI].elem, \
sc->debug.stats.txstats[WME_AC_VO].elem); \
+ if (len >= size) \
+ goto done; \
} while(0)
#define PRX(str, elem) \
@@ -597,6 +599,8 @@ do { \
(unsigned int)(sc->tx.txq[WME_AC_BK].elem), \
(unsigned int)(sc->tx.txq[WME_AC_VI].elem), \
(unsigned int)(sc->tx.txq[WME_AC_VO].elem)); \
+ if (len >= size) \
+ goto done; \
} while(0)
#define PRQLE(str, elem) \
@@ -607,6 +611,8 @@ do { \
list_empty(&sc->tx.txq[WME_AC_BK].elem), \
list_empty(&sc->tx.txq[WME_AC_VI].elem), \
list_empty(&sc->tx.txq[WME_AC_VO].elem)); \
+ if (len >= size) \
+ goto done; \
} while (0)
static ssize_t read_file_xmit(struct file *file, char __user *user_buf,
@@ -614,7 +620,7 @@ static ssize_t read_file_xmit(struct file *file, char __user *user_buf,
{
struct ath_softc *sc = file->private_data;
char *buf;
- unsigned int len = 0, size = 4000;
+ unsigned int len = 0, size = 8000;
int i;
ssize_t retval = 0;
char tmp[32];
@@ -623,7 +629,10 @@ static ssize_t read_file_xmit(struct file *file, char __user *user_buf,
if (buf == NULL)
return -ENOMEM;
- len += sprintf(buf, "%30s %10s%10s%10s\n\n", "BE", "BK", "VI", "VO");
+ len += sprintf(buf, "Num-Tx-Queues: %i tx-queues-setup: 0x%x\n"
+ "%30s %10s%10s%10s\n\n",
+ ATH9K_NUM_TX_QUEUES, sc->tx.txqsetup,
+ "BE", "BK", "VI", "VO");
PR("MPDUs Queued: ", queued);
PR("MPDUs Completed: ", completed);
@@ -644,6 +653,14 @@ static ssize_t read_file_xmit(struct file *file, char __user *user_buf,
PR("hw-put-tx-buf: ", puttxbuf);
PR("hw-tx-start: ", txstart);
PR("hw-tx-proc-desc: ", txprocdesc);
+ len += snprintf(buf + len, size - len,
+ "%s%11p%11p%10p%10p\n", "txq-memory-address:",
+ &(sc->tx.txq[WME_AC_BE]),
+ &(sc->tx.txq[WME_AC_BK]),
+ &(sc->tx.txq[WME_AC_VI]),
+ &(sc->tx.txq[WME_AC_VO]));
+ if (len >= size)
+ goto done;
PRX("axq-qnum: ", axq_qnum);
PRX("axq-depth: ", axq_depth);
@@ -661,6 +678,74 @@ static ssize_t read_file_xmit(struct file *file, char __user *user_buf,
snprintf(tmp, sizeof(tmp) - 1, "txq_fifo[%i] empty: ", i);
PRQLE(tmp, txq_fifo[i]);
}
+
+done:
+ if (len > size)
+ len = size;
+
+ retval = simple_read_from_buffer(user_buf, count, ppos, buf, len);
+ kfree(buf);
+
+ return retval;
+}
+
+static ssize_t read_file_stations(struct file *file, char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct ath_softc *sc = file->private_data;
+ char *buf;
+ unsigned int len = 0, size = 64000;
+ int i;
+ ssize_t retval = 0;
+
+ buf = kzalloc(size, GFP_KERNEL);
+ if (buf == NULL)
+ return -ENOMEM;
+
+ len += snprintf(buf + len, size - len,
+ "Stations:\n"
+ " tid: addr sched paused buf_q-empty an ac\n"
+ " ac: addr sched tid_q-empty txq\n");
+
+ for (i = 0; i < ATH9K_MAX_STATIONS; i++) {
+ if (sc->stations[i]) {
+ struct ath_node *an;
+ int q;
+ an = (struct ath_node *)(sc->stations[i]->drv_priv);
+
+ len += snprintf(buf + len, size - len,
+ "%pM\n", sc->stations[i]->addr);
+ if (len >= size)
+ goto done;
+
+ for (q = 0; q < WME_NUM_TID; q++) {
+ struct ath_atx_tid *tid = &(an->tid[q]);
+ len += snprintf(buf + len, size - len,
+ " tid: %p %s %s %i %p %p\n",
+ tid,
+ tid->sched ? "sched" : "idle",
+ tid->paused ? "pause" : " ",
+ list_empty(&tid->buf_q),
+ tid->an, tid->ac);
+ if (len >= size)
+ goto done;
+ }
+
+ for (q = 0; q < WME_NUM_AC; q++) {
+ struct ath_atx_ac *ac = &(an->ac[q]);
+ len += snprintf(buf + len, size - len,
+ " ac: %p %s %i %p\n",
+ ac,
+ ac->sched ? "sched" : "idle",
+ list_empty(&ac->tid_q),
+ ac->txq);
+ if (len >= size)
+ goto done;
+ }
+ }
+ }
+
+done:
if (len > size)
len = size;
@@ -708,6 +793,13 @@ static const struct file_operations fops_xmit = {
.llseek = default_llseek,
};
+static const struct file_operations fops_stations = {
+ .read = read_file_stations,
+ .open = ath9k_debugfs_open,
+ .owner = THIS_MODULE,
+ .llseek = default_llseek,
+};
+
static ssize_t read_file_recv(struct file *file, char __user *user_buf,
size_t count, loff_t *ppos)
{
@@ -945,6 +1037,10 @@ int ath9k_init_debug(struct ath_hw *ah)
sc, &fops_xmit))
goto err;
+ if (!debugfs_create_file("stations", S_IRUSR, sc->debug.debugfs_phy,
+ sc, &fops_stations))
+ goto err;
+
if (!debugfs_create_file("recv", S_IRUSR, sc->debug.debugfs_phy,
sc, &fops_recv))
goto err;
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index b716ffb..a3e5539 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1769,7 +1769,15 @@ static int ath9k_sta_add(struct ieee80211_hw *hw,
{
struct ath_wiphy *aphy = hw->priv;
struct ath_softc *sc = aphy->sc;
-
+#ifdef CONFIG_ATH9K_DEBUGFS
+ int i;
+ for (i = 0; i < ATH9K_MAX_STATIONS; i++) {
+ if (!sc->stations[i]) {
+ sc->stations[i] = sta;
+ break;
+ }
+ }
+#endif
ath_node_attach(sc, sta);
return 0;
@@ -1781,7 +1789,15 @@ static int ath9k_sta_remove(struct ieee80211_hw *hw,
{
struct ath_wiphy *aphy = hw->priv;
struct ath_softc *sc = aphy->sc;
-
+#ifdef CONFIG_ATH9K_DEBUGFS
+ int i;
+ for (i = 0; i < ATH9K_MAX_STATIONS; i++) {
+ if (sc->stations[i] == sta) {
+ sc->stations[i] = NULL;
+ break;
+ }
+ }
+#endif
ath_node_detach(sc, sta);
return 0;
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/3] ath9k: Re-start xmit logic in xmit watchdog timer.
From: greearb @ 2011-01-07 0:46 UTC (permalink / raw)
To: linux-wireless; +Cc: ath9k-devel, Ben Greear
In-Reply-To: <1294361165-15308-1-git-send-email-greearb@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
We should not get to this state, but we do. What is
worse, many times the xmit logic still will not start,
probably due to tids being paused when they shouldn't be.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
NOTE: This needs review. It might be too much of a hack
for upstream code, and at best it works around a small part
of the problem.
:100644 100644 3aae523... 547fb44... M drivers/net/wireless/ath/ath9k/xmit.c
drivers/net/wireless/ath/ath9k/xmit.c | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 3aae523..547fb44 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2110,6 +2110,27 @@ static void ath_tx_complete_poll_work(struct work_struct *work)
} else {
txq->axq_tx_inprogress = true;
}
+ } else {
+ /* If the queue has pending buffers, then it
+ * should be doing tx work (and have axq_depth).
+ * Shouldn't get to this state I think..but
+ * perhaps we do.
+ */
+ if (!list_empty(&txq->axq_acq)) {
+ ath_err(ath9k_hw_common(sc->sc_ah),
+ "txq: %p axq_qnum: %i,"
+ " axq_link: %p"
+ " pending frames: %i"
+ " axq_acq is not empty, but"
+ " axq_depth is zero. Calling"
+ " ath_txq_schedule to restart"
+ " tx logic.\n",
+ txq, txq->axq_qnum,
+ txq->axq_link,
+ txq->pending_frames);
+ ATH_DBG_WARN_ON_ONCE(1);
+ ath_txq_schedule(sc, txq);
+ }
}
spin_unlock_bh(&txq->axq_lock);
}
--
1.7.2.3
^ permalink raw reply related
* Re: [RFC v2] cfg80211: Add HT BSS attributes
From: Luis R. Rodriguez @ 2011-01-07 0:56 UTC (permalink / raw)
To: Sujith; +Cc: linux-wireless
In-Reply-To: <19750.24410.495583.789895@gargle.gargle.HOWL>
On Thu, Jan 6, 2011 at 4:33 PM, Sujith <m.sujith@gmail.com> wrote:
> (Resend to list).
>
> Sujith wrote:
>> Sujith wrote:
>> > From: Sujith Manoharan <Sujith.Manoharan@atheros.com>
>> >
>> > Add two new per-BSS attributes to allow configuration of
>> > HT capabilites and operational parameters by hostapd.
>>
>> Ok, looks like this is not needed after all.
>> When operating in AP mode, an associated station's HT caps is
>> notified to the driver through sta_add() anyway.
>>
>> The main motive for this patch was that ath9k_htc required the
>> HT params of the current BSS and it turns out that the firmware
>> doesn't do anything with the information. :)
Ah, I thought the purpose was to allow dynamic configuration of HT
capa/params used.
Luis
^ permalink raw reply
* Re: [ath9k-devel] [PATCH 1/3] ath9k: Decrease skb size to fit into one page.
From: Luis R. Rodriguez @ 2011-01-07 0:57 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, ath9k-devel, Eric Dumazet
In-Reply-To: <1294361165-15308-1-git-send-email-greearb@candelatech.com>
On Thu, Jan 6, 2011 at 4:46 PM, <greearb@candelatech.com> wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> Patch is from Eric Dumazet, as described here:
> https://patchwork.kernel.org/patch/104271/
>
> Reported-by: Michael Guntsche <mike@it-loops.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Did he SOB it?
Luis
^ permalink raw reply
* Re: [ath9k-devel] [PATCH 1/3] ath9k: Decrease skb size to fit into one page.
From: Ben Greear @ 2011-01-07 1:03 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, ath9k-devel, Eric Dumazet
In-Reply-To: <AANLkTin2YS4akjJpAhagqesoNO-5D=ngbMJLOqS8-yQu@mail.gmail.com>
On 01/06/2011 04:57 PM, Luis R. Rodriguez wrote:
> On Thu, Jan 6, 2011 at 4:46 PM,<greearb@candelatech.com> wrote:
>> From: Ben Greear<greearb@candelatech.com>
>>
>> Patch is from Eric Dumazet, as described here:
>> https://patchwork.kernel.org/patch/104271/
>>
>> Reported-by: Michael Guntsche<mike@it-loops.com>
>> Signed-off-by: Eric Dumazet<eric.dumazet@gmail.com>
>
> Did he SOB it?
I guess not explicitly. But, it's a small little patch that has been
languishing for 6 months. Please put the fix in one way or another.
I don't care that I get any credit what-so-ever.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 1/3] ath9k: Decrease skb size to fit into one page.
From: Christian Lamparter @ 2011-01-07 1:04 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, ath9k-devel, Eric Dumazet
In-Reply-To: <1294361165-15308-1-git-send-email-greearb@candelatech.com>
On Friday 07 January 2011 01:46:03 greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> Patch is from Eric Dumazet, as described here:
> https://patchwork.kernel.org/patch/104271/
>
> Reported-by: Michael Guntsche <mike@it-loops.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
> ---
>
> NOTE: This needs review by ath9k and/or other informed
> people.
Does the hardware support vector-i/o for rx (like for instance iwlagn)?
Else, this change would break A-MSDU rx - which is a mandatory feature
(although, not very popular) of 802.11n -
See for example 802.11n-2009 9.7c:
"Support for the reception of an A-MSDU, where [...], is mandatory for
an HT STA"
And 7.1.2 "The maximum frame body size is determined by the maximum
MSDU size (2304 octets) OR the maximum A-MSDU (3839 or 7935 octets,
depending upon the STA's capability), plus any overhead from security
encapsulation.
> diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
> index b2497b8..270661d 100644
> --- a/drivers/net/wireless/ath/ath9k/recv.c
> +++ b/drivers/net/wireless/ath/ath9k/recv.c
> @@ -230,11 +230,11 @@ static int ath_rx_edma_init(struct ath_softc *sc, int nbufs)
> int error = 0, i;
> u32 size;
>
> -
> - common->rx_bufsize = roundup(IEEE80211_MAX_MPDU_LEN +
> - ah->caps.rx_status_len,
> - min(common->cachelsz, (u16)64));
> -
> + size = roundup(IEEE80211_MAX_MPDU_LEN + ah->caps.rx_status_len,
> + min(common->cachelsz, (u16)64));
> + common->rx_bufsize = max_t(u32, size,
> + SKB_MAX_ORDER(NET_SKB_PAD
> + + common->cachelsz, 0));
> ath9k_hw_set_rx_bufsize(ah, common->rx_bufsize -
> ah->caps.rx_status_len);
>
>
^ permalink raw reply
* Re: [PATCH 1/3] ath9k: Decrease skb size to fit into one page.
From: Eric Dumazet @ 2011-01-07 1:23 UTC (permalink / raw)
To: Christian Lamparter; +Cc: greearb, linux-wireless, ath9k-devel
In-Reply-To: <201101070205.00886.chunkeey@googlemail.com>
Le vendredi 07 janvier 2011 à 02:04 +0100, Christian Lamparter a écrit :
> On Friday 07 January 2011 01:46:03 greearb@candelatech.com wrote:
> > From: Ben Greear <greearb@candelatech.com>
> >
> > Patch is from Eric Dumazet, as described here:
> > https://patchwork.kernel.org/patch/104271/
> >
> > Reported-by: Michael Guntsche <mike@it-loops.com>
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> > Signed-off-by: Ben Greear <greearb@candelatech.com>
> > ---
> >
> > NOTE: This needs review by ath9k and/or other informed
> > people.
>
> Does the hardware support vector-i/o for rx (like for instance iwlagn)?
> Else, this change would break A-MSDU rx - which is a mandatory feature
> (although, not very popular) of 802.11n -
>
> See for example 802.11n-2009 9.7c:
>
> "Support for the reception of an A-MSDU, where [...], is mandatory for
> an HT STA"
>
> And 7.1.2 "The maximum frame body size is determined by the maximum
> MSDU size (2304 octets) OR the maximum A-MSDU (3839 or 7935 octets,
> depending upon the STA's capability), plus any overhead from security
> encapsulation.
Then, only solution is to mark this broken, and perform a copy of each
received frame, to keep a order-1 buffer(s) allocated for hardware.
Its too easy to have memory allocation failures for high order pages and
freeze the card.
A copy is time consuming, but at least works.
^ permalink raw reply
* Re: [PATCH] compat-wireless linux-2.6.37.y, fix compile error for pm_qos_add_request()
From: Luis R. Rodriguez @ 2011-01-07 1:51 UTC (permalink / raw)
To: tim.gardner; +Cc: linux-wireless, mcgrof
In-Reply-To: <4D2632A6.9040307@canonical.com>
On Thu, Jan 6, 2011 at 1:22 PM, Tim Gardner <tim.gardner@canonical.com> wrote:
> On 01/06/2011 02:18 PM, Tim Gardner wrote:
>>
>> rtg
>> ----
>
> git send-email clipped my annotation. It should have said:
>
> "Compile tested against 2.6.32.25 and 2.6.35.8"
Awesome, thanks, applied, pushed and made two new releases with this,
a -2 release.
Luis
^ permalink raw reply
* Re: [PATCH 1/3] ath9k: Decrease skb size to fit into one page.
From: Luis R. Rodriguez @ 2011-01-07 1:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Christian Lamparter, greearb, linux-wireless, ath9k-devel
In-Reply-To: <1294363427.2704.23.camel@edumazet-laptop>
On Thu, Jan 6, 2011 at 5:23 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 07 janvier 2011 à 02:04 +0100, Christian Lamparter a écrit :
>> On Friday 07 January 2011 01:46:03 greearb@candelatech.com wrote:
>> > From: Ben Greear <greearb@candelatech.com>
>> >
>> > Patch is from Eric Dumazet, as described here:
>> > https://patchwork.kernel.org/patch/104271/
>> >
>> > Reported-by: Michael Guntsche <mike@it-loops.com>
>> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>> > Signed-off-by: Ben Greear <greearb@candelatech.com>
>> > ---
>> >
>> > NOTE: This needs review by ath9k and/or other informed
>> > people.
>>
>> Does the hardware support vector-i/o for rx (like for instance iwlagn)?
>> Else, this change would break A-MSDU rx - which is a mandatory feature
>> (although, not very popular) of 802.11n -
>>
>> See for example 802.11n-2009 9.7c:
>>
>> "Support for the reception of an A-MSDU, where [...], is mandatory for
>> an HT STA"
>>
>> And 7.1.2 "The maximum frame body size is determined by the maximum
>> MSDU size (2304 octets) OR the maximum A-MSDU (3839 or 7935 octets,
>> depending upon the STA's capability), plus any overhead from security
>> encapsulation.
>
> Then, only solution is to mark this broken, and perform a copy of each
> received frame, to keep a order-1 buffer(s) allocated for hardware.
-ENOTPOSSIBLE -- its an WFA requirement to RX AMSDU.
> Its too easy to have memory allocation failures for high order pages and
> freeze the card.
Can't we us paged RX skbs, which mac80211 supports now?
See 2f301227a1ede57504694e1f64839839f5737cac and friends.
Luis
^ permalink raw reply
* Re: [RFC v2] cfg80211: Add HT BSS attributes
From: Daniel Halperin @ 2011-01-07 2:00 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Sujith, linux-wireless
In-Reply-To: <AANLkTintPXzmiGnjEQvXUO3hVCW9J4tGn=MookTx1qBM@mail.gmail.com>
On Thu, Jan 6, 2011 at 4:56 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Thu, Jan 6, 2011 at 4:33 PM, Sujith <m.sujith@gmail.com> wrote:
>> (Resend to list).
>>
>> Sujith wrote:
>>> Sujith wrote:
>>> > From: Sujith Manoharan <Sujith.Manoharan@atheros.com>
>>> >
>>> > Add two new per-BSS attributes to allow configuration of
>>> > HT capabilites and operational parameters by hostapd.
>>>
>>> Ok, looks like this is not needed after all.
>>> When operating in AP mode, an associated station's HT caps is
>>> notified to the driver through sta_add() anyway.
>>>
>>> The main motive for this patch was that ath9k_htc required the
>>> HT params of the current BSS and it turns out that the firmware
>>> doesn't do anything with the information. :)
>
> Ah, I thought the purpose was to allow dynamic configuration of HT
> capa/params used.
>
Yeah, me too. Isn't greenfield mode (whether there are legacy devices
around) part of the operating capabilities and should be supported by
hostapd?
Dan
^ permalink raw reply
* Re: [PATCH 1/3] ath9k: Decrease skb size to fit into one page.
From: Eric Dumazet @ 2011-01-07 2:07 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Christian Lamparter, greearb, linux-wireless, ath9k-devel
In-Reply-To: <AANLkTinQ42y9Tu=Ugb92-R+56BP4U+cDBzd4tQQCES1W@mail.gmail.com>
Le jeudi 06 janvier 2011 à 17:57 -0800, Luis R. Rodriguez a écrit :
> On Thu, Jan 6, 2011 at 5:23 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > Le vendredi 07 janvier 2011 à 02:04 +0100, Christian Lamparter a écrit :
> >> On Friday 07 January 2011 01:46:03 greearb@candelatech.com wrote:
> >> > From: Ben Greear <greearb@candelatech.com>
> >> >
> >> > Patch is from Eric Dumazet, as described here:
> >> > https://patchwork.kernel.org/patch/104271/
> >> >
> >> > Reported-by: Michael Guntsche <mike@it-loops.com>
> >> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> >> > Signed-off-by: Ben Greear <greearb@candelatech.com>
> >> > ---
> >> >
> >> > NOTE: This needs review by ath9k and/or other informed
> >> > people.
> >>
> >> Does the hardware support vector-i/o for rx (like for instance iwlagn)?
> >> Else, this change would break A-MSDU rx - which is a mandatory feature
> >> (although, not very popular) of 802.11n -
> >>
> >> See for example 802.11n-2009 9.7c:
> >>
> >> "Support for the reception of an A-MSDU, where [...], is mandatory for
> >> an HT STA"
> >>
> >> And 7.1.2 "The maximum frame body size is determined by the maximum
> >> MSDU size (2304 octets) OR the maximum A-MSDU (3839 or 7935 octets,
> >> depending upon the STA's capability), plus any overhead from security
> >> encapsulation.
> >
> > Then, only solution is to mark this broken, and perform a copy of each
> > received frame, to keep a order-1 buffer(s) allocated for hardware.
>
> -ENOTPOSSIBLE -- its an WFA requirement to RX AMSDU.
>
> > Its too easy to have memory allocation failures for high order pages and
> > freeze the card.
>
> Can't we us paged RX skbs, which mac80211 supports now?
>
> See 2f301227a1ede57504694e1f64839839f5737cac and friends.
>
Maybe you dont understand the point. A fix is needed for stable kernels.
paged RX skbs is probably a bit complex, even if copy/pasted from other
drivers.
If the hardware needs 8192 bytes (or 16384) buffers to perform its
operation, it should not give them back to linux, because there is no
guarantee it can allocate fresh ones for the next frames.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox