* Re: ATH5k - Signal measurement reports wrong values - thanks for a fix
From: Bruno Randolf @ 2010-06-30 7:26 UTC (permalink / raw)
To: Jaroslav Fojtik; +Cc: linux-wireless, Nick Kossifidis
In-Reply-To: <4C2AEF25.1702.2DF7E2@jafojtik.seznam.cz>
On Wed June 30 2010 16:15:49 Jaroslav Fojtik wrote:
> > > Before this patch there were short peeks from -78dB to -71dB.
> > > After patch there are short measurement drops from -62dB to -70dB.
> > >
> > > The week charting simply averages it:
> > > http://78.108.103.11:11080/cgi-bin/rodga_1week_big.cgi
> >
> > i guess this must be the same situation as before, no?
>
> Just repeat:
> ## Before this patch there were short peeks from -78dB to -71dB.
>
> ## After patch there are short measurement drops from -62dB to -70dB.
i meant: did you see the same kind of drops with the older compat-wireless
versions, before you reported the problem?
> > how many antennas do you have attached to your device?
>
> One miniPCI device has only one antenna attached. Second U.FL. connector
> is empty.
>
> > it might be interesting to check if you get more consistent
> > signal measurements by disabling antenna
> > diversity, setting it to a fixed antenna. you can do this by using a
> > debugfs file "echo fixed-a > /sys/kernel/debug/ath5k/phy0/antenna" (or
> > "fixed-b")...
>
> I have found that "fixed-b" is a right connector. There is a stupid
> question why? When I am using "out" and not "aux". I just guess that "out"
> should be 'a' and 'aux' should be 'b'.
yes, i have noticed the same thing on some cards. maybe a wrong setting in
eeprom, or some bug in ath5k.
> Please again have a look at:
> http://78.108.103.11:11080/cgi-bin/rodga_1day_big.cgi
>
> It looks like signal power jumped to -46dB.
> It seems that ATH5k never switched to "fixed-b" and I has been receiving
> garbage from empty U.FL. It is a miracle that it has been worked.
i have also had problems with diversity in ath5k when there is only one
antenna attached and in this case i always need to set a fixed antenna for
optimal performance.
> MadWiFi is much more intelligent. It tests both inputs and selects better
> one.
glad to hear it works for you; i had many inconsistencies with antenna
diversity on madwifi as well..
bruno
PS: CC'ing nick, maybe he has some idea?
^ permalink raw reply
* [PATCH] ath9k_htc: Add LED support for AR7010
From: Sujith @ 2010-06-30 9:16 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/htc.h | 1 +
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 2 +
drivers/net/wireless/ath/ath9k/hw.c | 34 ++++++++++++++++++++++---
drivers/net/wireless/ath/ath9k/reg.h | 23 +++++++++++++++++
4 files changed, 56 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc.h b/drivers/net/wireless/ath/ath9k/htc.h
index 58f52a1..3756400 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -287,6 +287,7 @@ struct ath9k_debug {
#define ATH_LED_PIN_DEF 1
#define ATH_LED_PIN_9287 8
#define ATH_LED_PIN_9271 15
+#define ATH_LED_PIN_7010 12
#define ATH_LED_ON_DURATION_IDLE 350 /* in msecs */
#define ATH_LED_OFF_DURATION_IDLE 250 /* in msecs */
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 05445d8..e38ca66 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -931,6 +931,8 @@ void ath9k_init_leds(struct ath9k_htc_priv *priv)
priv->ah->led_pin = ATH_LED_PIN_9287;
else if (AR_SREV_9271(priv->ah))
priv->ah->led_pin = ATH_LED_PIN_9271;
+ else if (AR_DEVID_7010(priv->ah))
+ priv->ah->led_pin = ATH_LED_PIN_7010;
else
priv->ah->led_pin = ATH_LED_PIN_DEF;
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 1ed1440..3c76ecb 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2176,6 +2176,8 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah)
if (AR_SREV_9271(ah))
pCap->num_gpio_pins = AR9271_NUM_GPIO;
+ else if (AR_DEVID_7010(ah))
+ pCap->num_gpio_pins = AR7010_NUM_GPIO;
else if (AR_SREV_9285_10_OR_LATER(ah))
pCap->num_gpio_pins = AR9285_NUM_GPIO;
else if (AR_SREV_9280_10_OR_LATER(ah))
@@ -2316,8 +2318,15 @@ void ath9k_hw_cfg_gpio_input(struct ath_hw *ah, u32 gpio)
BUG_ON(gpio >= ah->caps.num_gpio_pins);
- gpio_shift = gpio << 1;
+ if (AR_DEVID_7010(ah)) {
+ gpio_shift = gpio;
+ REG_RMW(ah, AR7010_GPIO_OE,
+ (AR7010_GPIO_OE_AS_INPUT << gpio_shift),
+ (AR7010_GPIO_OE_MASK << gpio_shift));
+ return;
+ }
+ gpio_shift = gpio << 1;
REG_RMW(ah,
AR_GPIO_OE_OUT,
(AR_GPIO_OE_OUT_DRV_NO << gpio_shift),
@@ -2333,7 +2342,11 @@ u32 ath9k_hw_gpio_get(struct ath_hw *ah, u32 gpio)
if (gpio >= ah->caps.num_gpio_pins)
return 0xffffffff;
- if (AR_SREV_9300_20_OR_LATER(ah))
+ if (AR_DEVID_7010(ah)) {
+ u32 val;
+ val = REG_READ(ah, AR7010_GPIO_IN);
+ return (MS(val, AR7010_GPIO_IN_VAL) & AR_GPIO_BIT(gpio)) == 0;
+ } else if (AR_SREV_9300_20_OR_LATER(ah))
return MS_REG_READ(AR9300, gpio) != 0;
else if (AR_SREV_9271(ah))
return MS_REG_READ(AR9271, gpio) != 0;
@@ -2353,10 +2366,16 @@ void ath9k_hw_cfg_output(struct ath_hw *ah, u32 gpio,
{
u32 gpio_shift;
- ath9k_hw_gpio_cfg_output_mux(ah, gpio, ah_signal_type);
+ if (AR_DEVID_7010(ah)) {
+ gpio_shift = gpio;
+ REG_RMW(ah, AR7010_GPIO_OE,
+ (AR7010_GPIO_OE_AS_OUTPUT << gpio_shift),
+ (AR7010_GPIO_OE_MASK << gpio_shift));
+ return;
+ }
+ ath9k_hw_gpio_cfg_output_mux(ah, gpio, ah_signal_type);
gpio_shift = 2 * gpio;
-
REG_RMW(ah,
AR_GPIO_OE_OUT,
(AR_GPIO_OE_OUT_DRV_ALL << gpio_shift),
@@ -2366,6 +2385,13 @@ EXPORT_SYMBOL(ath9k_hw_cfg_output);
void ath9k_hw_set_gpio(struct ath_hw *ah, u32 gpio, u32 val)
{
+ if (AR_DEVID_7010(ah)) {
+ val = val ? 0 : 1;
+ REG_RMW(ah, AR7010_GPIO_OUT, ((val&1) << gpio),
+ AR_GPIO_BIT(gpio));
+ return;
+ }
+
if (AR_SREV_9271(ah))
val = ~val;
diff --git a/drivers/net/wireless/ath/ath9k/reg.h b/drivers/net/wireless/ath/ath9k/reg.h
index 47be667..633e3d9 100644
--- a/drivers/net/wireless/ath/ath9k/reg.h
+++ b/drivers/net/wireless/ath/ath9k/reg.h
@@ -882,6 +882,7 @@
#define AR_SREV_9271_11(_ah) \
(AR_SREV_9271(_ah) && \
((_ah)->hw_version.macRev == AR_SREV_REVISION_9271_11))
+
#define AR_SREV_9300(_ah) \
(((_ah)->hw_version.macVersion == AR_SREV_VERSION_9300))
#define AR_SREV_9300_20(_ah) \
@@ -896,6 +897,10 @@
(AR_SREV_9285_12_OR_LATER(_ah) && \
((REG_READ(_ah, AR_AN_SYNTH9) & 0x7) == 0x1))
+#define AR_DEVID_7010(_ah) \
+ (((_ah)->hw_version.devid == 0x7010) || \
+ ((_ah)->hw_version.devid == 0x9018))
+
#define AR_RADIO_SREV_MAJOR 0xf0
#define AR_RAD5133_SREV_MAJOR 0xc0
#define AR_RAD2133_SREV_MAJOR 0xd0
@@ -993,6 +998,7 @@ enum {
#define AR9287_NUM_GPIO 11
#define AR9271_NUM_GPIO 16
#define AR9300_NUM_GPIO 17
+#define AR7010_NUM_GPIO 16
#define AR_GPIO_IN_OUT 0x4048
#define AR_GPIO_IN_VAL 0x0FFFC000
@@ -1007,6 +1013,8 @@ enum {
#define AR9271_GPIO_IN_VAL_S 16
#define AR9300_GPIO_IN_VAL 0x0001FFFF
#define AR9300_GPIO_IN_VAL_S 0
+#define AR7010_GPIO_IN_VAL 0x0000FFFF
+#define AR7010_GPIO_IN_VAL_S 0
#define AR_GPIO_OE_OUT (AR_SREV_9300_20_OR_LATER(ah) ? 0x4050 : 0x404c)
#define AR_GPIO_OE_OUT_DRV 0x3
@@ -1015,6 +1023,21 @@ enum {
#define AR_GPIO_OE_OUT_DRV_HI 0x2
#define AR_GPIO_OE_OUT_DRV_ALL 0x3
+#define AR7010_GPIO_OE 0x52000
+#define AR7010_GPIO_OE_MASK 0x1
+#define AR7010_GPIO_OE_AS_OUTPUT 0x0
+#define AR7010_GPIO_OE_AS_INPUT 0x1
+#define AR7010_GPIO_IN 0x52004
+#define AR7010_GPIO_OUT 0x52008
+#define AR7010_GPIO_SET 0x5200C
+#define AR7010_GPIO_CLEAR 0x52010
+#define AR7010_GPIO_INT 0x52014
+#define AR7010_GPIO_INT_TYPE 0x52018
+#define AR7010_GPIO_INT_POLARITY 0x5201C
+#define AR7010_GPIO_PENDING 0x52020
+#define AR7010_GPIO_INT_MASK 0x52024
+#define AR7010_GPIO_FUNCTION 0x52028
+
#define AR_GPIO_INTR_POL (AR_SREV_9300_20_OR_LATER(ah) ? 0x4058 : 0x4050)
#define AR_GPIO_INTR_POL_VAL 0x0001FFFF
#define AR_GPIO_INTR_POL_VAL_S 0
--
1.7.1
^ permalink raw reply related
* [PATCH 1/2] mac80211: Dont allow to wake up netif tx queues while on off channel
From: Vasanthakumar Thiagarajan @ 2010-06-30 10:15 UTC (permalink / raw)
To: linville; +Cc: johannes, linux-wireless
Drivers are not supposed to call ieee80211_wake_queue() while operating
on off channel during sw scanning, but there is no clear way for
the driver to know that it is operating on off channel during scanning.
There are cases (unavailablity/availability of tx buffers in ath9k, for
example) where driver needs to stop/restart tx queues during background
scanning state, this might result in waking up the corresponding netif
tx queue when the device is on off channel which is not desired. This
patches fixes this by checking SCAN_OFF_CHANNEL bit in scanning before
restarting the tx queue.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
net/mac80211/util.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index a54cf14..1938a67 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -277,7 +277,8 @@ static void __ieee80211_wake_queue(struct ieee80211_hw *hw, int queue,
__clear_bit(reason, &local->queue_stop_reasons[queue]);
- if (local->queue_stop_reasons[queue] != 0)
+ if ((local->queue_stop_reasons[queue] != 0) ||
+ test_bit(SCAN_OFF_CHANNEL, &local->scanning))
/* someone still has this queue stopped */
return;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/2] ath9k: Call ieee80211_wake_queue() during ATH_WIPHY_SCAN state also
From: Vasanthakumar Thiagarajan @ 2010-06-30 10:15 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Along with "mac80211: Dont allow to wake up netif tx queues while on off channel"
this patch fixes a tx hang issue which shows up when starting a background scanning.
The cause for hang is a missed call to ieee80211_wake_queue() after the tx queue
was stopped due to tx buffer shortage.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/virtual.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/virtual.c b/drivers/net/wireless/ath/ath9k/virtual.c
index 89423ca..2c2f193 100644
--- a/drivers/net/wireless/ath/ath9k/virtual.c
+++ b/drivers/net/wireless/ath/ath9k/virtual.c
@@ -703,7 +703,8 @@ void ath_mac80211_start_queue(struct ath_softc *sc, u16 skb_queue)
spin_lock_bh(&sc->wiphy_lock);
/* Start the primary wiphy */
- if (sc->pri_wiphy->state == ATH_WIPHY_ACTIVE) {
+ if ((sc->pri_wiphy->state == ATH_WIPHY_ACTIVE) ||
+ (sc->pri_wiphy->state == ATH_WIPHY_SCAN)) {
ieee80211_wake_queue(hw, skb_queue);
goto unlock;
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 1/2] mac80211: Dont allow to wake up netif tx queues while on off channel
From: Johannes Berg @ 2010-06-30 10:17 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan; +Cc: linville, linux-wireless
In-Reply-To: <1277892907-2401-1-git-send-email-vasanth@atheros.com>
On Wed, 2010-06-30 at 03:15 -0700, Vasanthakumar Thiagarajan wrote:
> Drivers are not supposed to call ieee80211_wake_queue() while operating
> on off channel during sw scanning, but there is no clear way for
> the driver to know that it is operating on off channel during scanning.
> There are cases (unavailablity/availability of tx buffers in ath9k, for
> example) where driver needs to stop/restart tx queues during background
> scanning state, this might result in waking up the corresponding netif
> tx queue when the device is on off channel which is not desired. This
> patches fixes this by checking SCAN_OFF_CHANNEL bit in scanning before
> restarting the tx queue.
>
> Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
> ---
> net/mac80211/util.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/net/mac80211/util.c b/net/mac80211/util.c
> index a54cf14..1938a67 100644
> --- a/net/mac80211/util.c
> +++ b/net/mac80211/util.c
> @@ -277,7 +277,8 @@ static void __ieee80211_wake_queue(struct ieee80211_hw *hw, int queue,
>
> __clear_bit(reason, &local->queue_stop_reasons[queue]);
>
> - if (local->queue_stop_reasons[queue] != 0)
> + if ((local->queue_stop_reasons[queue] != 0) ||
> + test_bit(SCAN_OFF_CHANNEL, &local->scanning))
> /* someone still has this queue stopped */
> return;
That doesn't seem to make sense, since we treat driver and scan stop
status separately via wake_queue_by_reason()
johannes
^ permalink raw reply
* Re: [PATCH 1/2] mac80211: Dont allow to wake up netif tx queues while on off channel
From: Johannes Berg @ 2010-06-30 10:26 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan; +Cc: linville, linux-wireless
In-Reply-To: <1277893026.7823.7.camel@jlt3.sipsolutions.net>
On Wed, 2010-06-30 at 12:17 +0200, Johannes Berg wrote:
> On Wed, 2010-06-30 at 03:15 -0700, Vasanthakumar Thiagarajan wrote:
> > Drivers are not supposed to call ieee80211_wake_queue() while operating
> > on off channel during sw scanning,
> That doesn't seem to make sense, since we treat driver and scan stop
> status separately via wake_queue_by_reason()
IOW, the above assertion would seem to be false already.
johannes
^ permalink raw reply
* Re: [PATCH 1/2] mac80211: Dont allow to wake up netif tx queues while on off channel
From: Vasanthakumar Thiagarajan @ 2010-06-30 10:47 UTC (permalink / raw)
To: Johannes Berg
Cc: Vasanth Thiagarajan, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <1277893026.7823.7.camel@jlt3.sipsolutions.net>
On Wed, Jun 30, 2010 at 03:47:06PM +0530, Johannes Berg wrote:
> On Wed, 2010-06-30 at 03:15 -0700, Vasanthakumar Thiagarajan wrote:
> > Drivers are not supposed to call ieee80211_wake_queue() while operating
> > on off channel during sw scanning, but there is no clear way for
> > the driver to know that it is operating on off channel during scanning.
> > There are cases (unavailablity/availability of tx buffers in ath9k, for
> > example) where driver needs to stop/restart tx queues during background
> > scanning state, this might result in waking up the corresponding netif
> > tx queue when the device is on off channel which is not desired. This
> > patches fixes this by checking SCAN_OFF_CHANNEL bit in scanning before
> > restarting the tx queue.
> >
> > Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
> > ---
> > net/mac80211/util.c | 3 ++-
> > 1 files changed, 2 insertions(+), 1 deletions(-)
> >
> > diff --git a/net/mac80211/util.c b/net/mac80211/util.c
> > index a54cf14..1938a67 100644
> > --- a/net/mac80211/util.c
> > +++ b/net/mac80211/util.c
> > @@ -277,7 +277,8 @@ static void __ieee80211_wake_queue(struct ieee80211_hw *hw, int queue,
> >
> > __clear_bit(reason, &local->queue_stop_reasons[queue]);
> >
> > - if (local->queue_stop_reasons[queue] != 0)
> > + if ((local->queue_stop_reasons[queue] != 0) ||
> > + test_bit(SCAN_OFF_CHANNEL, &local->scanning))
> > /* someone still has this queue stopped */
> > return;
>
> That doesn't seem to make sense, since we treat driver and scan stop
> status separately via wake_queue_by_reason()
I dont know if I explained the issue properly. The issue here is
waking up the queues by driver during scan, particularly when
operating on off channel. With ath9k, there is a possibility that
ieee80211_wake_queue() can be called while moving from operational
channel (during channel set in driver). In this case driver still
needs to be allowed to clear the bit in queue_stop_reasons[] but
not wake up the tx queue.
Vasanth
^ permalink raw reply
* Re: [PATCH 1/2] mac80211: Dont allow to wake up netif tx queues while on off channel
From: Vasanthakumar Thiagarajan @ 2010-06-30 10:51 UTC (permalink / raw)
To: Johannes Berg
Cc: Vasanth Thiagarajan, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <1277893571.7823.9.camel@jlt3.sipsolutions.net>
On Wed, Jun 30, 2010 at 03:56:11PM +0530, Johannes Berg wrote:
> On Wed, 2010-06-30 at 12:17 +0200, Johannes Berg wrote:
> > On Wed, 2010-06-30 at 03:15 -0700, Vasanthakumar Thiagarajan wrote:
> > > Drivers are not supposed to call ieee80211_wake_queue() while operating
> > > on off channel during sw scanning,
>
> > That doesn't seem to make sense, since we treat driver and scan stop
> > status separately via wake_queue_by_reason()
>
> IOW, the above assertion would seem to be false already.
Sorry, I mean the existing code assumes that ieee80211_wake_queue() while
operating on off channel during scanning.
Vasanth
^ permalink raw reply
* Re: [PATCH 1/2] mac80211: Dont allow to wake up netif tx queues while on off channel
From: Vasanthakumar Thiagarajan @ 2010-06-30 10:57 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20100630105118.GB2192@vasanth-laptop>
On Wed, Jun 30, 2010 at 04:21:19PM +0530, Vasanth Thiagarajan wrote:
> On Wed, Jun 30, 2010 at 03:56:11PM +0530, Johannes Berg wrote:
> > On Wed, 2010-06-30 at 12:17 +0200, Johannes Berg wrote:
> > > On Wed, 2010-06-30 at 03:15 -0700, Vasanthakumar Thiagarajan wrote:
> > > > Drivers are not supposed to call ieee80211_wake_queue() while operating
> > > > on off channel during sw scanning,
> >
> > > That doesn't seem to make sense, since we treat driver and scan stop
> > > status separately via wake_queue_by_reason()
> >
> > IOW, the above assertion would seem to be false already.
>
> Sorry, I mean the existing code assumes that ieee80211_wake_queue() while
> operating on off channel during scanning.
I mean the existing code assumes that ieee80211_wake_queue() is not
supposed to be called while operating on off channel during
scanning as it is not right to pass packets to the drivers when
hw is on different channel.
Vasanth
^ permalink raw reply
* wl1271 firmware
From: Pazzo Da Legare @ 2010-06-30 11:26 UTC (permalink / raw)
To: linux-wireless
Hi all,
I'm looking for wl1271 firmwares. I found wl1271-fw.bin but I cannot
find wl1271-nvs.bin needed to use the wl1271's driver.
Could you please indicate where I can get it?
Thank in advance,
pz
^ permalink raw reply
* RE: wl1271 firmware
From: Levi, Shahar @ 2010-06-30 13:42 UTC (permalink / raw)
To: Pazzo Da Legare; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTinOcy-n6EVzAasAJO1I2yNeWOiaCid0tGdxnuwa@mail.gmail.com>
Hi pz,
I am checking the way to access the FW and NVS file of wl1271.
Let me find more details on that and get back to you.
Regards,
Shahar
-----Original Message-----
From: linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-owner@vger.kernel.org] On Behalf Of Pazzo Da Legare
Sent: Wednesday, June 30, 2010 2:27 PM
To: linux-wireless@vger.kernel.org
Subject: wl1271 firmware
Hi all,
I'm looking for wl1271 firmwares. I found wl1271-fw.bin but I cannot
find wl1271-nvs.bin needed to use the wl1271's driver.
Could you please indicate where I can get it?
Thank in advance,
pz
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* pull request: wireless-2.6 2010-06-30
From: John W. Linville @ 2010-06-30 18:53 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
David,
Here are a few more fixes intended for 2.6.35. Included are a couple of
small regression fixes for iwlwifi, one that causes connection stalls with
802.11n on some devices and another which could disable multicast traffic.
Also included is an ath9k fix which avoids a null pointer dereference
resulting from a timer leak.
Please let me know if there are problems!
John
---
The following changes since commit d3ead2413cb99d3e6265577b12537434e229d8c2:
Guillaume Gaudonville (1):
ixgbe: skip non IPv4 packets in ATR filter
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Johannes Berg (1):
iwlwifi: fix multicast
Vasanthakumar Thiagarajan (1):
ath9k: Fix bug in starting ani
Wey-Yi Guy (1):
iwlwifi: set TX_CMD_FLAG_PROT_REQUIRE_MSK in tx_flag
drivers/net/wireless/ath/ath9k/ath9k.h | 1 +
drivers/net/wireless/ath/ath9k/main.c | 11 ++++++++++-
drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c | 6 +-----
drivers/net/wireless/iwlwifi/iwl-core.c | 7 ++++++-
4 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index fbb7dec..5ea8773 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -445,6 +445,7 @@ void ath_deinit_leds(struct ath_softc *sc);
#define SC_OP_TSF_RESET BIT(11)
#define SC_OP_BT_PRIORITY_DETECTED BIT(12)
#define SC_OP_BT_SCAN BIT(13)
+#define SC_OP_ANI_RUN BIT(14)
/* Powersave flags */
#define PS_WAIT_FOR_BEACON BIT(0)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index abfa049..1e2a68e 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -336,6 +336,10 @@ set_timer:
static void ath_start_ani(struct ath_common *common)
{
unsigned long timestamp = jiffies_to_msecs(jiffies);
+ struct ath_softc *sc = (struct ath_softc *) common->priv;
+
+ if (!(sc->sc_flags & SC_OP_ANI_RUN))
+ return;
common->ani.longcal_timer = timestamp;
common->ani.shortcal_timer = timestamp;
@@ -872,11 +876,13 @@ static void ath9k_bss_assoc_info(struct ath_softc *sc,
/* Reset rssi stats */
sc->sc_ah->stats.avgbrssi = ATH_RSSI_DUMMY_MARKER;
+ sc->sc_flags |= SC_OP_ANI_RUN;
ath_start_ani(common);
} else {
ath_print(common, ATH_DBG_CONFIG, "Bss Info DISASSOC\n");
common->curaid = 0;
/* Stop ANI */
+ sc->sc_flags &= ~SC_OP_ANI_RUN;
del_timer_sync(&common->ani.timer);
}
}
@@ -1478,8 +1484,10 @@ static int ath9k_add_interface(struct ieee80211_hw *hw,
if (vif->type == NL80211_IFTYPE_AP ||
vif->type == NL80211_IFTYPE_ADHOC ||
- vif->type == NL80211_IFTYPE_MONITOR)
+ vif->type == NL80211_IFTYPE_MONITOR) {
+ sc->sc_flags |= SC_OP_ANI_RUN;
ath_start_ani(common);
+ }
out:
mutex_unlock(&sc->mutex);
@@ -1500,6 +1508,7 @@ static void ath9k_remove_interface(struct ieee80211_hw *hw,
mutex_lock(&sc->mutex);
/* Stop ANI */
+ sc->sc_flags &= ~SC_OP_ANI_RUN;
del_timer_sync(&common->ani.timer);
/* Reclaim beacon resources */
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c b/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c
index 44ef5d9..01658cf 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-hcmd.c
@@ -212,11 +212,7 @@ static void iwlagn_chain_noise_reset(struct iwl_priv *priv)
static void iwlagn_rts_tx_cmd_flag(struct ieee80211_tx_info *info,
__le32 *tx_flags)
{
- if ((info->control.rates[0].flags & IEEE80211_TX_RC_USE_RTS_CTS) ||
- (info->control.rates[0].flags & IEEE80211_TX_RC_USE_CTS_PROTECT))
- *tx_flags |= TX_CMD_FLG_RTS_CTS_MSK;
- else
- *tx_flags &= ~TX_CMD_FLG_RTS_CTS_MSK;
+ *tx_flags |= TX_CMD_FLG_RTS_CTS_MSK;
}
/* Calc max signal level (dBm) among 3 possible receivers */
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
index 426e955..5bbc529 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -1314,7 +1314,6 @@ void iwl_configure_filter(struct ieee80211_hw *hw,
changed_flags, *total_flags);
CHK(FIF_OTHER_BSS | FIF_PROMISC_IN_BSS, RXON_FILTER_PROMISC_MSK);
- CHK(FIF_ALLMULTI, RXON_FILTER_ACCEPT_GRP_MSK);
CHK(FIF_CONTROL, RXON_FILTER_CTL2HOST_MSK);
CHK(FIF_BCN_PRBRESP_PROMISC, RXON_FILTER_BCON_AWARE_MSK);
@@ -1329,6 +1328,12 @@ void iwl_configure_filter(struct ieee80211_hw *hw,
mutex_unlock(&priv->mutex);
+ /*
+ * Receiving all multicast frames is always enabled by the
+ * default flags setup in iwl_connection_init_rx_config()
+ * since we currently do not support programming multicast
+ * filters into the device.
+ */
*total_flags &= FIF_OTHER_BSS | FIF_ALLMULTI | FIF_PROMISC_IN_BSS |
FIF_BCN_PRBRESP_PROMISC | FIF_CONTROL;
}
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Compat-wireless release for 2010-06-30 is baked
From: Compat-wireless cronjob account @ 2010-06-30 19:02 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
4570588..85e0e99 history -> origin/history
+ 1b72384...7a6353a master -> origin/master (forced update)
5904b3b..984bc96 stable -> origin/stable
* [new tag] next-20100630 -> next-20100630
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
cat: compat_base_tree: No such file or directory
cat: compat_base_tree_version: No such file or directory
cat: compat_version: No such file or directory
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
scripts/Makefile.clean:17: /var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile: No such file or directory
make[4]: *** No rule to make target `/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile'. Stop.
make[3]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap] Error 2
make[2]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless] Error 2
make[1]: *** [_clean_/var/opt/compat/compat-wireless-2.6] Error 2
make: *** [clean] Error 2
compat-wireless code metrics
494378 - Total upstream lines of code being pulled
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-06-30
From: David Miller @ 2010-06-30 19:05 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20100630185319.GA2618@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 30 Jun 2010 14:53:20 -0400
> Here are a few more fixes intended for 2.6.35. Included are a couple of
> small regression fixes for iwlwifi, one that causes connection stalls with
> 802.11n on some devices and another which could disable multicast traffic.
> Also included is an ath9k fix which avoids a null pointer dereference
> resulting from a timer leak.
>
> Please let me know if there are problems!
...
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Pulled, thanks John.
> @@ -1329,6 +1328,12 @@ void iwl_configure_filter(struct ieee80211_hw *hw,
>
> mutex_unlock(&priv->mutex);
>
> + /*
> + * Receiving all multicast frames is always enabled by the
> + * default flags setup in iwl_connection_init_rx_config()
> + * since we currently do not support programming multicast
> + * filters into the device.
> + */
> *total_flags &= FIF_OTHER_BSS | FIF_ALLMULTI | FIF_PROMISC_IN_BSS |
> FIF_BCN_PRBRESP_PROMISC | FIF_CONTROL;
Note that this is an amazingly serious limitation.
This basically makes iwl chips unsuitable for use on networks where
real multicast use is common.
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-06-30
From: Johannes Berg @ 2010-06-30 19:15 UTC (permalink / raw)
To: David Miller; +Cc: linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <20100630.120551.170116973.davem@davemloft.net>
On Wed, 2010-06-30 at 12:05 -0700, David Miller wrote:
> > + /*
> > + * Receiving all multicast frames is always enabled by the
> > + * default flags setup in iwl_connection_init_rx_config()
> > + * since we currently do not support programming multicast
> > + * filters into the device.
> > + */
> > *total_flags &= FIF_OTHER_BSS | FIF_ALLMULTI | FIF_PROMISC_IN_BSS |
> > FIF_BCN_PRBRESP_PROMISC | FIF_CONTROL;
>
> Note that this is an amazingly serious limitation.
>
> This basically makes iwl chips unsuitable for use on networks where
> real multicast use is common.
Lots of wireless devices have this limitation unfortunately. I think we
-might- be able to have proper filters for iwl, but haven't found out
quite how yet unfortunately, if it's actually implemented properly on
the device and there's not just some fake API.
johannes
^ permalink raw reply
* Re: Compat-wireless release for 2010-06-30 is baked
From: Pavel Roskin @ 2010-06-30 19:27 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <20100630190300.056B742E2B@repository3.orbit-lab.org>
On Wed, 2010-06-30 at 15:02 -0400, Compat-wireless cronjob account
wrote:
> From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
> 4570588..85e0e99 history -> origin/history
> + 1b72384...7a6353a master -> origin/master (forced update)
> 5904b3b..984bc96 stable -> origin/stable
> * [new tag] next-20100630 -> next-20100630
> cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
> cat: compat_base_tree: No such file or directory
Luis, could you please check what is going on? There was another
announcement with error messages. Then there was a truncated message.
Now the errors are back.
I'm not sure such messages should be posted to the list. It would be
more useful to send then to those who can do something in the build
system breaks.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] ath9k: fix TSF after reset on AR913x
From: Pavel Roskin @ 2010-06-30 22:02 UTC (permalink / raw)
To: Felix Fietkau
Cc: linux-wireless, Luis R. Rodriguez, John W. Linville,
Björn Smedman
In-Reply-To: <4C2A8AD4.8070504@openwrt.org>
On Wed, 2010-06-30 at 02:07 +0200, Felix Fietkau wrote:
> + if (AR_SREV_9100(ah) && (ath9k_hw_gettsf64(ah) < tsf)) {
> + tsf += 1500;
Why 1500? Is it a magic number? It is a result of some measurement?
Can we have a define for it, please?
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Problem with firmware load on ipw2200
From: Dan Williams @ 2010-06-30 22:23 UTC (permalink / raw)
To: John W. Linville; +Cc: Larry Finger, wireless
In-Reply-To: <20100629134930.GC5296@tuxdriver.com>
On Tue, 2010-06-29 at 09:49 -0400, John W. Linville wrote:
> On Tue, Jun 29, 2010 at 08:37:21AM -0500, Larry Finger wrote:
> > I'm trying to help an ipw2200 user on the openSUSE Wireless Forum and I'm
> > stuck. The system is failing to load the firmware with error -2 (File or
> > directory not found). The difficulty is that the required files are
> > present with the correct permissions.
> >
> > What system component might be missing and/or borked to get this symptom?
>
> selinux?
Or udev; basically whatever firmware helper is registered with the
kernel for firmware request handling. Which these days I thought was
udev on most distros.
Dan
^ permalink raw reply
* Re: [PATCH] ath9k: fix TSF after reset on AR913x
From: Björn Smedman @ 2010-06-30 22:38 UTC (permalink / raw)
To: Pavel Roskin
Cc: Felix Fietkau, linux-wireless, Luis R. Rodriguez,
John W. Linville
In-Reply-To: <1277935351.17170.1.camel@mj>
On Thu, Jul 1, 2010 at 12:02 AM, Pavel Roskin <proski@gnu.org> wrote:
> On Wed, 2010-06-30 at 02:07 +0200, Felix Fietkau wrote:
>> + if (AR_SREV_9100(ah) && (ath9k_hw_gettsf64(ah) < tsf)) {
>> + tsf += 1500;
>
> Why 1500? Is it a magic number? It is a result of some measurement?
> Can we have a define for it, please?
Does the TSF always start counting from zero when the chip is reset?
In that case maybe the "magic number" can be replaced with the return
value from ath9k_hw_gettsf64() (which we call anyway).
/Björn
^ permalink raw reply
* Re: intel 5100/iwlagn bug in 2.6.35-rc2 during large file transfer
From: reinette chatre @ 2010-06-30 23:32 UTC (permalink / raw)
To: Richard Farina; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <4C296F44.9050000@gmail.com>
On Mon, 2010-06-28 at 20:57 -0700, Richard Farina wrote:
> [ 3091.463559] iwlagn 0000:02:00.0: Failed to alloc_pages with
> GFP_ATOMIC. Only 21 free buffers remaining.
> [ 3091.534626] iwlagn 0000:02:00.0: Failed to alloc_pages with
> GFP_ATOMIC. Only 0 free buffers remaining.
> [ 3593.179843] iwlagn 0000:02:00.0: Failed to alloc_pages with
> GFP_ATOMIC. Only 1 free buffers remaining.
> [ 3593.307837] iwlagn 0000:02:00.0: Failed to alloc_pages with
> GFP_ATOMIC. Only 26 free buffers remaining.
> [ 4091.542698] net_ratelimit: 34 callbacks suppressed
> [ 4091.542702] iwlagn 0000:02:00.0: Failed to alloc_pages with
> GFP_ATOMIC. Only 25 free buffers remaining.
> [ 4091.542724] iwlagn 0000:02:00.0: Failed to alloc_pages with
> GFP_ATOMIC. Only 3 free buffers remaining.
> [ 4091.555285] iwlagn 0000:02:00.0: Failed to alloc_pages with
> GFP_ATOMIC. Only 26 free buffers remaining.
> [ 4091.555305] iwlagn 0000:02:00.0: Failed to alloc_pages with
> GFP_ATOMIC. Only 0 free buffers remaining.
> [ 4258.724351] net_ratelimit: 2073 callbacks suppressed
> [ 4258.724372] iwlagn 0000:02:00.0: Failed to alloc_pages with
> GFP_ATOMIC. Only 0 free buffers remaining.
> [ 4258.753286] iwlagn 0000:02:00.0: Failed to alloc_pages with
> GFP_ATOMIC. Only 31 free buffers remaining.
> [ 4258.753309] iwlagn 0000:02:00.0: Failed to alloc_pages with
> GFP_ATOMIC. Only 2 free buffers remaining.
> [ 4258.774133] iwlagn 0000:02:00.0: Failed to alloc_pages with
> GFP_ATOMIC. Only 28 free buffers remaining.
> [ 5165.260524] net_ratelimit: 21 callbacks suppressed
> [ 5166.400305] iwlagn 0000:02:00.0: Failed to alloc_pages with
> GFP_ATOMIC. Only 4 free buffers remaining.
> [ 5167.126059] iwlagn 0000:02:00.0: Failed to alloc_pages with
> GFP_ATOMIC. Only 13 free buffers remaining.
> [ 5454.561708] net_ratelimit: 4 callbacks suppressed
> [ 5455.245019] iwlagn 0000:02:00.0: Failed to alloc_pages with
> GFP_ATOMIC. Only 1 free buffers remaining.
>
>
> I'd certainly list it as improved as it hardly freezes and those aren't
> kernel oops.
Some good news is always welcome.
> However it should be noted that this test didn't seem to
> have nearly the same speed as the previous test (which may well be due
> to my internet connection or any number of things having nothing to do
> with this patch). Point is, I'd definately like to get a faster test it
> to see if it explodes.
I do not like the idea that this is making your connection slower
though ... this could be because we are not more likely to attempt
memory allocation when there is still a large number of buffers left ...
so we do memory allocation more (too?) often.
> Assuming it doesn't, how can I help you find out
> why it keeps running out of buffers? I'm guessing this isn't expected
> behavior...
Well, the good news seems to be that your system is not running out of
memory completely ... it is just that the memory available to atomic
allocations is not enough to satisfy all requests. This really sounds
like https://bugzilla.kernel.org/show_bug.cgi?id=14141 , which has
unfortunately not been resolved yet.
Since the patch below appears to be the one making your system
slower ... could you modify the patch to set RX_LOW_WATERMARK to 64? I
know it is what we had before, but hopefully that together with the the
other changes in this patch will help to make system faster as well as
less noisy.
Thank you
Reinette
> Thanks,
> Rick Farina
>
> > >From 65c459c35332c7039cc84a980e6e04118ba81c04 Mon Sep 17 00:00:00 2001
> > From: Reinette Chatre <reinette.chatre@intel.com>
> > Date: Thu, 24 Jun 2010 10:48:59 -0700
> > Subject: [PATCH] increase low watermark
> >
> > ---
> > drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 5 +++--
> > drivers/net/wireless/iwlwifi/iwl-fh.h | 2 +-
> > 2 files changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> > index 0f292a2..2815ee7 100644
> > --- a/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> > +++ b/drivers/net/wireless/iwlwifi/iwl-agn-lib.c
> > @@ -613,7 +613,8 @@ void iwlagn_rx_allocate(struct iwl_priv *priv, gfp_t priority)
> > }
> > spin_unlock_irqrestore(&rxq->lock, flags);
> >
> > - if (rxq->free_count > RX_LOW_WATERMARK)
> > + if ((priority == GFP_ATOMIC) ||
> > + (rxq->free_count > RX_LOW_WATERMARK / 4))
> > gfp_mask |= __GFP_NOWARN;
> >
> > if (priv->hw_params.rx_page_order > 0)
> > @@ -627,7 +628,7 @@ void iwlagn_rx_allocate(struct iwl_priv *priv, gfp_t priority)
> > "order: %d\n",
> > priv->hw_params.rx_page_order);
> >
> > - if ((rxq->free_count <= RX_LOW_WATERMARK) &&
> > + if ((rxq->free_count <= RX_LOW_WATERMARK / 4) &&
> > net_ratelimit())
> > IWL_CRIT(priv, "Failed to alloc_pages with %s. Only %u free buffers remaining.\n",
> > priority == GFP_ATOMIC ? "GFP_ATOMIC" : "GFP_KERNEL",
> > diff --git a/drivers/net/wireless/iwlwifi/iwl-fh.h b/drivers/net/wireless/iwlwifi/iwl-fh.h
> > index 113c366..431bc58 100644
> > --- a/drivers/net/wireless/iwlwifi/iwl-fh.h
> > +++ b/drivers/net/wireless/iwlwifi/iwl-fh.h
> > @@ -426,7 +426,7 @@
> > * RX related structures and functions
> > */
> > #define RX_FREE_BUFFERS 64
> > -#define RX_LOW_WATERMARK 8
> > +#define RX_LOW_WATERMARK 128
> >
> > /* Size of one Rx buffer in host DRAM */
> > #define IWL_RX_BUF_SIZE_3K (3 * 1000) /* 3945 only */
> >
>
^ permalink raw reply
* Re: [PATCH] ath9k: fix TSF after reset on AR913x
From: Felix Fietkau @ 2010-07-01 0:45 UTC (permalink / raw)
To: Pavel Roskin
Cc: linux-wireless, Luis R. Rodriguez, John W. Linville,
Björn Smedman
In-Reply-To: <1277935351.17170.1.camel@mj>
On 2010-07-01 12:02 AM, Pavel Roskin wrote:
> On Wed, 2010-06-30 at 02:07 +0200, Felix Fietkau wrote:
>> + if (AR_SREV_9100(ah) && (ath9k_hw_gettsf64(ah) < tsf)) {
>> + tsf += 1500;
>
> Why 1500? Is it a magic number? It is a result of some measurement?
> Can we have a define for it, please?
The comment right above already explains it. This is the 'offset based
on measured time difference'
- Felix
^ permalink raw reply
* Re: [PATCH] ath9k: fix TSF after reset on AR913x
From: Felix Fietkau @ 2010-07-01 0:47 UTC (permalink / raw)
To: Björn Smedman
Cc: Pavel Roskin, linux-wireless, Luis R. Rodriguez, John W. Linville
In-Reply-To: <AANLkTim8NrVZfcJGi4NK_OhXBxEY0Lw9fdg1bcbzDU0X@mail.gmail.com>
On 2010-07-01 12:38 AM, Björn Smedman wrote:
> On Thu, Jul 1, 2010 at 12:02 AM, Pavel Roskin <proski@gnu.org> wrote:
>> On Wed, 2010-06-30 at 02:07 +0200, Felix Fietkau wrote:
>>> + if (AR_SREV_9100(ah) && (ath9k_hw_gettsf64(ah) < tsf)) {
>>> + tsf += 1500;
>>
>> Why 1500? Is it a magic number? It is a result of some measurement?
>> Can we have a define for it, please?
>
> Does the TSF always start counting from zero when the chip is reset?
> In that case maybe the "magic number" can be replaced with the return
> value from ath9k_hw_gettsf64() (which we call anyway).
No, the TSF value at this point is not accurate. It differs
semi-randomly by a few orders of magnitude from the time measured by the
CPU timer. The value I put in above is just an approximation, but since
making it completely accurate is impossible, I figured this is good
enough, especially since the value will most likely not deviate much
from what I've measured here.
- Felix
^ permalink raw reply
* rfkill failure in 2.6.35-rc3+
From: Andrew Lutomirski @ 2010-07-01 2:59 UTC (permalink / raw)
To: linux-wireless, ilw
I just toggled rfkill on and back off on my X200s (WiFi Link 5350, rev
0x24) and the link didn't come up. Toggling rfkill again didn't fix
it, but rmmod + modprobe did.
dmesg said:
[13629.424869] iwlagn 0000:03:00.0: RF_KILL bit toggled to disable radio.
[13629.432761] iwlagn 0000:03:00.0: Not sending command - RF KILL
[13629.432771] iwlagn 0000:03:00.0: Error sending REPLY_RXON:
enqueue_hcmd failed: -5
[13629.432778] iwlagn 0000:03:00.0: Error setting new RXON (-5)
[13631.268646] iwlagn 0000:03:00.0: RF_KILL bit toggled to enable radio.
[13631.311232] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[13675.710821] iwlagn 0000:03:00.0: RF_KILL bit toggled to disable radio.
[13675.713438] iwlagn 0000:03:00.0: Not sending command - RF KILL
[13675.713448] iwlagn 0000:03:00.0: Error sending REPLY_RXON:
enqueue_hcmd failed: -5
[13675.713455] iwlagn 0000:03:00.0: Error setting new RXON (-5)
[13683.090789] iwlagn 0000:03:00.0: RF_KILL bit toggled to enable radio.
[13683.145267] ADDRCONF(NETDEV_UP): wlan0: link is not ready
This is 2.6.35-rc3+ with firmware 8.24.2.12. I've never seen this before.
^ permalink raw reply
* Re: issues while attempting ath9k_htc to work with ubuntu 10.04, device TL-WN721N
From: c0rrupt @ 2010-06-30 21:59 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4C1078D4.3070604@yatharthgupta.com>
Yatharth <y <at> yatharthgupta.com> writes:
********
Yeah I have same problem on Ubuntu 10.04. make install, everything ok no errors,
restart PC and I have same error messages as you. Any one have solution?
^ permalink raw reply
* Re: [PATCH] ath9k: fix TSF after reset on AR913x
From: Johannes Berg @ 2010-07-01 6:39 UTC (permalink / raw)
To: Felix Fietkau
Cc: Björn Smedman, Pavel Roskin, linux-wireless,
Luis R. Rodriguez, John W. Linville
In-Reply-To: <4C2BE5A8.9030003@openwrt.org>
On Thu, 2010-07-01 at 02:47 +0200, Felix Fietkau wrote:
> No, the TSF value at this point is not accurate. It differs
> semi-randomly by a few orders of magnitude from the time measured by the
> CPU timer. The value I put in above is just an approximation, but since
> making it completely accurate is impossible, I figured this is good
> enough, especially since the value will most likely not deviate much
> from what I've measured here.
Are you sure it doesn't depend on CPU speed as well since the driver is
involved here? Or DMA speed?
johannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox