Hi,
I have two questions regarding frame aggregation in ath9k:
1. The maximum A-MPDU length I managed to get by saturating the link is
around 30 frames. How can I push the length to the theoretical limit which
is 64 frames? I am monitoring the (Average AMPDU length) in the* rc_stats*file.
2. How
Ahmad Showail wrote:
> I have two questions regarding frame aggregation in ath9k:
>
> 1. The maximum A-MPDU length I managed to get by saturating the link is around
> 30 frames. How can I push the length to the theoretical limit which is 64
> frames? I am monitoring the (Average AMPDU length) in t
On Mon, Mar 25, 2013 at 07:12:57PM -0700, Linus Torvalds wrote:
> Nothing sane worked, so I did a brute-force "let's just make
> wpa_supplicant a shell-script that adds the debug fields and then runs
> the real wpa_supplicant binary with the extra flags".
Ah, yes. I remember having done that at so
Jouni Malinen wrote:
> a clear difference in the driver interface (nl80211 vs. WEXT)
> that is being used here. This should not have really caused the
> issue since both cases used cfg80211 and same set of parameters for
> association. Anyway, that is the only clear difference..
I can confirm that
I'll get a bug together, but I wanted to report that even with the
patch above (fastcc disabled/cold reset always), it still eventually
was unable to change the channel. As soon as that failed, it's back
into the state where it never seems to xmit anything in the data
queues and can't associate.
ath9k bug created: https://bugzilla.kernel.org/show_bug.cgi?id=55771
On Tue, Mar 26, 2013 at 8:21 AM, Robert Shade wrote:
> I'll get a bug together, but I wanted to report that even with the
> patch above (fastcc disabled/cold reset always), it still eventually
> was unable to change the channel.
Ahmad Showail wrote:
> I have two questions regarding frame aggregation in ath9k:
>
> 1. The maximum A-MPDU length I managed to get by saturating the link is around
> 30 frames. How can I push the length to the theoretical limit which is 64
> frames? I am monitoring the (Average AMPDU length) in t
On Tue, 2013-03-26 at 11:58 +0200, Jouni Malinen wrote:
> On Mon, Mar 25, 2013 at 07:12:57PM -0700, Linus Torvalds wrote:
> > Nothing sane worked, so I did a brute-force "let's just make
> > wpa_supplicant a shell-script that adds the debug fields and then runs
> > the real wpa_supplicant binary wi
You also need to define CONFIG_ATH_CARDS=y
Things like this can usually easily resolved when using "make xconfig".
2013/3/26 Angela
> I am running 3.5.0-rc2 for a long time, where the ath9k was available in
> the
> kernel.
>
> I upraded and compiled the v3.8.4 kernel from
> git://git.kernel.o
On Tue, Mar 26, 2013 at 2:58 AM, Jouni Malinen wrote:
>
> If you still happen to be at the location with this AP, it could be
> useful to confirm that this kernel interface difference is indeed the
> reason by running the manual configuration case with -Dnl80211 added to
> the wpa_supplicant comma
On Tue, Mar 26, 2013 at 08:25:20AM -0700, Linus Torvalds wrote:
> Ok, added to the bugzilla. I'm still in the condo, but I'm leaving
> soon and need to pack up, so this is likely the last thing I can do..
>
> It is indeed the nl80211 part that causes problems, so I guess we're
> back to an actual
carl9170 bug created here:
https://bugzilla.kernel.org/show_bug.cgi?id=55751
On Mon, Mar 25, 2013 at 09:45:48AM -0700, Adrian Chadd wrote:
> One for each please.
>
>
>
>
> Adrian
>
>
> On 25 March 2013 09:12, Christian Lamparter wrote:
> > On Monday, March 25, 2013 03:23:53 AM Adrian Chadd
On 26 March 2013 05:21, Robert Shade wrote:
> I'll get a bug together, but I wanted to report that even with the
> patch above (fastcc disabled/cold reset always), it still eventually
> was unable to change the channel. As soon as that failed, it's back
> into the state where it never seems to xm
On Tue, Mar 26, 2013 at 12:28 PM, Adrian Chadd wrote:
> On 26 March 2013 05:21, Robert Shade wrote:
>> I'll get a bug together, but I wanted to report that even with the
>> patch above (fastcc disabled/cold reset always), it still eventually
>> was unable to change the channel. As soon as that f
On 03/26/2013 09:29 AM, Robert Shade wrote:
> On Tue, Mar 26, 2013 at 12:28 PM, Adrian Chadd wrote:
>> On 26 March 2013 05:21, Robert Shade wrote:
>>> I'll get a bug together, but I wanted to report that even with the
>>> patch above (fastcc disabled/cold reset always), it still eventually
>>> wa
On 26 March 2013 09:29, Robert Shade wrote:
>> Even after a cold reset?
>
> Yes, which is why I'm curious about the start/stop queues calls. It
> looks to my (untrained) eye that it's simply not processing the data
> queue.
Well if there's anything in the data queue once you've reset the chip
(i
On 03/26/2013 10:16 AM, Adrian Chadd wrote:
> ... and the odd thing here is that during scanning, it should be
> flushing the queues entirely so any new frame being transmitted
> _SHOULD_ result in:
>
> * TxDP for that queue being written (either FIFO or otherwise);
> * TxE for that queue being set
Right. Well, when you reset the FIFO chances are you should walk said
FIFO queue in the TXQ (not the pending frames, the "hw" frames) and
requeue each to the hardware.
What I am doing in my EDMA restart routine in FreeBSD:
* (assume TX is stopped, chip is reset, the completed frames are
already r
... and the odd thing here is that during scanning, it should be
flushing the queues entirely so any new frame being transmitted
_SHOULD_ result in:
* TxDP for that queue being written (either FIFO or otherwise);
* TxE for that queue being set.
So unless the queue is "full" already and isn't bein
On 03/26/2013 10:33 AM, Adrian Chadd wrote:
> Right. Well, when you reset the FIFO chances are you should walk said
> FIFO queue in the TXQ (not the pending frames, the "hw" frames) and
> requeue each to the hardware.
>
> What I am doing in my EDMA restart routine in FreeBSD:
>
> * (assume TX is st
Hello Holger
Thanks for pushing me in the right direction.
What struck me, was that the config's got deleted every time.
Menuconfig is terrible, used xconfig and found it immediately, thanks for
the tip.
Cheers
Angela
From: Holger Schurig [mailto:holgerschu...@gmail.com]
Sent: Tuesday, 26 Ma
Adding linux-wireless, not sure if many people read this list.
Luis
On Tue, Mar 26, 2013 at 8:40 AM, Jouni Malinen wrote:
> On Tue, Mar 26, 2013 at 08:25:20AM -0700, Linus Torvalds wrote:
>> Ok, added to the bugzilla. I'm still in the condo, but I'm leaving
>> soon and need to pack up, so this
On Tue, Mar 26, 2013 at 1:13 PM, Ben Greear wrote:
> Can you cat out the /debug/ieee80211/wiphy0/ath9k/xmit
> file when it gets in this hung state? I saw issues where
> the xmit queues got hung in our AR9380 NIC systems and
> ended up adding an ugly bit of cleanup/reset logic to
> get them workin
Think I found it: In ath_reset_internal, before we reset, we call
ath_prepare_reset, which calls ath9k_hw_disable_interrupts. If the
channel change fails, we never call ath_complete_reset, which calls
ath9k_hw_enable_interrupts.
ath9k_hw_{enable|disable}_interrupts calls definitely needs to be
b
On 25/3/2013 12:39 AM, Felix Fietkau wrote:
> On 2013-03-24 5:26 PM, Pannirselvam Kanagaratnam wrote:
>> Hello,
>>
>> My WiFi connection drops while running the AR9280 on a Freescale
>> MPC8315E platform in AP mode with hostapd. I get the following error
>> within 15 seconds and the WiFi connection
25 matches
Mail list logo
