On 2012-10-06 1:48 AM, Adrian Chadd wrote:
On 5 October 2012 09:51, Sven Eckelmann s...@narfation.org wrote:
Well, is it a RX chainmask thing, or is it a chip thing?
It's totally possible to have an RX chainmask of say 0x2 or 0x4..
What are you trying to tell us?
That the check for rx
On 2012-10-05 1:08 PM, Sven Eckelmann wrote:
On Wednesday 03 October 2012 07:51:28 Adrian Chadd wrote:
On 2 October 2012 08:20, Felix Fietkau n...@openwrt.org wrote:
This sync cause 0x20 isn't handled anywhere and may be the cause of the
hang/crash. At least this is the symptom which can
On 2012-10-05 3:07 PM, Sven Eckelmann wrote:
On Friday 05 October 2012 14:34:28 Felix Fietkau wrote:
On 2012-10-05 1:08 PM, Sven Eckelmann wrote:
[...]
Please try this patch to see if it gets rid of these interrupts:
---
--- a/drivers/net/wireless/ath/ath9k/ani.c
+++ b/drivers/net/wireless
On 2012-10-05 5:03 PM, Sven Eckelmann wrote:
On Friday 05 October 2012 15:24:25 Felix Fietkau wrote:
On 2012-10-05 3:07 PM, Sven Eckelmann wrote:
On Friday 05 October 2012 14:34:28 Felix Fietkau wrote:
On 2012-10-05 1:08 PM, Sven Eckelmann wrote:
[...]
Please try this patch to see
On 2012-10-02 3:13 PM, Adrian Chadd wrote:
.. well, the rule here is You shouldn't get PERR/FATAL interrupts.
Haven't I posted a summary of what those errors are?
Ok. So they're signals from the PCIe core (named host1_fatal and
host1_perr. Helpfully.) Those errors occured during a DMA
On 2012-10-02 5:02 PM, Sven Eckelmann wrote:
On Tuesday 02 October 2012 07:06:03 Adrian Chadd wrote:
Hm, there are still issues on Hornet?
Yes, we still have problems with hornet. The issue I am trying to fix with
this patch is an interrupt storm on AR9330 devices with sta interface(s).
On 2012-09-14 11:47 AM, Sven Eckelmann wrote:
AR9330 and most likely other chips like AR9285 seem to get stuck completely
after they worked a long period of time in special environments. It is
currently unknown which parameters causes this problem.
Symptom of these stuck is the exposure of
On 2012-09-14 4:49 PM, Mohammed Shafi Shajakhan wrote:
From: Thomas Wagner thomas.wag...@hs-rm.de
We need to have the promiscus mode enabled for older
chipsets(i.e, rule out many frames being filtered in the
hardware itself) if 'FIF_OTHER_BSS' flag is set, when we
start the mesh mode. Fix
On 2012-09-13 6:51 PM, Simon Wunderlich wrote:
ath9k fellows,
as it seems no one could find the cause for this problem so far. I'd therefore
like to create a workaround by checking one/some registers for 0xdeadbeef and
reset the chip if this is found.
Can anyone recommend a register which
On 2012-07-23 6:19 AM, Sujith Manoharan wrote:
This can be done from userspace.
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
I think we should keep this code until we have a proper user space
replacement, I've been using it for debugging a number of times.
The qca-swiss-army-knife
On 2012-07-14 12:10 PM, Arend van Spriel wrote:
On 07/13/2012 08:52 PM, Thomas Huehn wrote:
The pointer control.sta is removed from ieee80211_tx_info to free up
sufficient
memory in SKB_CB on the tx-path to enable new annotations per data packet
e.g.
support of upcoming Transmit Power
On 2012-06-27 4:30 PM, Mohammed Shafi Shajakhan wrote:
From: Mohammed Shafi Shajakhan moham...@qca.qualcomm.com
seems i got a message like this
ath: phy0: BT_Status_Update: is_link=0, linkId=2,
state=1, SEQ=-2085766476 initially.
Signed-off-by: Mohammed Shafi Shajakhan
On 2012-06-14 4:37 AM, Stephen Donecker wrote:
Hi,
I am experiencing very high datagram loss between two identical cards
communicating over a single spacial stream in adhoc mode. Using
minstrel_ht rate control the tx bitrate settles at MCS7 150Mbps, and I
get the following iperf results.
On 2012-06-02 8:14 PM, Guido Iribarren wrote:
On Sat, Jun 2, 2012 at 2:45 PM, Johannes Berg johan...@sipsolutions.net
wrote:
The sets are mutually exclusive, and there are implied sets of each
interface with a max number of 1. So for example, in iwlwifi we don't
advertise IBSS in the
On 2012-06-01 7:22 AM, Kamran Nishat wrote:
This is the output from menuconfig for ATH9K search option. There is no
option like ATH_DEBUG or ATH_DEBUGFS.
If you enable CONFIG_PACKAGE_MAC80211_DEBUGFS (enabled by default),
ath9k debugfs support will be enabled as well.
- Felix
On 2012-05-29 12:24 PM, Josef Semler wrote:
2012/5/26 Adrian Chadd adr...@freebsd.org mailto:adr...@freebsd.org
Hi,
If the device EEPROM states that it's a 2x2/3x3 device, it'll TX on
two/three streams.
If it's something like an AR9281 where it's physically a 1T2R
On 2012-05-27 4:09 AM, Sujith Manoharan wrote:
Sujith Manoharan wrote:
Odd. I get low numbers with a DB120 running OpenWRT (git HEAD).
TCP TX - ~260 Mbps.
TCP RX - ~160 Mbps.
UDP RX - ~240 Mbps.
UDP TX - iperf borks and doesn't display anything.
The load seems to be a bit high
On 2012-05-27 7:40 PM, Adrian Chadd wrote:
On 27 May 2012 08:08, Ben Greear gree...@candelatech.com wrote:
Do you have a link to anyone selling this AP, or is it just an
engineering sample as well?
The board is an engineering sample but (a) customers and developers
can ask for them under
On 2012-05-28 1:15 AM, Adrian Chadd wrote:
Sweet. Thanks a lot for chasing that up.
What's the oprofile output look like for the AR7242 when doing that?
Haven't run oprofile on the AR7242 yet, but here's what 350Mbits/s UDP
ethernet-rx - wifi-tx traffic (bridged) looks like on AR9344:
CPU:
On 2012-05-26 9:55 AM, Josef Semler wrote:
2012/5/26 Sujith Manoharan c_man...@qca.qualcomm.com
mailto:c_man...@qca.qualcomm.com
Joe Semler wrote:
With a XB112 card (3x3) in HT40 mode, 5Ghz, TX throughput (TCP)
can reach 290 Mbps.
Sample iperf run:
[
On 2012-05-26 7:15 PM, Joe Semler wrote:
Hi Felix,
Am 26.05.2012 um 14:35 schrieb Felix Fietkau n...@openwrt.org:
OK, tnx Sujith, but that brings me to my next question acc. 2x2 or 3x3
on OpenWRT-based devices like NanoStation M or AirBridge M.
Up to now only 1x2 or 1x3 was possible
On 2012-04-23 11:12 AM, Zefir Kurtisi wrote:
On 22.04.2012 22:00, Felix Fietkau wrote:
On 2012-04-22 9:50 PM, Zefir Kurtisi wrote:
From: Zefir Kurtisizefir.kurt...@neratec.com
Signed-off-by: Zefir Kurtisizefir.kurt...@neratec.com
---
drivers/net/wireless/ath/ath9k/recv.c |6
On 2012-04-22 9:50 PM, Zefir Kurtisi wrote:
From: Zefir Kurtisi zefir.kurt...@neratec.com
Signed-off-by: Zefir Kurtisi zefir.kurt...@neratec.com
---
drivers/net/wireless/ath/ath9k/recv.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git
of
'ath9k_hw_set_txpowerlimit' by adding a new
argument to 'ath9k_hw_apply_txpower.'
Signed-off-by: Gabor Juhos juh...@openwrt.org
Cc: Felix Fietkau n...@openwrt.org
Acked-by: Felix Fietkau n...@openwrt.org
___
ath9k-devel mailing list
ath9k-devel
On 2012-04-09 5:29 PM, Michael Leun wrote:
On Mon, 9 Apr 2012 19:52:45 +0530
Mohammed Shafi shafi.wirel...@gmail.com wrote:
On Mon, Apr 9, 2012 at 7:33 PM, Michael Leun
lkml20120...@newton.leun.net wrote:
On Mon, 9 Apr 2012 12:25:49 +0200
Michael Leun lkml20120...@newton.leun.net wrote:
On 2012-04-12 5:35 PM, Michael Leun wrote:
On Thu, 12 Apr 2012 16:58:34 +0300
Felipe Contreras felipe.contre...@gmail.com wrote:
On Thu, Apr 12, 2012 at 4:46 PM, Felix Fietkau n...@openwrt.org
wrote:
On 2012-04-09 5:29 PM, Michael Leun wrote:
On Mon, 9 Apr 2012 19:52:45 +0530
Seems
On 2012-03-20 8:47 PM, Ben Greear wrote:
I'm testing out some code to get a stations's avg-signal through
ethtool-stats,
and both it and /proc/net/wireless show ranges bouncing all over
(from around -48 to -110) on an interface running heavy traffic.
Are there any known bugs in 3.3.0
On 2012-03-13 9:33 PM, Chaoxing Lin wrote:
Gentlemen,
I am running kernel 2.6.39.1 and ath9k on ath9160 radio.
The radio runs as wireless client.
It's been stable for most of the time.
But occasionally, I see error message like below. And usually after I see
this message, client
On 2012-02-29 10:35 PM, Kim Lidström wrote:
Hello!
A while ago I had a situation where my AR9485 would lock up the kernel
so bad and two very nice guys(Mohammed Shafi and Adrian.. Uhm.. Sorry I
forgot his last name) were very patient in helping me and trying to
debug it through patches, etc.
On 2012-03-07 7:37 PM, Paul Farrow wrote:
On Wed, 07 Mar 2012 18:29:56 +0100, Felix Fietkau wrote:
On 2012-02-29 10:35 PM, Kim Lidström wrote:
Hello!
A while ago I had a situation where my AR9485 would lock up the
kernel
so bad and two very nice guys(Mohammed Shafi and Adrian.. Uhm
On 2012-03-01 3:46 PM, Peter Stuge wrote:
Mohammed Shafi wrote:
disabling power save would be a nice idea, to see if this issue
disappears.
I can not understand why Atheros insists on recommending disable
power saving in response to this error which has been pouring out
of ath9k hardware
On 2012-03-01 6:53 PM, Peter Stuge wrote:
Felix Fietkau wrote:
just because the error messages are similar does not mean that it's
just one bug that has been lurking in the driver for years.
I didn't say that it's a single issue, but it's clearly a single
class of issues, and I'm surprised
On 2012-03-01 8:53 PM, Peter Stuge wrote:
Still, DMA is not exotic, and here are DMA problems again.
That last sentence makes no sense at all.
My point is that DMA by peripheral devices and the drivers to manage
it are established technologies in computer busses across the world,
On 2012-02-16 8:03 AM, Mohammed Shafi Shajakhan wrote:
From: Mohammed Shafi Shajakhanmoham...@qca.qualcomm.com
it does not seems to used for anything
Signed-off-by: Mohammed Shafi Shajakhanmoham...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/ath9k.h |1 -
On 2012-02-14 7:43 PM, Ben Greear wrote:
On 02/14/2012 10:29 AM, Sujith wrote:
Ben Greear wrote:
Actually, I think it might be useful to have a second level of debugging.
I hope to soon have time resources to add some logic to dump lots of
register
info and such in human-readable format,
On 2012-02-13 7:20 AM, Sujith Manoharan wrote:
Signed-off-by: Sujith Manoharan c_man...@qca.qualcomm.com
---
drivers/net/wireless/ath/ath9k/init.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/init.c
On 2012-02-08 8:10 PM, Adrian Chadd wrote:
Has anyone figured out why -1 is appearing?
Maybe it's fixed by the mac80211 patch I submitted today. mac80211 was
calling .tx_status on the rate control module before .rate_init.
Just a wild guess...
- Felix
On 2012-02-06 6:12 PM, Triangle Men wrote:
Hi,
I noticed the RSSI values in the receive status descriptor will occasionally
drop 11 dB below expected, calculated, historical values and then stay in
that range. Example: RSSI is in range {23,24} for a long time, then range
drops to
On 2012-01-27 4:09 PM, Zefir Kurtisi wrote:
On 01/26/2012 04:53 PM, Felix Fietkau wrote:
On 2012-01-26 4:34 PM, Zefir Kurtisi wrote:
[...]
+/**
+ * struct pattern_detector - overloading base dfs_pattern_detector
+ *
+ * @exit(): destructor
+ * @add_pulse(): add radar pulse to detector
On 2012-01-26 4:34 PM, Zefir Kurtisi wrote:
This adds a DFS pattern detector to the common ath module. It takes
pulse events reported by ath9k and reports in place whether a
pattern was detected. On detection, caller must report a radar event
to the DFS management component in the upper layer.
On 2012-01-24 11:47 AM, Daniel Halperin wrote:
Please don't top-post.
On Tue, Jan 24, 2012 at 12:31 AM, le thanh son ltso...@yahoo.com wrote:
Sorry for my late writing, since I have just read the following:
The newer
family of chipsets AR9280, AR2985, AR9287 all do not support 5 / 10 MHz
On 2012-01-02 2:13 PM, Mohammed Shafi Shajakhan wrote:
From: Mohammed Shafi Shajakhan moham...@qca.qualcomm.com
make use of the already available function 'ar9003_calc_ptr_chksum'
in 'ar9003_set_txdesc'
Signed-off-by: Mohammed Shafi Shajakhan moham...@qca.qualcomm.com
NACK. I intentionally
On 2012-01-02 3:06 PM, Mohammed Shafi Shajakhan wrote:
hi Felix,
On Monday 02 January 2012 07:11 PM, Felix Fietkau wrote:
On 2012-01-02 2:13 PM, Mohammed Shafi Shajakhan wrote:
From: Mohammed Shafi Shajakhanmoham...@qca.qualcomm.com
make use of the already available function
On 2011-12-22 12:11 PM, wireless newbie wrote:
I still haven't been able to get this thing working. But I have made
some tests on other powerpc target (mpc8315 cpu versus mpc8321 cpu on
my own target) and I can tell that this problem doesn't seem to be
related to big endian environment. Ar9390
On 2011-12-23 7:45 AM, Adrian Chadd wrote:
This sounds like noise spurs all over the place.
AGC calibration failing can be because of this.
Can you do a channel survey, or something? Felix, what can he do to
inspect the channel busy % ?
iw wlan0 survey dump
On 2011-11-23 9:14 PM, Adrian Chadd wrote:
Ok, cool. So I was right. :)
Yes, the nice solution would be to expose those aggregate frame
boundary delimiters to userland and then only marking those frames
with valid RSSI .. well, somehow.
The nicer solution would be to buffer those frames
On 2011-11-22 11:22 PM, Mohammed Shafi Shajakhan wrote:
From: Mohammed Shafi Shajakhan moham...@qca.qualcomm.com
to be used by MCI specific changes
Cc: Wilson Tsao wt...@qca.qualcomm.com
Cc: Senthil Balasubramanian senth...@qca.qualcomm.com
Signed-off-by: Rajkumar Manoharan
On 2011-11-03 2:55 PM, Zefir Kurtisi wrote:
This patch integrates the DFS module into ath9k, including
* building the module into ath9k_hw
* setting up DFS debugfs
* defining HW capability flag for DFS support
* setting this flag by DFS supporting devices
(so far:
On 2011-11-03 6:25 PM, Zefir Kurtisi wrote:
On 11/03/2011 04:51 PM, Christian Lamparter wrote:
On Thursday, November 03, 2011 02:55:53 PM Zefir Kurtisi wrote:
This patch integrates the DFS module into ath9k, including
* building the module into ath9k_hw
* setting up DFS debugfs
*
On 2011-11-03 7:01 PM, Zefir Kurtisi wrote:
Hi Felix,
while I was waiting for your feedback on my related patch, I assumed
you're okay with having those rx filter flags preserved in ath_calcrxfilter.
I did send some feedback on the rx filter preserve patch. I think it's
unnecessary and should
On 2011-11-02 1:10 PM, Zefir Kurtisi wrote:
RX filter flags previously set for DFS radar detection were not
preserved after ath9k: disable unnecessary PHY error reporting.
This patch ensures that the flags required for DFS support are
kept set.
Signed-off-by: Zefir
On 2011-11-02 6:49 PM, Daniel Golle wrote:
Hi Adrian,
On 11/02/2011 06:22 PM, Adrian Chadd wrote:
There's an antenna switch field in the EEPROM, so I take it that you
require multiple valid values? What/why would you choose between
them?
according to the OEM it's allowed to set
On 2011-10-31 9:24 PM, Adrian Chadd wrote:
On 1 November 2011 00:04, Mohammed Shafishafi.wirel...@gmail.com wrote:
On Sat, Oct 29, 2011 at 9:02 PM, David Summers
i assume if we remove the antenna in chain0, the performance will be
bad. as per my assumption tx will always happen in
On 2011-10-12 5:35 PM, Peter Stuge wrote:
would you please stop complaining and provide some help ?
It took me many months time to get an idea of the ath9k community,
and I would have appreciated tremendously if someone had explained
to me how things worked and what I could
On 2011-10-12 7:23 PM, Peter Stuge wrote:
Having detailed information about the inner workings of the
hardware is useless if you don't have a basic understanding of how
the driver works.
The two obviously go very tightly together. The more information
about both you have, the easier it is
On 2011-10-04 11:55 AM, Zefir Kurtisi wrote:
On 10/03/2011 08:26 PM, Luis R. Rodriguez wrote:
On Mon, Oct 3, 2011 at 3:29 AM, Zefir Kurtisizefir.kurt...@neratec.com
wrote:
Signed-off-by: Zefir Kurtisizefir.kurt...@neratec.com
---
drivers/net/wireless/ath/ath9k/Kconfig |7 +++
On 2011-09-28 2:07 PM, Mohammed Shafi Shajakhan wrote:
From: Mohammed Shafi Shajakhanmoham...@qca.qualcomm.com
the AR_SREV register does not seems to indicate it properly though the
other information like macVersion etc can be obtained properly
How about using AR_SREV_9300_20_OR_LATER(ah)
On 2011-08-17 1:06 PM, Bill Jordan wrote:
Prevent 8 bytes from being truncated from MGMT packets
when using TKIP.
Signed-off-by: Bill Jordanbjor...@rajant.com
---
drivers/net/wireless/ath/ath9k/recv.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git
On 2011-08-16 2:31 PM, Bill Jordan wrote:
I'm not quite sure what the correct fix is for this.
Ath9k in AP mode with a TKIP security: If a connected station sends a
management packet, the packet is truncated by 8 bytes before being
delivered to hostapd. This prevents the station from
:
return 0;
}
Any chance for an ACK from someone from Atheros on the ath9k team?
Acked-by: Felix Fietkau n...@openwrt.org
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
On 2011-08-08 1:19 PM, Bill Jordan wrote:
The first 4 hardware key indexes are reserved for WEP, but
never programmed. The result was that WEP always used
software decryption.
Signed-off-by: Bill Jordanbjor...@rajant.com
---
drivers/net/wireless/ath/key.c |8 +---
1 files
On 2011-07-19 2:42 PM, Mitar wrote:
Hi!
I have TP-Link WR741ND with OpenWrt and I cannot get current
RSSI/noise levels. /proc/net/wireless contains only zero values:
Inter-| sta-| Quality| Discarded packets | Missed |
WE
face | tus | link level noise | nwid
On 2011-07-18 12:16 AM, Kelly Hogan wrote:
Hi all,
I'm trying to get the UBNT AirRouter to work with latest ath9k and am
finding that it is failing in the ath9k_hw_wait with a timeout fail.
The ah structure appears to return it as a 9860 but 0x58d21 as the reg
value.The and with
On 2011-07-18 6:02 PM, Kelly Hogan wrote:
Thanks for the response!
This is a 9285 and similar to the UBNT Bullet M radio I believe.
root@OpenWrt:/# dmesg | grep phy
Determined physical RAM map:
ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
Registered led device: ath9k-phy0
On 12.07.2011, at 17:55, Michał Mirosław mirq-li...@rere.qmqm.pl wrote:
On Tue, Jul 12, 2011 at 12:36:06PM +0800, Felix Fietkau wrote:
On 2011-07-11 8:52 AM, Michał Mirosław wrote:
Also constify buf_addr for ath9k_hw_process_rxdesc_edma() to verify
assumptions --- dma_sync_single_for_device
On 12.07.2011, at 21:03, Michał Mirosław mirq-li...@rere.qmqm.pl wrote:
On Tue, Jul 12, 2011 at 08:54:32PM +0800, Felix Fietkau wrote:
On 12.07.2011, at 17:55, Michał Mirosław mirq-li...@rere.qmqm.pl wrote:
On Tue, Jul 12, 2011 at 12:36:06PM +0800, Felix Fietkau wrote:
On 2011-07-11 8:52 AM
On 12.07.2011, at 23:58, Michał Mirosław mirq-li...@rere.qmqm.pl wrote:
On Tue, Jul 12, 2011 at 10:21:05PM +0800, Felix Fietkau wrote:
On 12.07.2011, at 21:03, Michał Mirosław mirq-li...@rere.qmqm.pl wrote:
On Tue, Jul 12, 2011 at 08:54:32PM +0800, Felix Fietkau wrote:
On 12.07.2011, at 17
On 2011-07-11 8:52 AM, Michał Mirosław wrote:
Also constify buf_addr for ath9k_hw_process_rxdesc_edma() to verify
assumptions --- dma_sync_single_for_device() call can be removed.
Signed-off-by: Michał Mirosławmirq-li...@rere.qmqm.pl
---
drivers/net/wireless/ath/ath9k/ar9003_mac.c |4
On 2011-05-24 2:42 PM, Fabrice Deyber wrote:
This fix ensure the timers to be set at beacon interval boundaries. Without
this change timers can be set improperly resulting in the absence of beacons.
Signed-off-by: Fabrice Deyberfabricedey...@agilemesh.com
---
On 2011-05-24 1:26 AM, Fabrice Deyber wrote:
Yes Felix,
you're right that makes sense.
Should I submit a new patch?
Yes, and please also Cc linux-wirel...@vger.kernel.org and
lrodrig...@atheros.com when submitting it.
- Felix
___
ath9k-devel
On 2011-04-28 11:36 AM, Andreas Hofmann wrote:
Hello folks,
I am currently running wireless video transmissions over RTP, using 2
embedded linux devices with kernel 2.6.37 and AR9280 wireless-cards. The
link was not reliable enough and I found out that a small change to the
On 2011-04-29 3:31 PM, Andreas Hofmann wrote:
Hi Felix,
On 29.04.2011 13:20, Felix Fietkau wrote:
On 2011-04-28 11:36 AM, Andreas Hofmann wrote:
You could try using minstrel_ht instead of the ath9k rate control.
People have told me that it produces much lower PER, it might help for
both
On 2011-04-27 2:18 AM, Peter Stuge wrote:
Larry Vaden wrote:
I was refering exclusively to the ath9k code and community.
..
I look at ath9k, Felix, Adrian et al as real sw folks who have
forgotten more than I'll ever know wrt the specifics of the matter
at hand.
Yes Felix in
On 2011-04-28 2:58 AM, Joel Wiramu Pauling wrote:
WDS is crap, don't use it. You effectively half the available
bandwidth per node in a WDS network, it's a hack and is only useful if
you want coverage at the sacrifice of bandwidth of the link.
WDS doesn't cut your bandwidth in half, repeating
On 2011-04-06 4:49 PM, Larry Vaden wrote:
On Wed, Apr 6, 2011 at 9:31 AM, Felix Fietkaun...@openwrt.org wrote:
So, why is 65.0 MBit/s MCS 7 even on the table if rate control is based on
PER?
Because the assumption that lower rates always work better than higher rates
is a bad one to
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 card
On 2011-04-05 6:03 PM, Serene Gud wrote:
--- On *Tue, 4/5/11, Felix Fietkau /n...@openwrt.org/* wrote:
From: Felix Fietkau n...@openwrt.org
Subject: Re: [ath9k-devel] ath9k performance issues
To: Bernhard Walle bernh...@bwalle.de
Cc: ath9k-devel@lists.ath9k.org
Date
On 2011-04-05 6:19 PM, Bernhard Walle wrote:
Hello Felix,
* Felix Fietkaun...@openwrt.org [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 does the transmission has a high CPU utilization:
iperf
On 2011-04-05 6:54 PM, Serene Gud wrote:
On 2011-04-05 6:03 PM, Serene Gud wrote:
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
On 2011-04-05 7:52 PM, Kucherenko Valeriy wrote:
Are you using the ath9k rate control or are you using minstrel_ht? My
tests were done with minstrel_ht. You can enable it by disabling the
config option for the ath9k rate control.
- Felix
This is interesting. I have a problem with rate
On 2011-04-05 9:57 PM, Bernhard Walle wrote:
* Felix Fietkaun...@openwrt.org [2011-04-05 18:54]:
I'm using 2.6.38.1 ath9k which is at ~80 % CPU, starting from 2.6.37.1
with ~90 % CPU which was still an improvement. Do you think that
compat-wireless gives still a performance boost?
Not
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
the
On 2011-03-29 5:16 PM, Larry Vaden wrote:
On Tue, Mar 29, 2011 at 9:36 AM, Felix Fietkaun...@openwrt.org 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/*/rc_stats
And also a
On 2011-03-29 6:25 PM, Larry Vaden wrote:
On Tue, Mar 29, 2011 at 10:28 AM, Felix Fietkaun...@openwrt.org 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
well.
Please try different
On 2011-03-29 6:08 PM, Larry Vaden wrote:
On Tue, Mar 29, 2011 at 10:28 AM, Felix Fietkaun...@openwrt.org 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 interesting in the
On 2011-03-29 6:04 PM, Larry Vaden wrote:
On Tue, Mar 29, 2011 at 10:28 AM, Felix Fietkaun...@openwrt.org 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 ignorance; my intent was to
force
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:46
On 2011-03-29 7:38 PM, Larry Vaden wrote:
On Tue, Mar 29, 2011 at 12:33 PM, Felix Fietkaun...@openwrt.org 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,
Is the channel map
On 2011-03-21 6:22 AM, Mohammed Shafi wrote:
On Mon, Mar 21, 2011 at 12:56 AM, Metal Software
arsi.koutani...@metalsoftware.fi 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
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 and
information.
Thanks.
2011/2/2 Felix Fietkau n...@openwrt.org:
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
state. If you take a look at the messages, it shows that
txq-pending_frames is increasing over time
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. Seems
On 2011-01-19 2:30 AM, gree...@candelatech.com wrote:
From: Ben Greear gree...@candelatech.com
Try all xmit queues until the hardware buffers are full.
Acked-by: Felix Fietkau n...@openwrt.org
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
On 2011-01-14 6:27 PM, gree...@candelatech.com wrote:
From: Ben Greeargree...@candelatech.com
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
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 12:11 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-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
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 for
On 2011-01-09 12:46 AM, gree...@candelatech.com wrote:
From: Ben Greeargree...@candelatech.com
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
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, gree...@candelatech.com wrote:
From: Ben
101 - 200 of 260 matches
Mail list logo
