On 2011-04-05 6:19 PM, Bernhard Walle wrote:
> Hello Felix,
>
> * Felix Fietkau [2011-04-05 17:59]:
>> On 2011-04-05 5:44 PM, Bernhard Walle wrote:
>> >
>> >we're using a PCIe AR9280 card on a Octeon MIPS CPU. The system
>> >that d
On 2011-04-05 6:03 PM, Serene Gud wrote:
> --- On *Tue, 4/5/11, Felix Fietkau //* wrote:
> From: Felix Fietkau
> Subject: Re: [ath9k-devel] ath9k performance issues
> To: "Bernhard Walle"
> Cc: ath9k-devel@lists.ath9k.org
> Date: Tuesday, April
On 2011-04-05 5:44 PM, Bernhard Walle wrote:
> Hello,
>
> we're using a PCIe AR9280 card on a Octeon MIPS CPU. The system
> that does the transmission has a high CPU utilization:
>
> iperf in UDP mode with 50M bandwith has ~90 % CPU utilization with a
> high softirq proportion.
>
> Using an Intel c
On 2011-03-29 7:38 PM, Larry Vaden wrote:
> On Tue, Mar 29, 2011 at 12:33 PM, Felix Fietkau wrote:
>>
>> Still very noisy and high busy time, something is causing quite a bit of
>> interference. No idea how to reduce that or track it down though.
>
> Felix and Matt,
On 2011-03-29 7:25 PM, Larry Vaden wrote:
> root@OpenWrt:~# uptime
> 00:07:40 up 7 min, load average: 0.00, 0.03, 0.04
> root@OpenWrt:~# cat /etc/config/wireless
> config wifi-device radio0
> option type mac80211
> option channel 3
> option macaddr 00:15:6d:4e:f1
On 2011-03-29 6:04 PM, Larry Vaden wrote:
> On Tue, Mar 29, 2011 at 10:28 AM, Felix Fietkau wrote:
>>> option htmode HT5
>>
>> HT5? Did you add any custom patches, or is this a configuration error?
>
> No sir; see remark about Will Rogers and ignoranc
On 2011-03-29 6:08 PM, Larry Vaden wrote:
> On Tue, Mar 29, 2011 at 10:28 AM, Felix Fietkau wrote:
>> The packet counts seem rather low, so the client is probably reconnecting
>> frequently. You should try to find out what triggers the disconnects.
>> Anything interest
On 2011-03-29 6:25 PM, Larry Vaden wrote:
> On Tue, Mar 29, 2011 at 10:28 AM, Felix Fietkau wrote:
>
>>>20% busy time with only about 5% combined rx/tx time, I guess there's some
>>> interference on the channel which might be messing with your signal as
>&g
On 2011-03-29 5:08 PM, Larry Vaden wrote:
> Felix,
>
> You can not know how appreciative this rural ISP is of your reply.
Great. I work with a few companies involved in either deploying outdoor
links or making software for it, so I'm really interested in any
feedback related to how ath9k performs
On 2011-03-29 5:16 PM, Larry Vaden wrote:
> On Tue, Mar 29, 2011 at 9:36 AM, Felix Fietkau wrote:
>>
>> In order to debug this properly, please send a dump of the rate control
>> stats of both sides:
>> cat /sys/kernel/debug/ieee80211/phy0/netdev:wlan0/stations/*
On 2011-03-29 3:33 PM, Larry Vaden wrote:
> Good morning, ath9k devs and OpenWrt-users.
>
> Please excuse the cross post, not something we normally do.
>
> We have a particularly difficult situation in which we are trying to
> achieve a stable link over 1.2 miles with the Ubiquiti M900 which uses
>
On 2011-03-21 6:22 AM, Mohammed Shafi wrote:
> On Mon, Mar 21, 2011 at 12:56 AM, Metal Software
> wrote:
>> Hi all,
>>
>> I have Atheros AR9390 WLAN PCIe Mini-Card with AR9390 chipset. Does the
>> ath9k driver support AR9390 chipset? Does anybody know difference
>> between AR9380 and AR9390 chipse
On 2011-02-26 10:37 AM, Bernhard Schmidt wrote:
> On Friday 25 February 2011 18:12:09 Luis R. Rodriguez wrote:
>> On Fri, Feb 25, 2011 at 01:37:07AM -0800, Bernhard Schmidt wrote:
>> > On Thursday, February 24, 2011 19:18:25 Luis R. Rodriguez wrote:
>> > > On Thu, Feb 24, 2011 at 01:33:18AM -0800,
; This actually regards problem when client cannot reconnect to router
>>> - in this state even though client send association and authentication
>>> requests it doesn't get response.
>>>
>>> Can these two things be related? Is there any chance ath9k ca
On 2011-02-04 9:24 PM, Ben Greear wrote:
> I wanted to see if I could increase throughput in multi-vif scenario
> by increasing the ATH_MAX_QDEPTH (by increasing ATH_TXBUF).
>
> Is this a pure software thing, or are there hardware limitations
> I should be aware of?
It's a pure software thing.
-
Please copy the patch from http://nbd.name/560-ath9k_xmit_debug.patch
into package/mac80211/patches/ in your OpenWrt build tree.
Then recompile and update the ath9k package on your AP and see if it
prints the "Aggregation session blocked..." messages when tx to the
Intel client stops working.
Tha
ode.
>
> I'll be very happy to provide any other debugging information.
> Thanks.
>
> 2011/2/2 Felix Fietkau :
>> If he's using latest OpenWrt, he already has that patch.
>> I believe that this issue has nothing to do with the queue stop/start
>> stat
t's what gets the MacBook Pro stuck in
his tests until he stops pinging with the Intel STA).
- Felix
On 2011-02-02 4:24 PM, Mohammed Shafi wrote:
> Can you please try this patch(based on the idea of suggestion of experts).
>
> commit 92460412367c00e97f99babdb898d0930ce604fc
> Auth
On 2011-02-02 8:01 AM, Nikolay Martynov wrote:
> Hi,
>
> I've got a question for you, Ben, if you do not mind.
> Can it get stuck without this error message?
>
> The reason I'm asking is that this pair (ath9k-intel5300) has
> connectivity problems which I was trying to debug with intel team
On 2011-01-24 11:33 PM, Ben Greear wrote:
> Some time back, I posted a patch to implement rx-copybreak for
> ath9k. There were some other alternative patches that implemented
> paged skbs.
>
> My patch had at least one real problem in that it needs to handle
> arbitrary busses, not just pci. See
On 2011-01-19 2:30 AM, gree...@candelatech.com wrote:
> From: Ben Greear
>
> Try all xmit queues until the hardware buffers are full.
Acked-by: Felix Fietkau
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.or
On 2011-01-14 6:27 PM, gree...@candelatech.com wrote:
> From: Ben Greear
>
> When using a mixture of AP and Station interfaces,
> the hardware mode was using the type of the
> last VIF registered. Instead, we should keep track
> of the number of different types of vifs and set the
> mode according
On 2011-01-11 9:59 AM, Bernhard Walle wrote:
> While the driver reports
>
> ath: TX streams 2, RX streams: 2
>
> in the kernel log (with ATH_DBG_CONFIG set in the debug module
> parameter), "iw list" only reported
>
> [...]
> Capabilities: 0x12ce
> HT20/HT40
>
On 2011-01-10 1:23 PM, Bill Jordan wrote:
> This routine is failing a lot on my AR9160. The ((reg& 0x7E7FFFEF) ==
> 0x00702400) test is the one that always fails. There is no debug
> messages in this path, so it may not be obvious whether others are
> experiencing the problem.
>
> This forces ath9
On 2011-01-10 12:11 AM, gree...@candelatech.com wrote:
> From: Ben Greear
>
> This saves us constantly allocating large, multi-page
> skbs. It should fix the order-1 allocation errors reported,
> and in a 60-vif scenario, this significantly decreases CPU
> utilization, and latency, and increases b
On 2011-01-09 9:39 PM, Ben Greear wrote:
> On 01/09/2011 10:19 AM, Felix Fietkau wrote:
>> On 2011-01-09 12:46 AM, gree...@candelatech.com wrote:
>>> diff --git a/drivers/net/wireless/ath/ath9k/xmit.c
>>> b/drivers/net/wireless/ath/ath9k/xmit.c
>>> inde
On 2011-01-09 1:14 PM, Christian Lamparter wrote:
> On Sunday 09 January 2011 19:13:04 Jouni Malinen wrote:
>> On Sat, Jan 08, 2011 at 04:36:23PM -0800, Ben Greear wrote:
>> > On 01/08/2011 04:20 PM, Felix Fietkau wrote:
>> > >On 2011-01-08 8:33 AM,
On 2011-01-09 12:46 AM, gree...@candelatech.com wrote:
> From: Ben Greear
>
> The system can get into a state where the xmit queue
> is stopped, but there are no packets pending, so
> the queue will not be restarted.
>
> Add logic to the xmit watchdog to attempt to restart
> the xmit logic if this
On 2011-01-09 1:07 AM, Brian Prodoehl wrote:
> This patch adds error vector magnitude collection to AR9001 and
> AR9002, as well as my best attempt at making sense of what the EVM
> numbers actually mean. There was an obvious problem with the
> AR_RxEVMn macros (parts of status4 were being used fo
On 2011-01-09 7:15 AM, Björn Smedman wrote:
> I think we should also consider the added stability/saneness with this
> patch. I for one would be willing to live with some extra cpu load if
> that means the unstoppable rx dma problem can be contained (all the
> time).
I don't think this patch has an
On 2011-01-08 5:36 PM, Ben Greear wrote:
> On 01/08/2011 04:20 PM, Felix Fietkau wrote:
>> I think this should be dependent on packet size, maybe even based on the
>> architecture. Especially on embedded hardware, copying large frames is
>> probably quite a
>&g
On 2011-01-08 8:33 AM, gree...@candelatech.com wrote:
> From: Ben Greear
>
> This saves us constantly allocating large, multi-page
> skbs. It should fix the order-1 allocation errors reported,
> and in a 60-vif scenario, this significantly decreases CPU
> utilization, and latency, and increases ba
On 2011-01-07 1:12 PM, Luis R. Rodriguez wrote:
> On Thu, Jan 06, 2011 at 08:49:12PM -0800, gree...@candelatech.com wrote:
>> From: Ben Greear
>>
>> 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 p
On 2011-01-06 5:46 PM, gree...@candelatech.com wrote:
> From: Ben Greear
>
> 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
I rea
On 2010-12-13 6:48 PM, Luis R. Rodriguez wrote:
> On Sun, Dec 12, 2010 at 05:30:31AM -0800, Felix Fietkau wrote:
>> Signed-off-by: Felix Fietkau
>
> Hey Felix, thanks a lot. These didn't apply though, do you have
> this as your top patch fro
On 2010-12-06 9:28 PM, Ben Greear wrote:
> On 12/06/2010 11:53 AM, Luis R. Rodriguez wrote:
>> On Mon, Dec 06, 2010 at 11:53:13AM -0800, Luis Rodriguez wrote:
>>> On Mon, Dec 06, 2010 at 11:47:47AM -0800, Ben Greear wrote:
On 12/06/2010 11:36 AM, Luis R. Rodriguez wrote:
> Can you cla
On 2010-12-03 9:14 AM, Ben Greear wrote:
> On 12/01/2010 03:22 PM, Ben Greear wrote:
>> On 11/29/2010 04:44 PM, Luis R. Rodriguez wrote:
>>> On Mon, Nov 29, 2010 at 04:28:51PM -0800, Ben Greear wrote:
>>
BUG: unable to handle kernel NULL pointer dereference at 0040
IP: [] ath_tx_start
On 2010-12-01 3:27 PM, Joe Perches wrote:
> On Tue, 2010-11-30 at 23:56 -0800, Luis R. Rodriguez wrote:
>> On Tue, Nov 30, 2010 at 12:19 PM, Joe Perches wrote:
>> > Poor function naming is just that.
>> > It reduces readability and the uses are counter expectation.
>> The name is perfect, we use i
On 2010-11-30 2:39 AM, Joe Perches wrote:
> On Mon, 2010-11-29 at 23:41 +0100, Felix Fietkau wrote:
>> On 2010-11-29 7:07 AM, Peter Stuge wrote:
>> > Luis R. Rodriguez wrote:
>> >> On Sun, Nov 28, 2010 at 3:53 PM, Joe Perches wrote:
>> >> > Make
On 2010-11-29 7:07 AM, Peter Stuge wrote:
> Luis R. Rodriguez wrote:
>> On Sun, Nov 28, 2010 at 3:53 PM, Joe Perches wrote:
>> > Make the function name match the function purpose.
>> > ath_debug is a debug only facility.
>> > ath_print seems too generic a name for a debug only use.
>>
>> Nack, I
On 2010-11-29 10:58 AM, Pavel Machek wrote:
>
> It seems struct eep_header lacks proper #ifdef BIG_ENDIAN_BITFIELD
> markup. eep_4k_header has proper markup, but two fields were swapped.
>
> Signed-off-by: Pavel Machek
>
> diff --git a/drivers/net/wireless/ath/ath9k/eeprom.h
> b/drivers/net/wi
On 2010-11-03 6:36 PM, Björn Smedman wrote:
> Hi all,
>
> The beacon processing in ath9k is done in a tasklet. This tasklet may race
> against beacon allocation/deallocation in process context. The patch below
> is an attempt to point out / avoid these race conditions. My hope is that
> this wi
On 2010-11-03 6:31 PM, Björn Smedman wrote:
> 2010/11/3 Felix Fietkau :
>> On 2010-11-03 5:27 PM, Björn Smedman wrote:
>>> Ok, regardless. So lets say there is a bug in mac80211 that allows a
>>> "mismatch" between header qos tid and skb queue mapping to occu
On 2010-11-03 5:27 PM, Björn Smedman wrote:
>>> It comes down to this: either we look at the header qos when we select
>>> the queue (so the above cannot happen) or we relay on mac80211 to set
>>> the header qos and the skb queue mapping in a certain way. If we
>>> choose the later I vote for a BUG
On 2010-11-03 12:35 PM, Björn Smedman wrote:
> This is one good looking patch. :) And I agree, looking at the header
> qos is good to avoid.
>
> But there is still the risk of queue selection mismatch as I see it...
> See comments below.
>
> /Björn
>> -
>> /* XXX: Remove me once we don't depend
On 2010-11-02 8:16 PM, Björn Smedman wrote:
> 2010/11/2 Felix Fietkau :
>> On 2010-11-02 7:20 PM, Björn Smedman wrote:
>>> 2010/11/2 Felix Fietkau :
>>>> + q = ath_get_mac80211_qnum(txq->axq_class, sc);
>>>>r = ath_tx_setup_buffer(hw
On 2010-11-02 7:20 PM, Björn Smedman wrote:
> 2010/11/2 Felix Fietkau :
>> + q = ath_get_mac80211_qnum(txq->axq_class, sc);
>>r = ath_tx_setup_buffer(hw, bf, skb, txctl);
>>if (unlikely(r)) {
>>ath_print(common, ATH_DBG_
On 2010-11-02 6:13 PM, Felix Fietkau wrote:
> On 2010-11-02 5:13 PM, Björn Smedman wrote:
>> Hi all,
>>
>> The following patch attempts to fix some problems with ath9k tx queue
>> selection:
>>
>> 1. There was a posible mismatch between the queue selecte
On 2010-11-02 5:13 PM, Björn Smedman wrote:
> Hi all,
>
> The following patch attempts to fix some problems with ath9k tx queue
> selection:
>
> 1. There was a posible mismatch between the queue selected for QoS packets
> (on which locking, queue start/stop and statistics where performed) and
On 2010-11-01 5:44 PM, Luis R. Rodriguez wrote:
> 2010/11/1 Björn Smedman :
>> On Mon, Nov 1, 2010 at 4:43 PM, Ben Gamari wrote:
>>> On Mon, 1 Nov 2010 16:17:23 +0100, Björn Smedman
>>> wrote:
Hi all,
I have an application that creates and destroys a lot of ap vifs and
does a
On 2010-10-29 1:36 AM, Ben Greear wrote:
> On 10/09/2010 08:23 AM, Felix Fietkau wrote:
>> On 2010-10-09 5:19 PM, Björn Smedman wrote:
>>> On Tue, Oct 5, 2010 at 9:50 PM, Luis R. Rodriguez
>>> wrote:
>>>> Felix is more familiar with this area so I&
gt;>
>
> After further investigation bad commit is :
>
> 3430098ae463e31ab16926ac3eb295368a3ca5d9 is the first bad commit
> commit 3430098ae463e31ab16926ac3eb295368a3ca5d9
> Author: Felix Fietkau
> Date: Sun Oct 10 18:21:52 2010 +0200
On 2010-10-16 12:04 AM, gree...@candelatech.com wrote:
> From: Ben Greear
>
> Otherwise, lockdep splats, at the least:
> [...]
> diff --git a/drivers/net/wireless/ath/ath9k/init.c
> b/drivers/net/wireless/ath/ath9k/init.c
> index a4c5ed4..fdc25f9 100644
> --- a/drivers/net/wireless/ath/ath9k/ini
On 2010-10-09 5:19 PM, Björn Smedman wrote:
> On Tue, Oct 5, 2010 at 9:50 PM, Luis R. Rodriguez
> wrote:
>> Felix is more familiar with this area so I'll let him chime with
>> his ACK/NACK.
>>
>> Luis
>
> So Felix, what do you think? I realize it may not be a common problem
> on any currently po
On 2010-09-22 1:51 PM, Masahiro Inoue wrote:
> Hello,
>
> The log when crashing with compat-wireless-2010-09-20 is sent.
> My kernel is 2.6.27.
>
> [ cut here ]
> kernel BUG at
> /home/miyabi/test/compat-wireless/compat-wireless-2010-09-20/drivers/net/wireless/ath/ath9k
On 2010-09-22 6:33 AM, Ben Greear wrote:
> On 09/21/2010 03:41 PM, Felix Fietkau wrote:
>> On 2010-09-21 10:19 PM, Ben Greear wrote:
>>> On 09/21/2010 12:32 PM, Felix Fietkau wrote:
>>>> On 2010-09-21 9:28 PM, Johannes Berg wrote:
>>>>> On Tue, 2
On 2010-09-21 10:19 PM, Ben Greear wrote:
> On 09/21/2010 12:32 PM, Felix Fietkau wrote:
>> On 2010-09-21 9:28 PM, Johannes Berg wrote:
>>> On Tue, 2010-09-21 at 20:00 +0200, Felix Fietkau wrote:
>>>
>>>>> Could we just poke a pointer to the STA int
On 2010-09-21 9:28 PM, Johannes Berg wrote:
> On Tue, 2010-09-21 at 20:00 +0200, Felix Fietkau wrote:
>
>> > Could we just poke a pointer to the STA into the ath_buf structure?
>
>> No, that doesn't work because of RCU.
>
> Well, it could work, if you walk all
On 2010-09-21 8:04 PM, Ben Greear wrote:
> On 09/21/2010 11:00 AM, Felix Fietkau wrote:
>> On 2010-09-21 7:25 PM, Ben Greear wrote:
>>> On 09/21/2010 05:19 AM, Felix Fietkau wrote:
>>>> On 2010-09-21 2:08 PM, Ben Greear wrote:
>>>
>>>>> If
On 2010-09-21 7:25 PM, Ben Greear wrote:
> On 09/21/2010 05:19 AM, Felix Fietkau wrote:
>> On 2010-09-21 2:08 PM, Ben Greear wrote:
>
>>> If you have any more details on this, please let me know. I'm going to
>>> attempt to fix it...I certainly have a good t
On 2010-09-21 2:08 PM, Ben Greear wrote:
> On 09/21/2010 03:10 AM, Felix Fietkau wrote:
>> On 2010-09-21 7:25 AM, Ben Greear wrote:
>>> I think I have narrowed down some problems I see when I create
>>> two STA interfaces on the same radio and associate with the
>
On 2010-09-21 10:37 AM, "Lorna González" wrote:
>
> Hello,
>
> I have some questions regarding mac80211 rate control:
>
> 1. Is minstrel the default rate control algorithm?
minstrel_ht is for 802.11n, for legacy it falls back to minstrel.
ath9k still uses its own rate control by default though
On 2010-09-21 7:25 AM, Ben Greear wrote:
> I think I have narrowed down some problems I see when I create
> two STA interfaces on the same radio and associate with the
> same AP.
>
> I'm using wireless-testing plus some patches to the rx logic
> I posted earlier.
>
> It appears that the ath9k NIC
On 2010-07-26 10:37 PM, Björn Smedman wrote:
> 2010/7/26 Felix Fietkau :
>> On 2010-07-26 9:23 PM, Björn Smedman wrote:
>>> 2010/7/26 Felix Fietkau :
>>> * When tx is aggregated most rate control probe frames end up inside
>>> aggregates and are never used fo
On 2010-07-26 9:23 PM, Björn Smedman wrote:
> 2010/7/26 Felix Fietkau :
>> On 2010-07-26 7:10 PM, Björn Smedman wrote:
>>> I think there are some (in theory) simple improvements that can be
>>> done to the tx aggregation / rate control logic. A proof of concept of
On 2010-07-26 7:10 PM, Björn Smedman wrote:
> Hi all,
>
> I've been running a lot of iperf on AR913x /
> compat-wireless-2010-07-16 (w/ openwrt/tr...@22388).
>
> I think there are some (in theory) simple improvements that can be
> done to the tx aggregation / rate control logic. A proof of concep
On 2010-07-22 12:17 AM, Björn Smedman wrote:
> Hi all,
>
> I just tried out compat-wireless-2010-07-16 on AR913x (with
> openwrt/tr...@r22321) and saw some weird performance problems.
>
> That's in exactly the same spot I was getting 16Mbps consistently with
> AP was 11n!
>
> Any debuging I can
On 2010-07-16 10:43 AM, Robert P. J. Day wrote:
>
> from drivers/net/wireless/ath/ath9k/Makefile:
>
> ath9k-$(CONFIG_ATHEROS_AR71XX) += ahb.o
>
> but there is no such config variable. so i'm thinking *something*
> should be removed.
The platform port for AR71xx hasn't been submitted upstream
On 2010-07-11 3:37 AM, Peter Stuge wrote:
> Lars Hardy wrote:
>> I have tried with 2 different Atheros chipset in AP mode, the AR5416
>> and AR9280. dd-wrt gives a stronger signal with both chipsets
>> compared with openwrt.
>>
>> I know the ath9k is under development, so my question is if this is
On 2010-06-30 12:50 AM, Björn Smedman wrote:
> 2010/6/29 Felix Fietkau :
>> I had a similar thought about the multiple invocations thing. I think
>> that's a good approach in general, but we need to ensure that we make it
>> safe.
>> The main point of this function
On 2010-06-29 11:40 PM, Björn Smedman wrote:
> 2010/6/29 Björn Smedman :
>> Yes, hw reset is due to reg = 0x01702400 every 4 - 40 seconds or so:
>> ...
>
> When the chip is really stuck, does 'reg' (at 'return false') change
> over time? If I add a second requirement that ath9k_hw_check_alive()
>
On 2010-06-29 6:36 PM, Björn Smedman wrote:
> 2010/6/29 Felix Fietkau :
>> One beacon miss should never cause a TSF reset. Only a lot of
>> consecutive beacon misses trigger a hardware reset, which then resets
>> the TSF. Looking at your log, it appears that the beacon miss i
On 2010-06-29 5:20 PM, Björn Smedman wrote:
> 2010/6/29 Felix Fietkau :
>> IMHO the most likely problem source is stuck beacons. Please compile the
>> driver with the debug option enabled and load it with
>> insmod ath9k debug=0x0100
>
> It looks like it could be:
On 2010-06-29 8:08 AM, Benoit Papillault wrote:
> Le 29/06/2010 00:55, Felix Fietkau a écrit :
>> On 2010-06-29 12:31 AM, Björn Smedman wrote:
>>> Hi all,
>>>
>>> I'm getting weird values from the debugfs file ieee80211/phy0/tsf: the
>>> value goes
On 2010-06-29 12:31 AM, Björn Smedman wrote:
> Hi all,
>
> I'm getting weird values from the debugfs file ieee80211/phy0/tsf: the
> value goes up and down rather randomly and only the lower 24 bits or
> so seem to ever be used (see below for details).
>
> The only thing running on phy0 is a singl
On 2010-06-28 12:20 PM, Björn Smedman wrote:
> 2010/6/28 Felix Fietkau :
>> On 2010-06-28 2:01 AM, Björn Smedman wrote:
> [snip]
>>> I guess the real solution is your rewrite... But in the mean time
>>> perhaps we can memcpy the tx_info control from the last su
On 2010-06-28 2:01 AM, Björn Smedman wrote:
> 2010/6/23 Felix Fietkau :
>> On 2010-06-23 6:36 PM, Björn Smedman wrote:
>>> [snip] As
>>> far as I can tell, whenever the first subframe of an aggregate fails
>>> and is software retried, the rate control fee
On 2010-06-26 8:47 AM, Alphan Ulusoy wrote:
> Dear Felix,
>
> Thank you for your reply, as I was going over the code yesterday I've
> changed several parts and also the part your first patch covers.
> However I have also felt that beacon staggering is somewhat
> problematic. I've made a total of 4
On 2010-06-25 11:07 AM, Alphan Ulusoy wrote:
> Hi,
>
> I have noticed that ATH9K does not transmit beacons in IBSS. I can
> only see probe request/response frames but no periodic beacons. I
> have even applied the patch proposed by Felix
> (https://patchwork.kernel.org/patch/99373/) that disables
On 2010-06-23 8:47 PM, Björn Smedman wrote:
> 2010/6/23 Felix Fietkau :
>> On 2010-06-23 6:36 PM, Björn Smedman wrote:
> [snip]
>>> If I'm not wrong above then the rate control feedback must also be
>>> incorrect: a disaster of that magnitude simply cannot
On 2010-06-23 6:36 PM, Björn Smedman wrote:
> 2010/3/2 Felix Fietkau :
>> On 2010-03-02 4:47 PM, Björn Smedman wrote:
>>> 2010/3/2 Felix Fietkau :
> [snip]
>>> You mean the hardware interprets the block-ack and keeps retrying the
>>> un-acked frames? I thoug
On 2010-06-16 1:32 AM, RHS Linux User wrote:
>
> Hi All,
>
> I notice that the wireless driver version in xpud works reliably,
> while the version in puppy does not? The puppy version comes up OK, but
> then dies after a short time (minutes)?
>
> I wonder if the wireless driver can (eas
On 2010-06-14 1:58 PM, Ben Gamari wrote:
> On Sat, 29 May 2010 22:16:13 -0700 (PDT), Cloud Strife
> wrote:
>> Sometimes the card stops working all together (cannot scan, connect,
>> etc.), I have to ifconfig wlan0 down; rmmod ath9k; modprobe ath9k;
>> ifconfig wlan0 up to get it started again. Th
On 2010-06-01 8:27 AM, linux_pro wrote:
> [ 30.408000] PCI error 1 at PCI addr 0x100010c0
> [ 30.408000] Data bus error, epc == 80c848bc, ra == 80c848a8
> [ 30.408000] Oops[#1]:
> [ 30.408000] Cpu 0
> [...]
Please enable CONFIG_KERNEL_KALLSYMS in your OpenWrt .config when
posting kernel cra
On 08.05.2010, at 01:59, Björn Smedman
wrote:
> On Thu, May 6, 2010 at 6:35 PM, Peter Stuge wrote:
>> I don't consider ath9k on AR5008 to be at production level for STA
>> with wireless-testing as of a week ago, but AP performance may be
>> different.
>
> I've been running ath9k in a productio
On 2010-04-05 4:11 PM, Rakesh Kumar wrote:
> Hi,
>
> I notice this parameter ATH_AMPDU_SUBFRAME_DEFAULT and in the code in
> xmit.c, function ath_tx_form_aggr limits the number of sub-frames that
> can be included in a A-MPDU to half the total size. The accompanying
> comments say:
>
>
On 2010-02-24 8:22 PM, Galen wrote:
> This is an addendum to my earlier reply.
>
> On Feb 22, 2010, at 1:09 PM, Felix Fietkau wrote:
>>>> Except for STBC, ath9k seems to have pretty much the same hardware
>>>> features as Atheros' other drivers. There may b
On 2010-02-22 8:43 PM, Galen wrote:
> On Feb 22, 2010, at 6:29 AM, Felix Fietkau wrote:
>
>>> *** Discussion *** While I realize some of my examples are rather
>>> extreme, they clearly demonstrate the huge disparity between ath9k
>>> and proprietary drive
On 2010-02-21 9:41 PM, Galen wrote:
> Hello All,
>
> I have been testing out ath9k in a variety of situations. I have
> observed it appears to have poorer handling in MIMO-intensive
> environments than the binary drivers under Mac OS X and Windows. I
> have two computers with identical radios (3x3
On 2010-02-03 9:44 AM, oii...@aol.com wrote:
>
> I use IXP425( CPU 533M, 64M RAM ) platform, OpenWrt r18530 with
> compat-wireless-2009-11-21.
> As an AP, it worked just good I could see an average throughput like
> 70~80Mbps under HT40( the throughput limited by the 100M ethernet in my
> test env
On 2010-02-03 1:27 AM, Luis R. Rodriguez wrote:
> On Tue, Feb 2, 2010 at 4:18 PM, Felix Fietkau wrote:
>> On 2010-02-03 1:08 AM, Luis R. Rodriguez wrote:
>>> We have reviewed this. The 64 value came from interoperability
>>> tests against another 802.11n device
On 2010-02-03 1:08 AM, Luis R. Rodriguez wrote:
> We have reviewed this. The 64 value came from interoperability
> tests against another 802.11n device which had increased delayed BlockAcks
> when CTS-to-self was enabled. Although this is a higher value than
> what the standard says to use we recom
On 2010-01-30 9:37 PM, Pavel Roskin wrote:
> On Sat, 2010-01-30 at 21:10 +0100, Felix Fietkau wrote:
>
>> The workaround value of '64' is actually wrong. When I had trouble
>> associating in 2.4 GHz in a case where the slot time was actually set
>> correctly, I s
On 2010-01-30 8:39 PM, Pavel Roskin wrote:
> On Sat, 2010-01-30 at 00:34 +0100, Felix Fietkau wrote:
>
>> Please try this patch and see if it helps.
>
> Yes, it worked perfectly!!!
>
> I added some debug printks, and it turns out that ah->slottime is
> negative. T
On 2010-01-30 12:05 AM, Pavel Roskin wrote:
> Hello
>
> ath9k in wireless-testing won't work in AP mode. Stations fail to
> associate:
>
> # hostapd /etc/hostapd/wlan13.conf
> Configuration file: /etc/hostapd/wlan13.conf
> Using interface wlan13 with hwaddr 00:15:6d:84:1f:37 and ssid 'mike2'
> w
On 2010-01-29 9:10 AM, Joerg Pommnitz wrote:
> --- rootki...@yahoo.it wrote:
>
>>
>> Can you try in AP-client mode? I think you'll get more
>> throughput so.
>>
>
> No, IBSS is what I'm interested in. And the point is, that there is
> a 30% performance difference between ath5k (and Madwifi) an
On 2010-01-22 11:23 PM, Luis R. Rodriguez wrote:
> Adding Ben and Cliff just to keep them in the loop.
>
> Note: this e-mail is on a public mailing list.
>
> On Fri, Jan 22, 2010 at 02:17:43PM -0800, Pavel Roskin wrote:
>> On Fri, 2010-01-22 at 19:26 +0100, Jorge Boncompte [DTI2] wrote:
>>
>> >
On 2010-01-21 2:31 PM, Carl Fürstenberg wrote:
> We are trying to setup an AP using ar9220 on wireless-testing
> (2.6.33-rc4-wl-47251-g281bca7) and fails with below error during
> association:
>
> Jan 21 14:24:36 wlan hostapd: wlan0: STA 00:04:20:1e:1f:75 IEEE 802.11:
> did not acknowledge auth
Hi Peter,
On 2010-01-11 4:03 PM, Peter Stuge wrote:
> Since I never saw this behavior in exactly the same kernel with
> another mac80211 driver (ipw2200) the problem must be in the ath9k
> driver or in my "AR5416 MAC/BB Rev:2 AR5133 RF Rev:81" hardware.
ipw2200 is not a mac80211 driver. It probabl
On 2009-12-15 2:18 PM, Ayee Goundan wrote:
> I apologize for the delay. Please use Sasi Subramaniam as your first
> point of contact for OpenWRT related questions, while cc'ing Senthil
> Balasubramanian. Sasi will coordinate appropriate help within the
> organization to provide as quick a response
201 - 300 of 302 matches
Mail list logo
