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 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 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-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-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-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-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-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-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-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 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 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-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-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-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-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 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: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 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-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-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-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-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-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-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-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
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
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
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
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.
-
; 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-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,
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-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-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 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 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 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: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 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 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-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-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 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: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
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 proble
On 2011-04-05 9:57 PM, Bernhard Walle wrote:
> * Felix Fietkau [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-wirel
On 2011-04-06 4:17 PM, Larry Vaden wrote:
> On Wed, Apr 6, 2011 at 5:26 AM, Mohammed Shafi wrote:
>> On Wed, Apr 6, 2011 at 3:28 PM, Larry Vaden wrote:
>>> Mindful that we are all ignorant, just about different things, I ask
>>> the ? in the subject line.
>>>
>>> Would that not influence the
On 2011-04-06 4:49 PM, Larry Vaden wrote:
> On Wed, Apr 6, 2011 at 9:31 AM, Felix Fietkau 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 high
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
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-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
> ratecontro
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 mu
On 2011-05-23 7:22 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 absence of beacons.
>
>
> Signed-off-by: Fabrice Deyber
> ---
> drivers/net/wireless/ath/ath9k/beacon.c |2
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 m
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 Deyber
> ---
> drivers/net/wireless/ath/ath9k/beacon.c | 15 +++--
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ław
> ---
> drivers/net/wireless/ath/ath9k/ar9003_mac.c |4 ++--
> drivers/ne
On 12.07.2011, at 17:55, Michał Mirosław 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_sing
On 12.07.2011, at 21:03, Michał Mirosław wrote:
> On Tue, Jul 12, 2011 at 08:54:32PM +0800, Felix Fietkau wrote:
>> On 12.07.2011, at 17:55, Michał Mirosław wrote:
>>
>>> On Tue, Jul 12, 2011 at 12:36:06PM +0800, Felix Fietkau wrote:
>>>> On 2011-
On 12.07.2011, at 23:58, Michał Mirosław wrote:
> On Tue, Jul 12, 2011 at 10:21:05PM +0800, Felix Fietkau wrote:
>> On 12.07.2011, at 21:03, Michał Mirosław wrote:
>>
>>> On Tue, Jul 12, 2011 at 08:54:32PM +0800, Felix Fietkau wrote:
>>>> On 12.07.20
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 A
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: ath9
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 |
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 Jordan
> ---
> drivers/net/wireless/ath/key.c |8 +---
> 1 files changed, 5 insert
if (ver_minor>= AR5416_EEP_MINOR_VER_19)
>> - return pBase->txGainType;
>> - else
>> - return AR5416_EEP_TXGAIN_ORIGINAL;
>> + return pBase->txGainType;
>> default:
>> return 0;
>>
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 reau
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 Jordan
> ---
> drivers/net/wireless/ath/ath9k/recv.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/
On 2011-09-28 2:07 PM, Mohammed Shafi Shajakhan wrote:
> From: Mohammed Shafi Shajakhan
>
> 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) instead to make sure that
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 Kurtisi
>> wrote:
>>>
>>> Signed-off-by: Zefir Kurtisi
>>> ---
>>> drivers/net/wireless/ath/ath9k/Kconfig |7 +++
>>> drivers/net/wireless/ath/at
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 wh
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 easi
On 2011-10-31 9:24 PM, Adrian Chadd wrote:
> On 1 November 2011 00:04, Mohammed Shafi 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 chain0.(does we
>> have
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 Kurtisi
I think p
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 se
On 2011-11-02 7:16 PM, Daniel Golle wrote:
> On 11/02/2011 06:52 PM, Felix Fietkau wrote:
>>> I don't know the exact electronic details of the implementation, so I'd go
>>> with
>>> a list of known-to-be-good values (passed to the driver via platform-d
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: AR_SREV_92
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 debug
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 sho
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 fr
On 2011-11-22 11:22 PM, Mohammed Shafi Shajakhan wrote:
> From: Mohammed Shafi Shajakhan
>
> to be used by MCI specific changes
>
> Cc: Wilson Tsao
> Cc: Senthil Balasubramanian
> Signed-off-by: Rajkumar Manoharan
> Signed-off-by: Mohammed Shafi Shajakhan
NACK. ath_reset can no longer be cal
On 2011-11-23 10:18 PM, Mohammed Shafi Shajakhan wrote:
> Hi Felix,
>
> thanks for your review.
> On Wednesday 23 November 2011 07:59 PM, Felix Fietkau wrote:
>> On 2011-11-22 11:22 PM, Mohammed Shafi Shajakhan wrote:
>>> From: Mohammed Shafi Shajakhan
>>>
&g
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. Ar9
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 2012-01-02 2:13 PM, Mohammed Shafi Shajakhan wrote:
> From: Mohammed Shafi Shajakhan
>
> make use of the already available function 'ar9003_calc_ptr_chksum'
> in 'ar9003_set_txdesc'
>
> Signed-off-by: Mohammed Shafi Shajakhan
NACK. I intentionally did not use that function to avoid unnecessa
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 Shajakhan
>>>
>>&g
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 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
>>> chan
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 lay
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
>>> + *
>>> + *
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-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-13 7:20 AM, Sujith Manoharan wrote:
> Signed-off-by: Sujith Manoharan
> ---
> 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
> b/drivers/net/wireless/ath/ath9k/init.c
> index 5
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-rea
On 2012-02-16 8:03 AM, Mohammed Shafi Shajakhan wrote:
> From: Mohammed Shafi Shajakhan
>
> it does not seems to used for anything
>
> Signed-off-by: Mohammed Shafi Shajakhan
> ---
> drivers/net/wireless/ath/ath9k/ath9k.h |1 -
> drivers/net/wireless/ath/ath9k/recv.c |4
> 2 files
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
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 cl
On 2012-03-01 7:42 PM, Peter Stuge wrote:
> Felix Fietkau wrote:
>> Saying it's a single class of issues does not help in any way, because
>> with the issues I've fixed so far, the cause has been wildly different.
>> Sometimes software race conditions, sometimes
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
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, e
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
>>>
On 2012-03-12 6:57 AM, Mohammed Shafi Shajakhan wrote:
> From: Mohammed Shafi Shajakhan
>
> not sure if these checks are previously avoided may be those revision of
> chipsets are obselete ?
NACK. The extra checks that this patch adds have been intentionally
removed, since all earlier versions we
201 - 300 of 302 matches
Mail list logo
