There was a confusion in the usage of the bits AR5K_STA_ID1_ACKCTS_6MB and
AR5K_STA_ID1_BASE_RATE_11B. If they are set (1), we will get lower bitrates for
ACK and CTS. Therefore ath5k_hw_set_ack_bitrate_high(ah, false) actually
resulted in high bitrates, which i think is what we want anyways.
We get RXORN interrupts when all receive buffers are full. This is not
necessarily a fatal situation. It can also happen when the bus is busy or the
CPU is not fast enough to process all frames.
Older chipsets apparently need a reset to come out of this situration, but on
newer chips we can treat
hi!
i'm tempted to remove ATH5K_TRACE...
if anyone uses it please cry out now :)
i think it's not needed any more, since we now have ftrace.
bruno
___
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
Raghu Ramaraj raghu_rama...@... writes:
Hi
This is the one right...
Yes, this is the patch I meant.
--- wireless-testing/drivers/net/wireless/ath/ath5k/base.c 2010-03-19
09:55:26.0 +0100
+++ ../wireless-testing/drivers/net/wireless/ath/ath5k/base.c 2010-03-19
On Mon, Apr 12, 2010 at 4:07 AM, Bruno Randolf b...@einfach.org wrote:
hi!
i'm tempted to remove ATH5K_TRACE...
if anyone uses it please cry out now :)
i think it's not needed any more, since we now have ftrace.
Very much agreed, I wanted to do the same thing.
I have experimented with
Yes I am getting the following
r...@172.22.65.72:/home/raghu/HAL# iwlist wlan0 scan
__ratelimit: 12 callbacks suppressed
ath5k phy0: failed to warm reset the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k phy0: failed to warm reset the MAC Chip
ath5k phy0: can't reset hardware (-5)
ath5k
