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
index d9a4144..1b3a62c 100644
--- a/drivers/net
On 2011-01-08 8:33 AM, gree...@candelatech.com wrote:
From: Ben Greeargree...@candelatech.com
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
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
bit more expensive than allocating large
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 Greeargree...@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
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 n...@openwrt.org
Hey Felix, thanks a lot. These didn't apply though, do you have
this as your top patch from upstream?
commit
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 clarify the status of
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: [f933470a]
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 j...@perches.com wrote:
Poor function naming is just that.
It reduces readability and the uses are counter expectation.
The name is perfect, we
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 p...@sysgo.com
diff --git a/drivers/net/wireless/ath/ath9k/eeprom.h
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 j...@perches.com 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-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 j...@perches.com wrote:
Make the function name match the function purpose
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 will
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
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
On 2010-11-03 6:31 PM, Björn Smedman wrote:
2010/11/3 Felix Fietkau n...@openwrt.org:
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 occur
(which in fact there is because
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 selected for QoS packets
(on which locking, queue start
On 2010-11-02 8:16 PM, Björn Smedman wrote:
2010/11/2 Felix Fietkau n...@openwrt.org:
On 2010-11-02 7:20 PM, Björn Smedman wrote:
2010/11/2 Felix Fietkau n...@openwrt.org:
+ q = ath_get_mac80211_qnum(txq-axq_class, sc);
r = ath_tx_setup_buffer(hw, bf, skb, txctl
On 2010-11-01 5:44 PM, Luis R. Rodriguez wrote:
2010/11/1 Björn Smedman bjorn.smed...@venatech.se:
On Mon, Nov 1, 2010 at 4:43 PM, Ben Gamari bgam...@gmail.com wrote:
On Mon, 1 Nov 2010 16:17:23 +0100, Björn Smedman
bjorn.smed...@venatech.se wrote:
Hi all,
I have an application that
On 2010-10-16 12:04 AM, gree...@candelatech.com wrote:
From: Ben Greear gree...@candelatech.com
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
---
On 2010-10-09 5:19 PM, Björn Smedman wrote:
On Tue, Oct 5, 2010 at 9:50 PM, Luis R. Rodriguez
lrodrig...@atheros.com 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
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, 2010-09-21 at 20:00 +0200, Felix Fietkau wrote:
Could we just poke
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
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 does
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 - but
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
same AP.
I'm using wireless-testing plus
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 test case :)
ath_tx_complete_aggr completes
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 you have any more details on this, please let me know. I'm going
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 the structures upon sta_notify and
remove
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 into the ath_buf structure?
No, that doesn't work because of RCU
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 concept of
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 do to
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
known by
On 2010-06-29 5:20 PM, Björn Smedman wrote:
2010/6/29 Felix Fietkau n...@openwrt.org:
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:
...
Jan 1 00:06
On 2010-06-29 6:36 PM, Björn Smedman wrote:
2010/6/29 Felix Fietkau n...@openwrt.org:
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 is a
symptom
On 2010-06-29 11:40 PM, Björn Smedman wrote:
2010/6/29 Björn Smedman bjorn.smed...@venatech.se:
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
On 2010-06-30 12:50 AM, Björn Smedman wrote:
2010/6/29 Felix Fietkau n...@openwrt.org:
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 is to detect baseband
On 2010-06-28 12:20 PM, Björn Smedman wrote:
2010/6/28 Felix Fietkau n...@openwrt.org:
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 subframe to
the first before
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 single ap
On 2010-06-28 2:01 AM, Björn Smedman wrote:
2010/6/23 Felix Fietkau n...@openwrt.org:
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 feedback for that aggregate
is lost
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 VEOL
On 2010-06-23 6:36 PM, Björn Smedman wrote:
2010/3/2 Felix Fietkau n...@openwrt.org:
On 2010-03-02 4:47 PM, Björn Smedman wrote:
2010/3/2 Felix Fietkau n...@openwrt.org:
[snip]
You mean the hardware interprets the block-ack and keeps retrying the
un-acked frames? I thought it stopped as soon
On 2010-06-23 8:47 PM, Björn Smedman wrote:
2010/6/23 Felix Fietkau n...@openwrt.org:
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 be conveyed to
the rate control
On 2010-06-14 1:58 PM, Ben Gamari wrote:
On Sat, 29 May 2010 22:16:13 -0700 (PDT), Cloud Strife piroisl...@yahoo.com
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
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 (easily?)
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 crash
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-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:2
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 drivers. I suspect that ath9k may have inferior MIMO
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
On 2010-02-03 1:27 AM, Luis R. Rodriguez wrote:
On Tue, Feb 2, 2010 at 4:18 PM, Felix Fietkau n...@openwrt.org 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 which had increased delayed
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. The card is Ubiquiti SR71-12, 2 GHz only
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 simply used it, because that's what
On 2010-01-29 9:10 AM, Joerg Pommnitz wrote:
--- rootki...@yahoo.it 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
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'
wlan13:
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:
Hi
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 probably
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 as
Luis R. Rodriguez wrote:
On Wed, Nov 25, 2009 at 12:29:15PM -0800, Gabor Juhos wrote:
Currently, the 2GHz band is enabled unconditionally, even if the device
does not support it.
This is true, but we don't have any 11n 5 GHz only devices,
The patch is fine too though but it'd be better if
...@openwrt.org
Cc: Felix Fietkau n...@openwrt.org
Cc: Derek Smithies de...@indranet.co.nz
Cc: Chittajit Mitra chittajit.mi...@atheros.com
Signed-off-by: Luis R. Rodriguez lrodrig...@atheros.com
---
drivers/net/wireless/ath/ath9k/rc.c| 14 +
drivers/net/wireless/iwlwifi/iwl
201 - 260 of 260 matches
Mail list logo
