Hello,
I'm seeing a problem with the carl driver. If I change channels
repeatedly on the 2.4ghz band, monitoring (e.g. tcpdump) will
eventually halt. I've seen this on various versions of the carl
driver/firmware (both from 1.9.4 to 1.9.7)
After monitoring has hung, changing to a 5ghz channel, causes
monitoring to resume. Bouncing the interface (ip link set mon0
down/up) also fixes it.
Here are some steps to reproduce:
# setup interface
iw wlan0 interface add mon0 type monitor
ip link set mon0 up
# start channging channels
while true ; do for i in 1 6 11 ; do iw mon0 set channel $i ; \
sleep .250 ; done ; done
In a second terminal:
tcpdump -i mon0
Wait until tcpdump stops printing. I've seen the failure rate vary
greatly, sometime minutes, sometime hours, but usually less then an
hour.
Regards,
Marco Fonseca
Hello,
On Wednesday, March 20, 2013 09:50:13 PM Marco Fonseca wrote:
> I'm seeing a problem with the carl driver. If I change channels
> repeatedly on the 2.4ghz band, monitoring (e.g. tcpdump) will
> eventually halt. I've seen this on various versions of the carl
> driver/firmware (both from 1.9.4 to 1.9.7)
thanks for reporting this. You could try either of the attached
patch and test if it alleviate the issue. If the patches do help
then the problem is caused by rf/phy (code) [which is a problem
since the rf/phy parts are taken from the vendor driver as we
have no docs or specs for it].
Regards,
Chr
--
Patch 1: just reinitialize AGC_CONTROL
(can also be moved behind CMD_FREQ_START)
---
diff --git a/drivers/net/wireless/ath/carl9170/phy.c b/drivers/net/wireless/ath/carl9170/phy.c
index b72c09c..7fffee6 100644
--- a/drivers/net/wireless/ath/carl9170/phy.c
+++ b/drivers/net/wireless/ath/carl9170/phy.c
@@ -1638,6 +1638,13 @@ int carl9170_set_channel(struct ar9170 *ar, struct ieee80211_channel *channel,
cmd = CARL9170_CMD_FREQUENCY;
}
+ err = carl9170_write_reg(ar, AR9170_PHY_REG_AGC_CONTROL,
+ carl9170_def_val(AR9170_PHY_REG_AGC_CONTROL,
+ channel->band == IEEE80211_BAND_2GHZ,
+ conf_is_ht40(&ar->hw->conf)));
+ if (err)
+ return err;
+
err = carl9170_exec_cmd(ar, CARL9170_CMD_FREQ_START, 0, NULL, 0, NULL);
if (err)
return err;
---
Patch 2: always do warm reset when changing channels
---
diff --git a/drivers/net/wireless/ath/carl9170/phy.c b/drivers/net/wireless/ath/carl9170/phy.c
index b72c09c..643cc57 100644
--- a/drivers/net/wireless/ath/carl9170/phy.c
+++ b/drivers/net/wireless/ath/carl9170/phy.c
@@ -1578,7 +1578,7 @@ int carl9170_set_channel(struct ar9170 *ar, struct ieee80211_channel *channel,
u32 cmd, tmp, offs = 0, new_ht = 0;
int err;
enum carl9170_bw bw;
- bool warm_reset;
+ bool warm_reset = true;
struct ieee80211_channel *old_channel = NULL;
bw = nl80211_to_carl(_bw);
@@ -1592,14 +1592,7 @@ int carl9170_set_channel(struct ar9170 *ar, struct ieee80211_channel *channel,
/* may be NULL at first setup */
if (ar->channel) {
old_channel = ar->channel;
- warm_reset = (old_channel->band != channel->band) ||
- (old_channel->center_freq ==
- channel->center_freq) ||
- (ar->ht_settings != new_ht);
-
ar->channel = NULL;
- } else {
- warm_reset = true;
}
/* HW workaround */
---
On Saturday 23 March 2013 21:00:38 you wrote:
> As far as I can tell those patches fixed it. I wasn't paying
> attention and applied both patches though. My environment is
> a little different today and I will test some more on Monday.
No worries. I can wait for the test results on Monday.
> If you think it would help, I can test the patches individually.
Yes. The second patch disables the "fast channel change" feature.
And this should be avoided, unless of course it is absolutely
necessary.
Regards,
Chr
As far as I can tell those patches fixed it. I wasn't paying
attention and applied both patches though. My environment
is a little different today and I will test some more on Monday.
If you think it would help, I can test the patches individually.
Thanks!
Marco
On Wed, Mar 20, 2013 at 11:09:47PM +0100, Christian Lamparter wrote:
> Hello,
>
> On Wednesday, March 20, 2013 09:50:13 PM Marco Fonseca wrote:
> > I'm seeing a problem with the carl driver. If I change channels
> > repeatedly on the 2.4ghz band, monitoring (e.g. tcpdump) will
> > eventually halt. I've seen this on various versions of the carl
> > driver/firmware (both from 1.9.4 to 1.9.7)
> thanks for reporting this. You could try either of the attached
> patch and test if it alleviate the issue. If the patches do help
> then the problem is caused by rf/phy (code) [which is a problem
> since the rf/phy parts are taken from the vendor driver as we
> have no docs or specs for it].
>
> Regards,
> Chr