* Re[8]: cfg80211 and rfkill_backport question.
From: Nikolai ZHUBR @ 2009-09-16 22:11 UTC (permalink / raw)
To: linux-wireless
Cc: Hin-Tak Leung, Luis R. Rodriguez, Gaurav Jauhar,
Senthil Balasubramanian
In-Reply-To: <3ace41890909160824w146d63e6haddabe645d3e27d2@mail.gmail.com>
Wednesday, September 16, 2009, 6:24:11 PM, Hin-Tak Leung wrote:
>> From what I checked it all looks fine to me, except that there is
>> a circular dependency between cfg80211 and rfkill_backport (which
>> is confirmed by nm output I suppose). Is this circular dependency
>> intentional? Or, could it be avoided? (My understanding was that
>> as module loader loads one file at a time, it just have no way
>> to resolve such symbols, maybe I'm wrong on this)
> Hmm, yes and no... insmod loads modules one at a time; but as long as
> you run depmod, modprobe loads dependent modules automatically. I
> don't know if modprobe works for circular dependency, but it probably
> works correctly (since AFAIK, it reference-counts)?
Well, maybe modprobe is smart enough these days already, but openwrt
doesn't have it.
Anyway.
Circular dependency issue is now gone together with rfkill_backport
as I don't need rfkill at this point.
"Unable to reserve mem region" error was probably MIPS-related or
PCI-related and gone after cold reboot.
Now here is another:
in function wiphy_register (net/wireless/core.c):
device_add returns an error (-22)
Looks like some problem in mac80211<-->kernel_2.6.25 communication?
regards,
Nikolai
^ permalink raw reply
* Re: [PATCH 2/2] b43: Add lpphy_clear_tx_power_offsets to improve TX Power handling
From: Thomas Ilnseher @ 2009-09-16 21:00 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John Linville, Broadcom Wireless, linux-wireless, Larry Finger
In-Reply-To: <69e28c910909161344h511bcddeqcdc82b2e8a734dbb@mail.gmail.com>
>
> Put a printk here to see if this branch is getting hit.
>
> (BTW, are you loading b43 with the "hwpctl" modparam? That enables
> experimental HW TX power control support, which might explain what you
> were seeing.)
Hi Gabor,
I'm stupid.
I applied 3 Patches, the analog switch patch, and the other two patches.
The analog switch patch did it.
> >>
> >>
> >
> >
>
>
>
^ permalink raw reply
* Re: [PATCH 2/2] b43: Add lpphy_clear_tx_power_offsets to improve TX Power handling
From: Michael Buesch @ 2009-09-16 21:00 UTC (permalink / raw)
To: bcm43xx-dev
Cc: Thomas Ilnseher, Gábor Stefanik, Larry Finger,
linux-wireless
In-Reply-To: <1253132275.2989.75.camel@note>
On Wednesday 16 September 2009 22:17:55 Thomas Ilnseher wrote:
> Am Mittwoch, den 16.09.2009, 21:40 +0200 schrieb Gábor Stefanik:
> > You are essentially implementing dead code at this point - this will
> > only ever be called if hardware-accelerated TX power control is
> > enabled - and HW TX power control is unsupported, even for G-PHYs.
> Then the question remains, why this brings my device to 54 MBit/s ?
>
> I did double check again with the old driver:
>
> wlan0 IEEE 802.11bg ESSID:"tommy"
> Mode:Managed Frequency:2.412 GHz Access Point:
> Bit Rate=9 Mb/s Tx-Power=20 dBm
> Retry long limit:7 RTS thr:off Fragment thr:off
> Encryption key:off
> Power Management:off
> Link Quality=70/70 Signal level=5 dBm
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>
> Patched driver:
>
> wlan0 IEEE 802.11bg ESSID:"tommy"
> Mode:Managed Frequency:2.412 GHz Access Point: XXX
> Bit Rate=54 Mb/s Tx-Power=20 dBm
> Retry long limit:7 RTS thr:off Fragment thr:off
> Encryption key:off
> Power Management:off
> Link Quality=70/70 Signal level=10 dBm
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
The iwconfig output doesn't tell you anything about the actual net TX rate.
Please benchmark it with iperf.
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH] libertas: Add auto deep sleep support for SD8385/SD8686/SD8688
From: Andrey Yurovsky @ 2009-09-16 20:47 UTC (permalink / raw)
To: Bing Zhao
Cc: libertas-dev@lists.infradead.org, linux-wireless@vger.kernel.org,
Amitkumar Karwar, Dan Williams
In-Reply-To: <477F20668A386D41ADCC57781B1F704306DB9CFDB7@SC-VEXCH1.marvell.com>
On Wed, Sep 16, 2009 at 1:20 PM, Bing Zhao <bzhao@marvell.com> wrote:
> Hi Andrey,
>
>> -----Original Message-----
>> From: Andrey Yurovsky [mailto:andrey@cozybit.com]
>> Sent: Tuesday, September 15, 2009 4:41 PM
>> To: Bing Zhao
>> Cc: libertas-dev@lists.infradead.org; linux-wireless@vger.kernel.org; Amitkumar Karwar; Dan Williams
>> Subject: Re: [PATCH] libertas: Add auto deep sleep support for SD8385/SD8686/SD8688
>>
>> Hi Bing. This is not specific to the actual implementation of the
>> deep sleep commands in your patch but,
>>
>> On Tue, Sep 15, 2009 at 4:45 PM, Bing Zhao <bzhao@marvell.com> wrote:
>> > + Path: /sys/kernel/debug/libertas_wireless/ethX/
>>
>> Is the sysfs interface really necessary? It seems like yet another
>> non-standard configuration option to keep track of.
>
> Actually the debugfs interface is used in the patch.
>
> Some information (such as the interface name and path) in README file is out of date. We just copy-and-paste it for the new deepsleep command. We need a separate patch to clean up the REAME file and keep it up to date.
Ok. Either way, this is another out-of-band interface (regardless of
if it's debugfs or sysfs). That said, I believe that debugfs should
be used for debugging, not for configuring driver/device features like
these.
>> Deep sleep seems to pretty much "turn off" the wifi card (as far as
>> the user is concerned) so how about a simpler approach: enter deep
>> sleep when the interface is brought down (ifconfig wlanN down) and
>> exit deep sleep when it's brought up. Do this only when deep sleep is
>> supported/possible. Alternately, maybe this belongs as an rfkill
>> feature?
>
> Entering/exiting deep sleep doesn't have to depend on wlanN interface's up and down. User can still put the chip into sleep when wlanN is up. And, with auto deep sleep feature, the driver automatically wakes the chip up for sending user commands (for example, scan) and put the chip back to sleep after certain time period of inactivity. The deepsleep command through debugfs interface provides the flexibility of deep sleep options.
>
> The rfkill shuts down the RF transmitter of the device but most of other modules may be still functioning. The deep sleep shuts down most of the modules (including the RF) on the chip to save as much power as possible.
It seems that when the device is in deep sleep, it's effectively
"turned off" as far as the user is concerned. That seems really
similar to "ifconfig down" or rfkill, does the user really care about
anything beyond that? I understand that it's possible to control this
feature independently of either of those functions, but is it ever
necessary? If not, it would be great to just integrate it into one
(or both) of these already standard network interface semantics and
not introduce a whole new configuration parameter.
-Andrey
> Regards,
>
> Bing
>
>>
>> -Andrey
>
^ permalink raw reply
* pull request: wireless-next-2.6 2009-09-16
From: John W. Linville @ 2009-09-16 20:41 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here is a batch of fixes for 2.6.32...nothing too controversial
AFAICT...
Please let me know if there are problems!
John
---
Individual patches are available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-next-2.6/
---
The following changes since commit 13af7a6ea502fcdd4c0e3d7de6e332b102309491:
Dhananjay Phadke (1):
netxen: update copyright
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6.git master
Christian Lamparter (1):
p54usb: add Zcomax XG-705A usbid
Daniel C Halperin (1):
iwlwifi: fix HT operation in 2.4 GHz band
Holger Schurig (2):
cfg80211: use cfg80211_wext_freq() for freq conversion
cfg80211: minimal error handling for wext-compat freq scanning
Johannes Berg (2):
iwlwifi: disable powersave for 4965
cfg80211: fix SME connect
Larry Finger (1):
ssb: Fix error when V1 SPROM extraction is forced
Luis R. Rodriguez (1):
wireless: default CONFIG_WLAN to y
Martin Decky (1):
hostap: Revert a toxic part of the conversion to net_device_ops
Michael Buesch (3):
b43: Force-wake queues on init
ssb: Disable verbose SDIO coreswitch
b43: Fix resume failure
Pavel Roskin (1):
rc80211_minstrel: fix contention window calculation
Randy Dunlap (1):
ssb/sdio: fix printk format warnings
Reinette Chatre (1):
iwlwifi: fix potential rx buffer loss
Sujith (1):
ath9k: Fix bug in ANI channel handling
Wey-Yi Guy (1):
iwlwifi: find the correct first antenna
drivers/net/wireless/Kconfig | 1 +
drivers/net/wireless/ath/ath9k/ani.c | 6 ++++--
drivers/net/wireless/b43/main.c | 8 +++-----
drivers/net/wireless/hostap/hostap_main.c | 3 ++-
drivers/net/wireless/iwlwifi/iwl-4965.c | 1 +
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 10 +++++++++-
drivers/net/wireless/iwlwifi/iwl-core.c | 9 ++++++---
drivers/net/wireless/iwlwifi/iwl-core.h | 1 +
drivers/net/wireless/iwlwifi/iwl-power.c | 5 +++--
drivers/net/wireless/iwlwifi/iwl-rx.c | 24 +++++++++++++++++-------
drivers/net/wireless/iwlwifi/iwl3945-base.c | 24 ++++++++++++++++--------
drivers/net/wireless/p54/p54usb.c | 1 +
drivers/ssb/pci.c | 1 +
drivers/ssb/sdio.c | 6 +++---
net/mac80211/rc80211_minstrel.c | 2 +-
net/wireless/scan.c | 7 ++++++-
net/wireless/sme.c | 21 +++++++++++++--------
17 files changed, 88 insertions(+), 42 deletions(-)
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index ad89d23..49ea9c9 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -5,6 +5,7 @@
menuconfig WLAN
bool "Wireless LAN"
depends on !S390
+ default y
---help---
This section contains all the pre 802.11 and 802.11 wireless
device drivers. For a complete list of drivers and documentation
diff --git a/drivers/net/wireless/ath/ath9k/ani.c b/drivers/net/wireless/ath/ath9k/ani.c
index a7cbb07..2b49374 100644
--- a/drivers/net/wireless/ath/ath9k/ani.c
+++ b/drivers/net/wireless/ath/ath9k/ani.c
@@ -327,7 +327,8 @@ static void ath9k_hw_ani_ofdm_err_trigger(struct ath_hw *ah)
aniState->firstepLevel + 1);
return;
} else {
- if (conf->channel->band == IEEE80211_BAND_2GHZ) {
+ if ((conf->channel->band == IEEE80211_BAND_2GHZ) &&
+ !conf_is_ht(conf)) {
if (!aniState->ofdmWeakSigDetectOff)
ath9k_hw_ani_control(ah,
ATH9K_ANI_OFDM_WEAK_SIGNAL_DETECTION,
@@ -369,7 +370,8 @@ static void ath9k_hw_ani_cck_err_trigger(struct ath_hw *ah)
ath9k_hw_ani_control(ah, ATH9K_ANI_FIRSTEP_LEVEL,
aniState->firstepLevel + 1);
} else {
- if (conf->channel->band == IEEE80211_BAND_2GHZ) {
+ if ((conf->channel->band == IEEE80211_BAND_2GHZ) &&
+ !conf_is_ht(conf)) {
if (aniState->firstepLevel > 0)
ath9k_hw_ani_control(ah,
ATH9K_ANI_FIRSTEP_LEVEL, 0);
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index 7a9a3fa..e789792 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -2289,11 +2289,7 @@ static int b43_upload_microcode(struct b43_wldev *dev)
err = -ENODEV;
goto error;
}
- msleep_interruptible(50);
- if (signal_pending(current)) {
- err = -EINTR;
- goto error;
- }
+ msleep(50);
}
b43_read32(dev, B43_MMIO_GEN_IRQ_REASON); /* dummy read */
@@ -4287,6 +4283,8 @@ static int b43_wireless_core_init(struct b43_wldev *dev)
if (!dev->suspend_in_progress)
b43_rng_init(wl);
+ ieee80211_wake_queues(dev->wl->hw);
+
b43_set_status(dev, B43_STAT_INITIALIZED);
if (!dev->suspend_in_progress)
diff --git a/drivers/net/wireless/hostap/hostap_main.c b/drivers/net/wireless/hostap/hostap_main.c
index 6fe122f..eb57d1e 100644
--- a/drivers/net/wireless/hostap/hostap_main.c
+++ b/drivers/net/wireless/hostap/hostap_main.c
@@ -875,15 +875,16 @@ void hostap_setup_dev(struct net_device *dev, local_info_t *local,
switch(type) {
case HOSTAP_INTERFACE_AP:
+ dev->tx_queue_len = 0; /* use main radio device queue */
dev->netdev_ops = &hostap_mgmt_netdev_ops;
dev->type = ARPHRD_IEEE80211;
dev->header_ops = &hostap_80211_ops;
break;
case HOSTAP_INTERFACE_MASTER:
- dev->tx_queue_len = 0; /* use main radio device queue */
dev->netdev_ops = &hostap_master_ops;
break;
default:
+ dev->tx_queue_len = 0; /* use main radio device queue */
dev->netdev_ops = &hostap_netdev_ops;
}
diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c b/drivers/net/wireless/iwlwifi/iwl-4965.c
index 6a13bfb..ca61d37 100644
--- a/drivers/net/wireless/iwlwifi/iwl-4965.c
+++ b/drivers/net/wireless/iwlwifi/iwl-4965.c
@@ -2346,6 +2346,7 @@ struct iwl_cfg iwl4965_agn_cfg = {
.mod_params = &iwl4965_mod_params,
.use_isr_legacy = true,
.ht_greenfield_support = false,
+ .broken_powersave = true,
};
/* Module firmware */
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
index 40b207a..346dc06 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
@@ -760,6 +760,7 @@ static u32 rs_get_lower_rate(struct iwl_lq_sta *lq_sta,
u16 high_low;
u8 switch_to_legacy = 0;
u8 is_green = lq_sta->is_green;
+ struct iwl_priv *priv = lq_sta->drv;
/* check if we need to switch from HT to legacy rates.
* assumption is that mandatory rates (1Mbps or 6Mbps)
@@ -773,7 +774,8 @@ static u32 rs_get_lower_rate(struct iwl_lq_sta *lq_sta,
tbl->lq_type = LQ_G;
if (num_of_ant(tbl->ant_type) > 1)
- tbl->ant_type = ANT_A;/*FIXME:RS*/
+ tbl->ant_type =
+ first_antenna(priv->hw_params.valid_tx_ant);
tbl->is_ht40 = 0;
tbl->is_SGI = 0;
@@ -883,6 +885,12 @@ static void rs_tx_status(void *priv_r, struct ieee80211_supported_band *sband,
mac_index &= RATE_MCS_CODE_MSK; /* Remove # of streams */
if (mac_index >= (IWL_RATE_9M_INDEX - IWL_FIRST_OFDM_RATE))
mac_index++;
+ /*
+ * mac80211 HT index is always zero-indexed; we need to move
+ * HT OFDM rates after CCK rates in 2.4 GHz band
+ */
+ if (priv->band == IEEE80211_BAND_2GHZ)
+ mac_index += IWL_FIRST_OFDM_RATE;
}
if ((mac_index < 0) ||
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
index acfd7b4..fd26c0d 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -1585,9 +1585,12 @@ int iwl_setup_mac(struct iwl_priv *priv)
hw->flags = IEEE80211_HW_SIGNAL_DBM |
IEEE80211_HW_NOISE_DBM |
IEEE80211_HW_AMPDU_AGGREGATION |
- IEEE80211_HW_SPECTRUM_MGMT |
- IEEE80211_HW_SUPPORTS_PS |
- IEEE80211_HW_SUPPORTS_DYNAMIC_PS;
+ IEEE80211_HW_SPECTRUM_MGMT;
+
+ if (!priv->cfg->broken_powersave)
+ hw->flags |= IEEE80211_HW_SUPPORTS_PS |
+ IEEE80211_HW_SUPPORTS_DYNAMIC_PS;
+
hw->wiphy->interface_modes =
BIT(NL80211_IFTYPE_STATION) |
BIT(NL80211_IFTYPE_ADHOC);
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.h b/drivers/net/wireless/iwlwifi/iwl-core.h
index c04d2a2..7ff9ffb 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.h
+++ b/drivers/net/wireless/iwlwifi/iwl-core.h
@@ -252,6 +252,7 @@ struct iwl_cfg {
const u16 max_ll_items;
const bool shadow_ram_support;
const bool ht_greenfield_support;
+ const bool broken_powersave;
};
/***************************
diff --git a/drivers/net/wireless/iwlwifi/iwl-power.c b/drivers/net/wireless/iwlwifi/iwl-power.c
index 4ec6a83..60be976 100644
--- a/drivers/net/wireless/iwlwifi/iwl-power.c
+++ b/drivers/net/wireless/iwlwifi/iwl-power.c
@@ -292,8 +292,9 @@ int iwl_power_update_mode(struct iwl_priv *priv, bool force)
else
dtimper = 1;
- /* TT power setting overwrites everything */
- if (tt->state >= IWL_TI_1)
+ if (priv->cfg->broken_powersave)
+ iwl_power_sleep_cam_cmd(priv, &cmd);
+ else if (tt->state >= IWL_TI_1)
iwl_static_sleep_cmd(priv, &cmd, tt->tt_power_mode, dtimper);
else if (!enabled)
iwl_power_sleep_cam_cmd(priv, &cmd);
diff --git a/drivers/net/wireless/iwlwifi/iwl-rx.c b/drivers/net/wireless/iwlwifi/iwl-rx.c
index 8150c5c..b90adcb 100644
--- a/drivers/net/wireless/iwlwifi/iwl-rx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-rx.c
@@ -239,26 +239,22 @@ void iwl_rx_allocate(struct iwl_priv *priv, gfp_t priority)
struct iwl_rx_queue *rxq = &priv->rxq;
struct list_head *element;
struct iwl_rx_mem_buffer *rxb;
+ struct sk_buff *skb;
unsigned long flags;
while (1) {
spin_lock_irqsave(&rxq->lock, flags);
-
if (list_empty(&rxq->rx_used)) {
spin_unlock_irqrestore(&rxq->lock, flags);
return;
}
- element = rxq->rx_used.next;
- rxb = list_entry(element, struct iwl_rx_mem_buffer, list);
- list_del(element);
-
spin_unlock_irqrestore(&rxq->lock, flags);
/* Alloc a new receive buffer */
- rxb->skb = alloc_skb(priv->hw_params.rx_buf_size + 256,
+ skb = alloc_skb(priv->hw_params.rx_buf_size + 256,
priority);
- if (!rxb->skb) {
+ if (!skb) {
IWL_CRIT(priv, "Can not allocate SKB buffers\n");
/* We don't reschedule replenish work here -- we will
* call the restock method and if it still needs
@@ -266,6 +262,20 @@ void iwl_rx_allocate(struct iwl_priv *priv, gfp_t priority)
break;
}
+ spin_lock_irqsave(&rxq->lock, flags);
+
+ if (list_empty(&rxq->rx_used)) {
+ spin_unlock_irqrestore(&rxq->lock, flags);
+ dev_kfree_skb_any(skb);
+ return;
+ }
+ element = rxq->rx_used.next;
+ rxb = list_entry(element, struct iwl_rx_mem_buffer, list);
+ list_del(element);
+
+ spin_unlock_irqrestore(&rxq->lock, flags);
+
+ rxb->skb = skb;
/* Get physical address of RB/SKB */
rxb->real_dma_addr = pci_map_single(
priv->pci_dev,
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 2238c9f..0909668 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -1134,6 +1134,7 @@ static void iwl3945_rx_allocate(struct iwl_priv *priv, gfp_t priority)
struct iwl_rx_queue *rxq = &priv->rxq;
struct list_head *element;
struct iwl_rx_mem_buffer *rxb;
+ struct sk_buff *skb;
unsigned long flags;
while (1) {
@@ -1143,17 +1144,11 @@ static void iwl3945_rx_allocate(struct iwl_priv *priv, gfp_t priority)
spin_unlock_irqrestore(&rxq->lock, flags);
return;
}
-
- element = rxq->rx_used.next;
- rxb = list_entry(element, struct iwl_rx_mem_buffer, list);
- list_del(element);
spin_unlock_irqrestore(&rxq->lock, flags);
/* Alloc a new receive buffer */
- rxb->skb =
- alloc_skb(priv->hw_params.rx_buf_size,
- priority);
- if (!rxb->skb) {
+ skb = alloc_skb(priv->hw_params.rx_buf_size, priority);
+ if (!skb) {
if (net_ratelimit())
IWL_CRIT(priv, ": Can not allocate SKB buffers\n");
/* We don't reschedule replenish work here -- we will
@@ -1162,6 +1157,19 @@ static void iwl3945_rx_allocate(struct iwl_priv *priv, gfp_t priority)
break;
}
+ spin_lock_irqsave(&rxq->lock, flags);
+ if (list_empty(&rxq->rx_used)) {
+ spin_unlock_irqrestore(&rxq->lock, flags);
+ dev_kfree_skb_any(skb);
+ return;
+ }
+ element = rxq->rx_used.next;
+ rxb = list_entry(element, struct iwl_rx_mem_buffer, list);
+ list_del(element);
+ spin_unlock_irqrestore(&rxq->lock, flags);
+
+ rxb->skb = skb;
+
/* If radiotap head is required, reserve some headroom here.
* The physical head count is a variable rx_stats->phy_count.
* We reserve 4 bytes here. Plus these extra bytes, the
diff --git a/drivers/net/wireless/p54/p54usb.c b/drivers/net/wireless/p54/p54usb.c
index e44460f..17e1995 100644
--- a/drivers/net/wireless/p54/p54usb.c
+++ b/drivers/net/wireless/p54/p54usb.c
@@ -67,6 +67,7 @@ static struct usb_device_id p54u_table[] __devinitdata = {
{USB_DEVICE(0x0bf8, 0x1009)}, /* FUJITSU E-5400 USB D1700*/
{USB_DEVICE(0x0cde, 0x0006)}, /* Medion MD40900 */
{USB_DEVICE(0x0cde, 0x0008)}, /* Sagem XG703A */
+ {USB_DEVICE(0x0cde, 0x0015)}, /* Zcomax XG-705A */
{USB_DEVICE(0x0d8e, 0x3762)}, /* DLink DWL-G120 Cohiba */
{USB_DEVICE(0x124a, 0x4025)}, /* IOGear GWU513 (GW3887IK chip) */
{USB_DEVICE(0x1260, 0xee22)}, /* SMC 2862W-G version 2 */
diff --git a/drivers/ssb/pci.c b/drivers/ssb/pci.c
index f853d56..9e50896 100644
--- a/drivers/ssb/pci.c
+++ b/drivers/ssb/pci.c
@@ -600,6 +600,7 @@ static int sprom_extract(struct ssb_bus *bus, struct ssb_sprom *out,
ssb_printk(KERN_WARNING PFX "Unsupported SPROM"
" revision %d detected. Will extract"
" v1\n", out->revision);
+ out->revision = 1;
sprom_extract_r123(out, in);
}
}
diff --git a/drivers/ssb/sdio.c b/drivers/ssb/sdio.c
index 1140510..65a6080 100644
--- a/drivers/ssb/sdio.c
+++ b/drivers/ssb/sdio.c
@@ -21,7 +21,7 @@
#include "ssb_private.h"
/* Define the following to 1 to enable a printk on each coreswitch. */
-#define SSB_VERBOSE_SDIOCORESWITCH_DEBUG 1
+#define SSB_VERBOSE_SDIOCORESWITCH_DEBUG 0
/* Hardware invariants CIS tuples */
@@ -333,7 +333,7 @@ static void ssb_sdio_block_read(struct ssb_device *dev, void *buffer,
goto out;
err_out:
- dev_dbg(ssb_sdio_dev(bus), "%04X:%04X (width=%u, len=%u), error %d\n",
+ dev_dbg(ssb_sdio_dev(bus), "%04X:%04X (width=%u, len=%zu), error %d\n",
bus->sdio_sbaddr >> 16, offset, reg_width, saved_count, error);
out:
sdio_release_host(bus->host_sdio);
@@ -440,7 +440,7 @@ static void ssb_sdio_block_write(struct ssb_device *dev, const void *buffer,
goto out;
err_out:
- dev_dbg(ssb_sdio_dev(bus), "%04X:%04X (width=%u, len=%u), error %d\n",
+ dev_dbg(ssb_sdio_dev(bus), "%04X:%04X (width=%u, len=%zu), error %d\n",
bus->sdio_sbaddr >> 16, offset, reg_width, saved_count, error);
out:
sdio_release_host(bus->host_sdio);
diff --git a/net/mac80211/rc80211_minstrel.c b/net/mac80211/rc80211_minstrel.c
index 7c51429..6e5d68b 100644
--- a/net/mac80211/rc80211_minstrel.c
+++ b/net/mac80211/rc80211_minstrel.c
@@ -418,7 +418,7 @@ minstrel_rate_init(void *priv, struct ieee80211_supported_band *sband,
/* contention window */
tx_time_single += t_slot + min(cw, mp->cw_max);
- cw = (cw + 1) << 1;
+ cw = (cw << 1) | 1;
tx_time += tx_time_single;
tx_time_cts += tx_time_single + mi->sp_ack_dur;
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index 4c210c2..e5f92ee 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -662,7 +662,7 @@ int cfg80211_wext_siwscan(struct net_device *dev,
int k;
int wiphy_freq = wiphy->bands[band]->channels[j].center_freq;
for (k = 0; k < wreq->num_channels; k++) {
- int wext_freq = wreq->channel_list[k].m / 100000;
+ int wext_freq = cfg80211_wext_freq(wiphy, &wreq->channel_list[k]);
if (wext_freq == wiphy_freq)
goto wext_freq_found;
}
@@ -675,6 +675,11 @@ int cfg80211_wext_siwscan(struct net_device *dev,
wext_freq_not_found: ;
}
}
+ /* No channels found? */
+ if (!i) {
+ err = -EINVAL;
+ goto out;
+ }
/* Set real number of channels specified in creq->channels[] */
creq->n_channels = i;
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index 6830788..7fae7ee 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -188,7 +188,7 @@ void cfg80211_conn_work(struct work_struct *work)
rtnl_unlock();
}
-static bool cfg80211_get_conn_bss(struct wireless_dev *wdev)
+static struct cfg80211_bss *cfg80211_get_conn_bss(struct wireless_dev *wdev)
{
struct cfg80211_registered_device *rdev = wiphy_to_dev(wdev->wiphy);
struct cfg80211_bss *bss;
@@ -205,7 +205,7 @@ static bool cfg80211_get_conn_bss(struct wireless_dev *wdev)
WLAN_CAPABILITY_ESS | WLAN_CAPABILITY_PRIVACY,
capa);
if (!bss)
- return false;
+ return NULL;
memcpy(wdev->conn->bssid, bss->bssid, ETH_ALEN);
wdev->conn->params.bssid = wdev->conn->bssid;
@@ -213,14 +213,14 @@ static bool cfg80211_get_conn_bss(struct wireless_dev *wdev)
wdev->conn->state = CFG80211_CONN_AUTHENTICATE_NEXT;
schedule_work(&rdev->conn_work);
- cfg80211_put_bss(bss);
- return true;
+ return bss;
}
static void __cfg80211_sme_scan_done(struct net_device *dev)
{
struct wireless_dev *wdev = dev->ieee80211_ptr;
struct cfg80211_registered_device *rdev = wiphy_to_dev(wdev->wiphy);
+ struct cfg80211_bss *bss;
ASSERT_WDEV_LOCK(wdev);
@@ -234,7 +234,10 @@ static void __cfg80211_sme_scan_done(struct net_device *dev)
wdev->conn->state != CFG80211_CONN_SCAN_AGAIN)
return;
- if (!cfg80211_get_conn_bss(wdev)) {
+ bss = cfg80211_get_conn_bss(wdev);
+ if (bss) {
+ cfg80211_put_bss(bss);
+ } else {
/* not found */
if (wdev->conn->state == CFG80211_CONN_SCAN_AGAIN)
schedule_work(&rdev->conn_work);
@@ -670,6 +673,7 @@ int __cfg80211_connect(struct cfg80211_registered_device *rdev,
{
struct wireless_dev *wdev = dev->ieee80211_ptr;
struct ieee80211_channel *chan;
+ struct cfg80211_bss *bss = NULL;
int err;
ASSERT_WDEV_LOCK(wdev);
@@ -760,7 +764,7 @@ int __cfg80211_connect(struct cfg80211_registered_device *rdev,
/* don't care about result -- but fill bssid & channel */
if (!wdev->conn->params.bssid || !wdev->conn->params.channel)
- cfg80211_get_conn_bss(wdev);
+ bss = cfg80211_get_conn_bss(wdev);
wdev->sme_state = CFG80211_SME_CONNECTING;
wdev->connect_keys = connkeys;
@@ -770,10 +774,11 @@ int __cfg80211_connect(struct cfg80211_registered_device *rdev,
wdev->conn->prev_bssid_valid = true;
}
- /* we're good if we have both BSSID and channel */
- if (wdev->conn->params.bssid && wdev->conn->params.channel) {
+ /* we're good if we have a matching bss struct */
+ if (bss) {
wdev->conn->state = CFG80211_CONN_AUTHENTICATE_NEXT;
err = cfg80211_conn_do_work(wdev);
+ cfg80211_put_bss(bss);
} else {
/* otherwise we'll need to scan for the AP first */
err = cfg80211_conn_scan(wdev);
--
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
* Re: [PATCH 2/2] b43: Add lpphy_clear_tx_power_offsets to improve TX Power handling
From: Gábor Stefanik @ 2009-09-16 20:44 UTC (permalink / raw)
To: Thomas Ilnseher
Cc: John Linville, Broadcom Wireless, linux-wireless, Larry Finger
In-Reply-To: <1253132275.2989.75.camel@note>
2009/9/16 Thomas Ilnseher <illth@gmx.de>:
> Am Mittwoch, den 16.09.2009, 21:40 +0200 schrieb Gábor Stefanik:
>> You are essentially implementing dead code at this point - this will
>> only ever be called if hardware-accelerated TX power control is
>> enabled - and HW TX power control is unsupported, even for G-PHYs.
> Then the question remains, why this brings my device to 54 MBit/s ?
>
> I did double check again with the old driver:
>
> wlan0 IEEE 802.11bg ESSID:"tommy"
> Mode:Managed Frequency:2.412 GHz Access Point:
> Bit Rate=9 Mb/s Tx-Power=20 dBm
> Retry long limit:7 RTS thr:off Fragment thr:off
> Encryption key:off
> Power Management:off
> Link Quality=70/70 Signal level=5 dBm
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>
> Patched driver:
>
> wlan0 IEEE 802.11bg ESSID:"tommy"
> Mode:Managed Frequency:2.412 GHz Access Point: XXX
> Bit Rate=54 Mb/s Tx-Power=20 dBm
> Retry long limit:7 RTS thr:off Fragment thr:off
> Encryption key:off
> Power Management:off
> Link Quality=70/70 Signal level=10 dBm
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>
>
>
>> > Signed-off-by: Thomas Ilnseher <illth@gmx.de>
>> >
>> > ---
>> > diff -uNr a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c
>> > --- a/drivers/net/wireless/b43/phy_lp.c 2009-09-16 20:52:17.501318374 +0200
>> > +++ b/drivers/net/wireless/b43/phy_lp.c 2009-09-16 20:53:36.593319452 +0200
>> > @@ -1125,6 +1125,18 @@
>> > dev->phy.lp->tssi_idx = (b43_phy_read(dev, B43_LPPHY_TX_PWR_CTL_STAT) & 0x7F00) >> 8;
>> > }
>> >
>> > +static void lpphy_clear_tx_power_offsets(struct b43_wldev *dev)
>> > +{
>> > + int i;
>> > + int id = 7;
>> > + if (dev->phy.rev < 2)
>> > + id = 10;
>> > + for (i = 0; i < 12; i++)
>> > + b43_lptab_write(dev, B43_LPTAB32(id, 0x40 + i), 0);
>> > + for (i = 0; i < 64; i++)
>> > + b43_lptab_write(dev, B43_LPTAB32(id, 0x80 + i), 0);
>> > +}
>> > +
>> > static void lpphy_set_tx_power_control(struct b43_wldev *dev,
>> > enum b43_lpphy_txpctl_mode mode)
>> > {
>> > @@ -1139,7 +1151,7 @@
>> >
>> > if (oldmode == B43_LPPHY_TXPCTL_HW) {
>> > lpphy_update_tx_power_npt(dev);
>> > - //TODO Clear all TX Power offsets
>> > + lpphy_clear_tx_power_offsets(dev);
Put a printk here to see if this branch is getting hit.
(BTW, are you loading b43 with the "hwpctl" modparam? That enables
experimental HW TX power control support, which might explain what you
were seeing.)
>> > } else {
>> > if (mode == B43_LPPHY_TXPCTL_HW) {
>> > //TODO Recalculate target TX power
>> >
>> >
>>
>>
>>
>
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* RE: [PATCH] libertas: Add auto deep sleep support for SD8385/SD8686/SD8688
From: Bing Zhao @ 2009-09-16 20:20 UTC (permalink / raw)
To: Andrey Yurovsky
Cc: libertas-dev@lists.infradead.org, linux-wireless@vger.kernel.org,
Amitkumar Karwar, Dan Williams
In-Reply-To: <45e8e6c40909151641o423cbc70y22033061505661b6@mail.gmail.com>
Hi Andrey,
> -----Original Message-----
> From: Andrey Yurovsky [mailto:andrey@cozybit.com]
> Sent: Tuesday, September 15, 2009 4:41 PM
> To: Bing Zhao
> Cc: libertas-dev@lists.infradead.org; linux-wireless@vger.kernel.org; Amitkumar Karwar; Dan Williams
> Subject: Re: [PATCH] libertas: Add auto deep sleep support for SD8385/SD8686/SD8688
>
> Hi Bing. This is not specific to the actual implementation of the
> deep sleep commands in your patch but,
>
> On Tue, Sep 15, 2009 at 4:45 PM, Bing Zhao <bzhao@marvell.com> wrote:
> > + Path: /sys/kernel/debug/libertas_wireless/ethX/
>
> Is the sysfs interface really necessary? It seems like yet another
> non-standard configuration option to keep track of.
Actually the debugfs interface is used in the patch.
Some information (such as the interface name and path) in README file is out of date. We just copy-and-paste it for the new deepsleep command. We need a separate patch to clean up the REAME file and keep it up to date.
>
> Deep sleep seems to pretty much "turn off" the wifi card (as far as
> the user is concerned) so how about a simpler approach: enter deep
> sleep when the interface is brought down (ifconfig wlanN down) and
> exit deep sleep when it's brought up. Do this only when deep sleep is
> supported/possible. Alternately, maybe this belongs as an rfkill
> feature?
Entering/exiting deep sleep doesn't have to depend on wlanN interface's up and down. User can still put the chip into sleep when wlanN is up. And, with auto deep sleep feature, the driver automatically wakes the chip up for sending user commands (for example, scan) and put the chip back to sleep after certain time period of inactivity. The deepsleep command through debugfs interface provides the flexibility of deep sleep options.
The rfkill shuts down the RF transmitter of the device but most of other modules may be still functioning. The deep sleep shuts down most of the modules (including the RF) on the chip to save as much power as possible.
Regards,
Bing
>
> -Andrey
^ permalink raw reply
* Re: [PATCH 2/2] b43: Add lpphy_clear_tx_power_offsets to improve TX Power handling
From: Thomas Ilnseher @ 2009-09-16 20:17 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John Linville, Broadcom Wireless, linux-wireless, Larry Finger
In-Reply-To: <69e28c910909161240p7739edebi653b5d402a792856@mail.gmail.com>
Am Mittwoch, den 16.09.2009, 21:40 +0200 schrieb Gábor Stefanik:
> You are essentially implementing dead code at this point - this will
> only ever be called if hardware-accelerated TX power control is
> enabled - and HW TX power control is unsupported, even for G-PHYs.
Then the question remains, why this brings my device to 54 MBit/s ?
I did double check again with the old driver:
wlan0 IEEE 802.11bg ESSID:"tommy"
Mode:Managed Frequency:2.412 GHz Access Point:
Bit Rate=9 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=70/70 Signal level=5 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Patched driver:
wlan0 IEEE 802.11bg ESSID:"tommy"
Mode:Managed Frequency:2.412 GHz Access Point: XXX
Bit Rate=54 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=70/70 Signal level=10 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
> > Signed-off-by: Thomas Ilnseher <illth@gmx.de>
> >
> > ---
> > diff -uNr a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c
> > --- a/drivers/net/wireless/b43/phy_lp.c 2009-09-16 20:52:17.501318374 +0200
> > +++ b/drivers/net/wireless/b43/phy_lp.c 2009-09-16 20:53:36.593319452 +0200
> > @@ -1125,6 +1125,18 @@
> > dev->phy.lp->tssi_idx = (b43_phy_read(dev, B43_LPPHY_TX_PWR_CTL_STAT) & 0x7F00) >> 8;
> > }
> >
> > +static void lpphy_clear_tx_power_offsets(struct b43_wldev *dev)
> > +{
> > + int i;
> > + int id = 7;
> > + if (dev->phy.rev < 2)
> > + id = 10;
> > + for (i = 0; i < 12; i++)
> > + b43_lptab_write(dev, B43_LPTAB32(id, 0x40 + i), 0);
> > + for (i = 0; i < 64; i++)
> > + b43_lptab_write(dev, B43_LPTAB32(id, 0x80 + i), 0);
> > +}
> > +
> > static void lpphy_set_tx_power_control(struct b43_wldev *dev,
> > enum b43_lpphy_txpctl_mode mode)
> > {
> > @@ -1139,7 +1151,7 @@
> >
> > if (oldmode == B43_LPPHY_TXPCTL_HW) {
> > lpphy_update_tx_power_npt(dev);
> > - //TODO Clear all TX Power offsets
> > + lpphy_clear_tx_power_offsets(dev);
> > } else {
> > if (mode == B43_LPPHY_TXPCTL_HW) {
> > //TODO Recalculate target TX power
> >
> >
>
>
>
^ permalink raw reply
* Re: WARNING: at net/mac80211/scan.c:267 ieee80211_scan_completed+0x299/0x2b0 [mac80211]()
From: Maciej Rutecki @ 2009-09-16 19:59 UTC (permalink / raw)
To: reinette chatre
Cc: Linux Kernel Mailing List, Linux Wireless List,
ilw@linux.intel.com, Zhu, Yi
In-Reply-To: <1253124149.26521.438.camel@rc-desk>
2009/9/16 reinette chatre <reinette.chatre@intel.com>:
>
> You mentioned that you tried to connect to two networks. From the logs I
> can understand that the connection to the first network took a long
> time. This is also not due to the warnings you encountered (the warnings
> only showed up after you disconnected from second network). The reason
> why the connection to the first network took so long was some protocol
> exchange problems with AP. Here is the relevant information from your
> log:
>
[...]
>
> As you can see the AP keeps deauthenticating you with Reason 6. This
> means "Incorrect frame type or subtype received from unauthenticated
> station". Can you try to connect using wpa_supplicant? When you do make
> sure there is no other network managing applications (like network
> manager, wicd, or even other instances of wpa_supplicant etc) running.
>
> The connection to the second network went very fast - completed in one
> second. But a disconnection was requested locally just as fast. Do you
> perhaps have more than one network managing application running?
1. Stop wicd daemon (I don't use another application to connect to the network).
2. Connect to network "x" (with WPA)
Script (wifi_wpa.sh):
#!/bin/sh
INTERFACE=wlan0
WPA_FILE=/etc/wpa_supplicant/wpa_supplicant.conf
DRIVER=wext
ifconfig eth0 down
ifconfig $INTERFACE up
sleep 3
killall wpa_supplicant &> /dev/null
wpa_supplicant -c $WPA_FILE -D $DRIVER -i $INTERFACE -B
dhclient $INTERFACE
iwconfig $INTERFACE
File /etc/wpa_supplicant/wpa_supplicant.conf:
# WPA-PSK/TKIP
ctrl_interface=/var/run/wpa_supplicant
network={
ssid="x"
key_mgmt=WPA-PSK
proto=WPA
pairwise=TKIP
group=TKIP
psk=<data hidden>
priority=4
}
First try:
root@gumis:/home/maciek# /home/maciek/bin/wifi/wifi_wpa.sh
Internet Systems Consortium DHCP Client V3.1.2p1
Copyright 2004-2009 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
Listening on LPF/wlan0/00:13:02:c3:96:a8
Sending on LPF/wlan0/00:13:02:c3:96:a8
Sending on Socket/fallback
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 15
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 10
No DHCPOFFERS received.
Trying recorded lease 192.168.0.102
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
--- 192.168.0.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
No working leases in persistent database - sleeping.
wlan0 IEEE 802.11abg ESSID:"x"
Mode:Managed Frequency:2.457 GHz Access Point: 00:1B:11:F6:0F:28
Tx-Power=15 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:on
>From dmesg:
[ 256.945249] b44: eth0: powering down PHY
[ 256.948714] iwl3945 0000:08:00.0: firmware: requesting
iwlwifi-3945-2.ucode
[ 256.985907] iwl3945 0000:08:00.0: loaded firmware version 15.32.2.9
[ 257.060922] Registered led device: iwl-phy0::radio
[ 257.061021] Registered led device: iwl-phy0::assoc
[ 257.061070] Registered led device: iwl-phy0::RX
[ 257.061109] Registered led device: iwl-phy0::TX
[ 262.899954] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 262.902445] wlan0 direct probe responded
[ 262.902455] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 262.904278] wlan0: authenticated
[ 262.904328] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 262.906702] wlan0: RX AssocResp from 00:1b:11:f6:0f:28 (capab=0x431
status=0 aid=1)
[ 262.906711] wlan0: associated
[ 266.615969] wlan0: deauthenticated from 00:1b:11:f6:0f:28 (Reason:
6)
[ 269.342010] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 269.344434] wlan0 direct probe responded
[ 269.344441] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 269.346167] wlan0: authenticated
[ 269.346197] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 269.348470] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28
(capab=0x431 status=0 aid=1)
[...]
[ 416.396624] wlan0: associated
[ 419.907739] wlan0: deauthenticated from 00:1b:11:f6:0f:28 (Reason: 6)
[ 422.633775] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 422.832075] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 2)
[ 423.032068] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 3)
[ 423.034477] wlan0 direct probe responded
[ 423.034484] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 423.036229] wlan0: authenticated
[ 423.036266] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 423.038518] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28
(capab=0x431 status=0 aid=1)
[ 423.038524] wlan0: associated
[ 481.301801] wlan0: deauthenticating by local choice (reason=3)
Second try:
root@gumis:/home/maciek# /home/maciek/bin/wifi/wifi_wpa.sh
There is already a pid file /var/run/dhclient.pid with pid 4555
killed old client process, removed PID file
Internet Systems Consortium DHCP Client V3.1.2p1
Copyright 2004-2009 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
Listening on LPF/wlan0/00:13:02:c3:96:a8
Sending on LPF/wlan0/00:13:02:c3:96:a8
Sending on Socket/fallback
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 15
DHCPOFFER from 192.168.0.1
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPACK from 192.168.0.1
Reloading /etc/samba/smb.conf: smbd only.
bound to 192.168.0.102 -- renewal in 571812 seconds.
wlan0 IEEE 802.11abg ESSID:"x"
Mode:Managed Frequency:2.457 GHz Access Point: 00:1B:11:F6:0F:28
Bit Rate=54 Mb/s Tx-Power=15 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:on
Link Quality=68/70 Signal level=-42 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Dmesg:
[ 481.460263] Registered led device: iwl-phy0::radio
[ 481.460289] Registered led device: iwl-phy0::assoc
[ 481.460375] Registered led device: iwl-phy0::RX
[ 481.460396] Registered led device: iwl-phy0::TX
[ 481.476399] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 481.478822] wlan0 direct probe responded
[ 481.478828] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 481.480750] wlan0: authenticated
[ 481.480775] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 481.483111] wlan0: RX AssocResp from 00:1b:11:f6:0f:28 (capab=0x431
status=0 aid=1)
[ 481.483116] wlan0: associated
[ 485.238506] wlan0: deauthenticated from 00:1b:11:f6:0f:28 (Reason:
6)
[ 485.361103] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 485.363480] wlan0 direct probe responded
[ 485.363487] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 485.365222] wlan0: authenticated
[ 485.365253] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 485.367505] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28
(capab=0x431 status=0 aid=1)
[ 485.367512] wlan0: associated
[ 489.334545] wlan0: deauthenticated from 00:1b:11:f6:0f:28 (Reason:
6)
[ 492.052130] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 492.054555] wlan0 direct probe responded
[ 492.054562] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 492.056507] wlan0: authenticated
[ 492.056541] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 492.058793] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28
(capab=0x431 status=0 aid=1)
[ 492.058800] wlan0: associated
[ 495.580873] wlan0: deauthenticated from 00:1b:11:f6:0f:28 (Reason:
6)
[ 498.302685] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 498.305121] wlan0 direct probe responded
[ 498.305129] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 498.306855] wlan0: authenticated
[ 498.306885] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 498.309142] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28
(capab=0x431 status=0 aid=1)
[ 498.309149] wlan0: associated
[ 501.520066] wlan0: deauthenticated from 00:1b:11:f6:0f:28 (Reason:
6)
[ 504.250066] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 504.252493] wlan0 direct probe responded
[ 504.252500] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 504.254227] wlan0: authenticated
[ 504.254256] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 504.256525] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28
(capab=0x431 status=0 aid=1)
[ 504.256532] wlan0: associated
[ 507.766452] wlan0: deauthenticated from 00:1b:11:f6:0f:28 (Reason: 6)
[ 510.518231] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 510.520682] wlan0 direct probe responded
[ 510.520689] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 510.522415] wlan0: authenticated
[ 510.522447] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 510.524699] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28
(capab=0x431 status=0 aid=1)
[ 510.524706] wlan0: associated
[ 514.012725] wlan0: deauthenticated from 00:1b:11:f6:0f:28 (Reason: 6)
[ 516.718174] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 516.720611] wlan0 direct probe responded
[ 516.720619] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 516.722346] wlan0: authenticated
[ 516.722377] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 516.724653] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28
(capab=0x431 status=0 aid=1)
[ 516.724660] wlan0: associated
[ 520.873494] wlan0: deauthenticated from 00:1b:11:f6:0f:28 (Reason: 6)
[ 523.608977] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 523.611397] wlan0 direct probe responded
[ 523.611405] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 523.613133] wlan0: authenticated
[ 523.613165] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 523.615415] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28
(capab=0x431 status=0 aid=1)
[ 523.615421] wlan0: associated
[ 527.011070] wlan0: deauthenticated from 00:1b:11:f6:0f:28 (Reason: 6)
[ 529.714994] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 529.717412] wlan0 direct probe responded
[ 529.717420] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 529.719146] wlan0: authenticated
[ 529.719176] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 529.721458] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28
(capab=0x431 status=0 aid=1)
[ 529.721465] wlan0: associated
3. Connect to network "y" (without wpa/wep/etc.)
Script:
#!/bin/sh
INTERFACE="wlan0"
ESSID="y"
killall wpa_supplicant
ifconfig $INTERFACE down
iwconfig $INTERFACE essid $ESSID
ifconfig $INTERFACE up
sleep 3
killall dhclient &> /dev/null
dhclient $INTERFACE
sleep 3
iwconfig $INTERFACE
First try:
root@gumis:/home/maciek# /home/maciek/bin/wifi/wifi_dhcp.sh
There is already a pid file /var/run/dhclient.pid with pid 4819
killed old client process, removed PID file
Internet Systems Consortium DHCP Client V3.1.2p1
Copyright 2004-2009 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
Listening on LPF/wlan0/00:13:02:c3:96:a8
Sending on LPF/wlan0/00:13:02:c3:96:a8
Sending on Socket/fallback
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPNAK from 192.168.1.1
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4
DHCPOFFER from 192.168.1.1
DHCPREQUEST on wlan0 to 255.255.255.255 port 67
DHCPACK from 192.168.1.1
Reloading /etc/samba/smb.conf: smbd only.
bound to 192.168.1.102 -- renewal in 40350 seconds.
wlan0 IEEE 802.11abg ESSID:"y"
Mode:Managed Frequency:2.462 GHz Access Point: 00:0D:F3:0D:D1:4C
Bit Rate=54 Mb/s Tx-Power=15 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:on
Link Quality=31/70 Signal level=-79 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Dmesg:
[ 1088.324243] Registered led device: iwl-phy0::radio
[ 1088.324270] Registered led device: iwl-phy0::assoc
[ 1088.324354] Registered led device: iwl-phy0::RX
[ 1088.324374] Registered led device: iwl-phy0::TX
[ 1088.339739] wlan0: direct probe to AP 00:0d:f3:0d:d1:4c (try 1)
[ 1088.343450] wlan0 direct probe responded
[ 1088.343458] wlan0: authenticate with AP 00:0d:f3:0d:d1:4c (try 1)
[ 1088.345313] wlan0: authenticated
[ 1088.345337] wlan0: associate with AP 00:0d:f3:0d:d1:4c (try 1)
[ 1088.347943] wlan0: RX AssocResp from 00:0d:f3:0d:d1:4c (capab=0x401
status=0 aid=2)
[ 1088.347948] wlan0: associated
Normally I use wicd to manage all networks. In first e-mail I connect
to "x" and - after this - connect to "y".
Network "x" is my own network. Sometimes (if is visible) I connect to
"y" - somebody create fast network without any protection... :-) Till
2.6.31 all works ok.
Note: in "x" and "y" I have the same IP (this only coincidence).
--
Maciej Rutecki
http://www.maciek.unixy.pl
^ permalink raw reply
* Re: [PATCH 2/2] b43: Add lpphy_clear_tx_power_offsets to improve TX Power handling
From: Gábor Stefanik @ 2009-09-16 19:40 UTC (permalink / raw)
To: Thomas Ilnseher
Cc: John Linville, Broadcom Wireless, linux-wireless, Larry Finger
In-Reply-To: <1253129879.2989.48.camel@note>
You are essentially implementing dead code at this point - this will
only ever be called if hardware-accelerated TX power control is
enabled - and HW TX power control is unsupported, even for G-PHYs.
On Wed, Sep 16, 2009 at 9:37 PM, Thomas Ilnseher <illth@gmx.de> wrote:
> This patch adds the lpphy_clear_tx_power_offsets to b43.
>
> Signed-off-by: Thomas Ilnseher <illth@gmx.de>
>
> ---
> diff -uNr a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c
> --- a/drivers/net/wireless/b43/phy_lp.c 2009-09-16 20:52:17.501318374 +0200
> +++ b/drivers/net/wireless/b43/phy_lp.c 2009-09-16 20:53:36.593319452 +0200
> @@ -1125,6 +1125,18 @@
> dev->phy.lp->tssi_idx = (b43_phy_read(dev, B43_LPPHY_TX_PWR_CTL_STAT) & 0x7F00) >> 8;
> }
>
> +static void lpphy_clear_tx_power_offsets(struct b43_wldev *dev)
> +{
> + int i;
> + int id = 7;
> + if (dev->phy.rev < 2)
> + id = 10;
> + for (i = 0; i < 12; i++)
> + b43_lptab_write(dev, B43_LPTAB32(id, 0x40 + i), 0);
> + for (i = 0; i < 64; i++)
> + b43_lptab_write(dev, B43_LPTAB32(id, 0x80 + i), 0);
> +}
> +
> static void lpphy_set_tx_power_control(struct b43_wldev *dev,
> enum b43_lpphy_txpctl_mode mode)
> {
> @@ -1139,7 +1151,7 @@
>
> if (oldmode == B43_LPPHY_TXPCTL_HW) {
> lpphy_update_tx_power_npt(dev);
> - //TODO Clear all TX Power offsets
> + lpphy_clear_tx_power_offsets(dev);
> } else {
> if (mode == B43_LPPHY_TXPCTL_HW) {
> //TODO Recalculate target TX power
>
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* [PATCH 2/2] b43: Add lpphy_clear_tx_power_offsets to improve TX Power handling
From: Thomas Ilnseher @ 2009-09-16 19:37 UTC (permalink / raw)
To: John Linville
Cc: Broadcom Wireless, linux-wireless, Larry Finger,
Gábor Stefanik
This patch adds the lpphy_clear_tx_power_offsets to b43.
Signed-off-by: Thomas Ilnseher <illth@gmx.de>
---
diff -uNr a/drivers/net/wireless/b43/phy_lp.c b/drivers/net/wireless/b43/phy_lp.c
--- a/drivers/net/wireless/b43/phy_lp.c 2009-09-16 20:52:17.501318374 +0200
+++ b/drivers/net/wireless/b43/phy_lp.c 2009-09-16 20:53:36.593319452 +0200
@@ -1125,6 +1125,18 @@
dev->phy.lp->tssi_idx = (b43_phy_read(dev, B43_LPPHY_TX_PWR_CTL_STAT) & 0x7F00) >> 8;
}
+static void lpphy_clear_tx_power_offsets(struct b43_wldev *dev)
+{
+ int i;
+ int id = 7;
+ if (dev->phy.rev < 2)
+ id = 10;
+ for (i = 0; i < 12; i++)
+ b43_lptab_write(dev, B43_LPTAB32(id, 0x40 + i), 0);
+ for (i = 0; i < 64; i++)
+ b43_lptab_write(dev, B43_LPTAB32(id, 0x80 + i), 0);
+}
+
static void lpphy_set_tx_power_control(struct b43_wldev *dev,
enum b43_lpphy_txpctl_mode mode)
{
@@ -1139,7 +1151,7 @@
if (oldmode == B43_LPPHY_TXPCTL_HW) {
lpphy_update_tx_power_npt(dev);
- //TODO Clear all TX Power offsets
+ lpphy_clear_tx_power_offsets(dev);
} else {
if (mode == B43_LPPHY_TXPCTL_HW) {
//TODO Recalculate target TX power
^ permalink raw reply
* [PATCH 1/2] b43: Add lpphy_update_tx_power_npt function to improve TX power handling on LP PHYs
From: Thomas Ilnseher @ 2009-09-16 19:27 UTC (permalink / raw)
To: John Linville
Cc: Broadcom Wireless, linux-wireless, Larry Finger,
Gábor Stefanik
The lpphy_update_tx_power_npt routine is currently missing in the code.
I added the routine according to the specs.
Signed-off-by: Thomas Ilnseher <illth@gmx.de>
---
diff -uNr compat-wireless-2009-09-15/drivers/net/wireless/b43/b43.h compat-wireless-2009-09-15.mod/drivers/net/wireless/b43/b43.h
--- compat-wireless-2009-09-15/drivers/net/wireless/b43/b43.h 2009-09-15 06:13:53.000000000 +0200
+++ compat-wireless-2009-09-15.mod/drivers/net/wireless/b43/b43.h 2009-09-15 23:35:02.651859159 +0200
@@ -255,7 +255,10 @@
#define B43_SHM_SH_MAXBFRAMES 0x0080 /* Maximum number of frames in a burst */
#define B43_SHM_SH_SPUWKUP 0x0094 /* pre-wakeup for synth PU in us */
#define B43_SHM_SH_PRETBTT 0x0096 /* pre-TBTT in us */
-
+/* MAC Statistics */
+#define B43_SHM_SH_TX_FRAMES_SENT 0x00E0 /* # TX Frames sent */
+#define B43_SHM_SH_TX_RTS 0x00E2 /* # TX RTS */
+#define B43_SHM_SH_TX_CTS 0x00E4 /* # TX CTS */
/* SHM_SCRATCH offsets */
#define B43_SHM_SC_MINCONT 0x0003 /* Minimum contention window */
#define B43_SHM_SC_MAXCONT 0x0004 /* Maximum contention window */
diff -uNr compat-wireless-2009-09-15/drivers/net/wireless/b43/phy_lp.c compat-wireless-2009-09-15.mod/drivers/net/wireless/b43/phy_lp.c
--- compat-wireless-2009-09-15/drivers/net/wireless/b43/phy_lp.c 2009-09-15 06:13:53.000000000 +0200
+++ compat-wireless-2009-09-15.mod/drivers/net/wireless/b43/phy_lp.c 2009-09-16 00:00:20.712857949 +0200
@@ -1103,6 +1103,28 @@
(u16)~B43_LPPHY_TX_PWR_CTL_CMD_MODE, ctl);
}
+static void lpphy_update_tx_power_npt(struct b43_wldev *dev)
+{
+ u16 tx_cnt;
+ u16 npt;
+ u16 s3;
+
+ s3 = b43_shm_read16(dev, B43_SHM_SHARED, B43_SHM_SH_TX_FRAMES_SENT);
+ tx_cnt = s3 - dev->phy.lp->tssi_tx_count;
+ npt = (b43_phy_read(dev, B43_LPPHY_TX_PWR_CTL_NNUM) & 0x700) >> 8;
+
+ if ((1 << (npt & 0x1F)) >= tx_cnt)
+ return;
+ /* NB: Spec says do the stuff if xxx < tx_cnt, so return on xxx > txcnt */
+ dev->phy.lp->tssi_tx_count = s3;
+ if (npt < 7) {
+ npt++;
+ b43_phy_maskset(dev, B43_LPPHY_TX_PWR_CTL_NNUM, 0xF8FF, (npt << 8));
+ }
+ dev->phy.lp->tssi_npt = npt;
+ dev->phy.lp->tssi_idx = (b43_phy_read(dev, B43_LPPHY_TX_PWR_CTL_STAT) & 0x7F00) >> 8;
+}
+
static void lpphy_set_tx_power_control(struct b43_wldev *dev,
enum b43_lpphy_txpctl_mode mode)
{
@@ -1116,7 +1138,7 @@
lpphy->txpctl_mode = mode;
if (oldmode == B43_LPPHY_TXPCTL_HW) {
- //TODO Update TX Power NPT
+ lpphy_update_tx_power_npt(dev);
//TODO Clear all TX Power offsets
} else {
if (mode == B43_LPPHY_TXPCTL_HW) {
^ permalink raw reply
* [PATCH 0/2] b43: improve TX power handling for LP PHYs
From: Thomas Ilnseher @ 2009-09-16 19:25 UTC (permalink / raw)
To: John Linville
Cc: Broadcom Wireless, linux-wireless, Larry Finger,
Gábor Stefanik
I implemented the functions:
"lpphy_update_tx_power_npt"
and
"lpphy_set_tx_power_control",
and together, both improve the bitrate of my device:
wlan0 IEEE 802.11bg ESSID:"tommy"
Mode:Managed Frequency:2.412 GHz Access Point: XXX
Bit Rate=54 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality=70/70 Signal level=10 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
without these patches, I maxed out at about 24 Mbit/s.
^ permalink raw reply
* Re: WARNING: at net/mac80211/scan.c:267 ieee80211_scan_completed+0x299/0x2b0 [mac80211]()
From: reinette chatre @ 2009-09-16 18:02 UTC (permalink / raw)
To: Maciej Rutecki
Cc: Linux Kernel Mailing List, Linux Wireless List,
ilw@linux.intel.com, Zhu, Yi
In-Reply-To: <8db1092f0909161036t5bae781eqa6f0a0df308ec4cd@mail.gmail.com>
Hi Maciej,
On Wed, 2009-09-16 at 10:36 -0700, Maciej Rutecki wrote:
> 2009/9/16 reinette chatre <reinette.chatre@intel.com>:
> >
> > The important information is not what you posted here, but still in the
> > dmesg file you provided. In that log we see the following right before
> > the warnings:
> >
> > [ 163.126590] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
> > [ 163.130027] wlan0 direct probe responded
> > [ 163.130032] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
> > [ 163.131924] wlan0: authenticated
> > [ 163.131952] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
> > [ 163.134325] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28 (capab=0x431 status=0 aid=1)
> > [ 163.134331] wlan0: associated
> > [ 163.155938] wlan0: deauthenticating by local choice (reason=3)
> >
> > It shows that association was successful, but something in userspace requested a disconnect.
>
> Hmm. Yes, connect takes more time than in 2.6.31.
You mentioned that you tried to connect to two networks. From the logs I
can understand that the connection to the first network took a long
time. This is also not due to the warnings you encountered (the warnings
only showed up after you disconnected from second network). The reason
why the connection to the first network took so long was some protocol
exchange problems with AP. Here is the relevant information from your
log:
[ 117.741190] wlan0: deauthenticating by local choice (reason=3)
[ 117.741308] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 117.745515] wlan0 direct probe responded
[ 117.745523] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 117.747256] wlan0: authenticated
[ 117.747288] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 117.749529] wlan0: RX AssocResp from 00:1b:11:f6:0f:28 (capab=0x431 status=0 aid=1)
[ 117.749536] wlan0: associated
[ 121.404153] wlan0: deauthenticated from 00:1b:11:f6:0f:28 (Reason: 6)
[ 124.123203] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 124.126121] wlan0 direct probe responded
[ 124.126129] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 124.127876] wlan0: authenticated
[ 124.127906] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 124.130164] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28 (capab=0x431 status=0 aid=1)
[ 124.130172] wlan0: associated
[ 128.263997] wlan0: disassociated (Reason: 3)
[ 128.280067] wlan0: deauthenticating by local choice (reason=3)
[ 130.968263] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 130.970685] wlan0 direct probe responded
[ 130.970692] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 130.972497] wlan0: authenticated
[ 130.972529] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 130.974780] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28 (capab=0x431 status=0 aid=1)
[ 130.974787] wlan0: associated
[ 134.511593] wlan0: deauthenticated from 00:1b:11:f6:0f:28 (Reason: 6)
[ 137.216183] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 137.218606] wlan0 direct probe responded
[ 137.218614] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 137.220520] wlan0: authenticated
[ 137.220555] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 137.222808] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28 (capab=0x431 status=0 aid=1)
[ 137.222815] wlan0: associated
[ 140.758586] wlan0: deauthenticated from 00:1b:11:f6:0f:28 (Reason: 6)
[ 143.513364] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 143.524448] wlan0 direct probe responded
[ 143.524456] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 143.526207] wlan0: authenticated
[ 143.526238] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 143.540625] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28 (capab=0x431 status=0 aid=1)
[ 143.540632] wlan0: associated
[ 162.901260] b44: eth0: powering down PHY
[ 162.919757] wlan0: deauthenticating by local choice (reason=3)
As you can see the AP keeps deauthenticating you with Reason 6. This
means "Incorrect frame type or subtype received from unauthenticated
station". Can you try to connect using wpa_supplicant? When you do make
sure there is no other network managing applications (like network
manager, wicd, or even other instances of wpa_supplicant etc) running.
The connection to the second network went very fast - completed in one
second. But a disconnection was requested locally just as fast. Do you
perhaps have more than one network managing application running?
Reinette
^ permalink raw reply
* Re: WARNING: at net/mac80211/scan.c:267 ieee80211_scan_completed+0x299/0x2b0 [mac80211]()
From: Maciej Rutecki @ 2009-09-16 17:36 UTC (permalink / raw)
To: reinette chatre
Cc: Linux Kernel Mailing List, Linux Wireless List,
ilw@linux.intel.com, Zhu, Yi
In-Reply-To: <1253122055.26521.431.camel@rc-desk>
2009/9/16 reinette chatre <reinette.chatre@intel.com>:
>
> The important information is not what you posted here, but still in the
> dmesg file you provided. In that log we see the following right before
> the warnings:
>
> [ 163.126590] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
> [ 163.130027] wlan0 direct probe responded
> [ 163.130032] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
> [ 163.131924] wlan0: authenticated
> [ 163.131952] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
> [ 163.134325] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28 (capab=0x431 status=0 aid=1)
> [ 163.134331] wlan0: associated
> [ 163.155938] wlan0: deauthenticating by local choice (reason=3)
>
> It shows that association was successful, but something in userspace requested a disconnect.
Hmm. Yes, connect takes more time than in 2.6.31.
>
>>
>> [ 163.208063] ------------[ cut here ]------------
>> [ 163.208114] WARNING: at net/mac80211/scan.c:267
>> ieee80211_scan_completed+0x299/0x2b0 [mac80211]()
>
> I cannot get an exact line match based on the kernel information you
> provided. I assume it is the first warning in
> ieee80211_scan_completed(). This is not serious as it indicates that
> mac80211 received a "scan completed" indication when it was not
> scanning.
>
>
>> [ 163.232845] ------------[ cut here ]------------
>> [ 163.232908] WARNING: at net/wireless/core.c:613
>> wdev_cleanup_work+0xbb/0xe0 [cfg80211]()
>
> This warning has just been reported in linux-wireless also. Perhaps you
> can follow its discussion there. See
> http://thread.gmane.org/gmane.linux.kernel.wireless.general/39607
Thanks for information
--
Maciej Rutecki
http://www.maciek.unixy.pl
^ permalink raw reply
* Re: WARNING: at net/mac80211/scan.c:267 ieee80211_scan_completed+0x299/0x2b0 [mac80211]()
From: reinette chatre @ 2009-09-16 17:27 UTC (permalink / raw)
To: Maciej Rutecki
Cc: Linux Kernel Mailing List, Linux Wireless List,
ilw@linux.intel.com, Zhu, Yi
In-Reply-To: <8db1092f0909160236i5d2b1f31k3ec289fbd9ac0bfa@mail.gmail.com>
Hi Maciej,
> Steps to reproduce:
> 1. Connect to the wireless network (WPA2), it takes long time (longer
> than in 2.6.31)
> 2. Connect to another wireless network:
> 3. Connect fails with error:
The important information is not what you posted here, but still in the
dmesg file you provided. In that log we see the following right before
the warnings:
[ 163.126590] wlan0: direct probe to AP 00:1b:11:f6:0f:28 (try 1)
[ 163.130027] wlan0 direct probe responded
[ 163.130032] wlan0: authenticate with AP 00:1b:11:f6:0f:28 (try 1)
[ 163.131924] wlan0: authenticated
[ 163.131952] wlan0: associate with AP 00:1b:11:f6:0f:28 (try 1)
[ 163.134325] wlan0: RX ReassocResp from 00:1b:11:f6:0f:28 (capab=0x431 status=0 aid=1)
[ 163.134331] wlan0: associated
[ 163.155938] wlan0: deauthenticating by local choice (reason=3)
It shows that association was successful, but something in userspace requested a disconnect.
>
> [ 163.208063] ------------[ cut here ]------------
> [ 163.208114] WARNING: at net/mac80211/scan.c:267
> ieee80211_scan_completed+0x299/0x2b0 [mac80211]()
I cannot get an exact line match based on the kernel information you
provided. I assume it is the first warning in
ieee80211_scan_completed(). This is not serious as it indicates that
mac80211 received a "scan completed" indication when it was not
scanning.
> [ 163.232845] ------------[ cut here ]------------
> [ 163.232908] WARNING: at net/wireless/core.c:613
> wdev_cleanup_work+0xbb/0xe0 [cfg80211]()
This warning has just been reported in linux-wireless also. Perhaps you
can follow its discussion there. See
http://thread.gmane.org/gmane.linux.kernel.wireless.general/39607
Reinette
^ permalink raw reply
* Continuous monitoring of wifi stats
From: John Goyette @ 2009-09-16 17:24 UTC (permalink / raw)
To: linux-wireless
Hello all,
I am looking for some advice on a Libertas related issue. I am having a problem with a recent feature we added to our embedded system that continuously monitors wifi statistics, i.e., signal strength. We are using a Blackfin platform with a Marvell 8686 device in the G-SPI configuration. Our kernel is based on a 2.6.28.6 release.
The problem occurs after pressing Ctrl-C to terminate a user space program that is polling the wireless stats in a loop. A number of libertas error messages appear indicating a failure to download command 0x0000. I am pretty sure there is no command 0x0000, so I do not know how it got queued. Here is a sample of the error messages from dmesg:
libertas: command 0x0000 timed out
libertas: requeueing command 0x0000 due to timeout (#1)
libertas: if_spi_host_to_card: invalid size requested: 0
libertas: DNLD_CMD: hw_host_to_card failed: -22
libertas: command 0x0000 timed out
libertas: requeueing command 0x0000 due to timeout (0000002 <http://schicksw/mantis/view.php?id=2> )
libertas: if_spi_host_to_card: invalid size requested: 0
libertas: DNLD_CMD: hw_host_to_card failed: -22
libertas: command 0x0000 timed out
libertas: requeueing command 0x0000 due to timeout (0000003 <http://schicksw/mantis/view.php?id=3> )
libertas: if_spi_host_to_card: invalid size requested: 0
libertas: DNLD_CMD: hw_host_to_card failed: -22
libertas: command 0x0000 timed out
libertas: Excessive timeouts submitting command 0x0000
This can be reproduced by enabling IEEE Power Savings mode and flooding the card with wireless stats requests by running something like the following from a terminal:
while true; do iwconfig eth1;done
Let this run for 30-60 secs, and then press Ctrl-C. With IEEE power savings off, it may take several minutes, but does eventually give the same problem. I have downloaded the compat-wireless-2.6.30 release and was able to cross-compile it for our kernel. It helped a little in that it seemed to take longer before the error messaged occurred after pressing ctrl-c, but it did not completely resolve the problem.
Has anyone seen something similar? Are there any more recent patches that may address this issue?
Thanks.
-John Goyette
Schick Technologies, Inc.
^ permalink raw reply
* Re: linuxwireless Driver information: zd1211rw
From: Stefan Lippers-Hollmann @ 2009-09-16 17:17 UTC (permalink / raw)
To: Markus Becker; +Cc: linux-wireless
In-Reply-To: <200909161804.04296.mab@comnets.uni-bremen.de>
Hi
On Wednesday 16 September 2009, Markus Becker wrote:
> Hello,
>
> is the information on the page
> http://www.linuxwireless.org/en/users/Drivers/zd1211rw about the Debian
> firmware package still true?
>
> "Firmware is pulled from userspace, get the files here.
> Debian users beware: don't use the the zd1211-firmware package, as this is for
> Debian's fork of the vendor-based driver"
>
> The current debian package contains the same files as in the link
> http://sourceforge.net/project/showfiles.php?group_id=129083
zd1211-firmware (2.16.0.0-0.1) unstable; urgency=low
* NMU
[...]
* Use symlink farm to provide the firmware in the locations used by the
zd1211rw in-kernel driver, as well as the zd1211 extra-kernel driver.
Closes: #383604
* Should be suitable for etch release now. Closes: #411912
[...]
-- Joey Hess <joeyh@debian.org> Wed, 21 Feb 2007 15:09:09 -0500
(the symlink farm is gone by now and the the package only keeps
compatibility with in-kernel zd1211rw, all what's left is the version
number derived from the vendor-based driver)
In other words, the past two major Debian releases (shipping with kernel
2.6.18/ etch and 2.6.26/ lenny respectively) had a working firmware package
available from the non-free section.
Kernel 2.6.18, which was the first to ship with zd1211rw, was released on
Tue, Sep 19 20:42:06 2006 -0700, so the advice pointing at a broken
firmware package in Debian's unreleased branches was true for roughly 4
months and never affected a released version (sarge shipped with kernel
2.6.8, etch with 2.6.18 and zd1211-firmware 2.16.0.0-0.1).
Regards
Stefan Lippers-Hollmann
^ permalink raw reply
* Re: iwlagn rfkill and 2.6.31 on Intel Corporation PRO/Wireless 5100 AGN
From: reinette chatre @ 2009-09-16 16:30 UTC (permalink / raw)
To: Fabio Coatti
Cc: John W. Linville, linux-wireless@vger.kernel.org, mjg@redhat.com
In-Reply-To: <200909161657.44453.fabio.coatti@gmail.com>
Hi Fabio,
On Wed, 2009-09-16 at 07:57 -0700, Fabio Coatti wrote:
> But the behaviour of wifi sybsystem is still weird, (maybe for some faults on
> my side). Basically if the laptop starts with wifi enabled (rfkill off)
> wpa_supplicant can establish a connection, that can be killed by rfkill switch
> (both wifi and bluetooth seems to be killed). But when I turn off rfkill
> switch wpa_supplicant is unable to connect again; looking at syslog/dmesg I
> can see activity in bt stack, but no messages regarding wlan0.
I think at this point you need to bring the interface back up. When you
enable rfkill the interface is brought down, the opposite (bringing
interface up) is not done automatically when you disable rfkill.
Reinette
^ permalink raw reply
* Re: iwlagn: order 2 page allocation failures
From: reinette chatre @ 2009-09-16 16:26 UTC (permalink / raw)
To: Mel Gorman
Cc: Frans Pop, Larry Finger, John W. Linville, Pekka Enberg,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, Andrew Morton,
cl@linux-foundation.org, Krauss, Assaf, Johannes Berg,
Abbas, Mohamed
In-Reply-To: <20090916150239.GG1993@csn.ul.ie>
On Wed, 2009-09-16 at 08:02 -0700, Mel Gorman wrote:
> If vanilla, Reinette, is your patch already upstream or in a subsystem
> tree somewhere?
Not yet.
Reinette
^ permalink raw reply
* linuxwireless Driver information: zd1211rw
From: Markus Becker @ 2009-09-16 16:04 UTC (permalink / raw)
To: linux-wireless
Hello,
is the information on the page
http://www.linuxwireless.org/en/users/Drivers/zd1211rw about the Debian
firmware package still true?
"Firmware is pulled from userspace, get the files here.
Debian users beware: don't use the the zd1211-firmware package, as this is for
Debian's fork of the vendor-based driver"
The current debian package contains the same files as in the link
http://sourceforge.net/project/showfiles.php?group_id=129083
BR,
Markus
^ permalink raw reply
* [PATCH] cfg80211: fix SME connect
From: Johannes Berg @ 2009-09-16 16:04 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
There's a check saying
/* we're good if we have both BSSID and channel */
if (wdev->conn->params.bssid && wdev->conn->params.channel) {
but that isn't true -- we need the BSS struct. This leads
to errors such as
Trying to associate with 00:1b:53:11:dc:40 (SSID='TEST' freq=2412 MHz)
ioctl[SIOCSIWFREQ]: No such file or directory
ioctl[SIOCSIWESSID]: No such file or directory
Association request to the driver failed
Associated with 00:1b:53:11:dc:40
in wpa_supplicant, as reported by Holger.
Instead, we really need to have the BSS struct, and if we
don't, then we need to initiate a scan for it. But we may
already have the BSS struct here, so hang on to it if we
do and scan if we don't.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Tested-by: Holger Schurig <hs4233@mail.mn-solutions.de>
---
net/wireless/sme.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
--- wireless-testing.orig/net/wireless/sme.c 2009-09-15 21:33:41.000000000 -0700
+++ wireless-testing/net/wireless/sme.c 2009-09-15 21:37:58.000000000 -0700
@@ -188,7 +188,7 @@ void cfg80211_conn_work(struct work_stru
rtnl_unlock();
}
-static bool cfg80211_get_conn_bss(struct wireless_dev *wdev)
+static struct cfg80211_bss *cfg80211_get_conn_bss(struct wireless_dev *wdev)
{
struct cfg80211_registered_device *rdev = wiphy_to_dev(wdev->wiphy);
struct cfg80211_bss *bss;
@@ -205,7 +205,7 @@ static bool cfg80211_get_conn_bss(struct
WLAN_CAPABILITY_ESS | WLAN_CAPABILITY_PRIVACY,
capa);
if (!bss)
- return false;
+ return NULL;
memcpy(wdev->conn->bssid, bss->bssid, ETH_ALEN);
wdev->conn->params.bssid = wdev->conn->bssid;
@@ -213,14 +213,14 @@ static bool cfg80211_get_conn_bss(struct
wdev->conn->state = CFG80211_CONN_AUTHENTICATE_NEXT;
schedule_work(&rdev->conn_work);
- cfg80211_put_bss(bss);
- return true;
+ return bss;
}
static void __cfg80211_sme_scan_done(struct net_device *dev)
{
struct wireless_dev *wdev = dev->ieee80211_ptr;
struct cfg80211_registered_device *rdev = wiphy_to_dev(wdev->wiphy);
+ struct cfg80211_bss *bss;
ASSERT_WDEV_LOCK(wdev);
@@ -234,7 +234,10 @@ static void __cfg80211_sme_scan_done(str
wdev->conn->state != CFG80211_CONN_SCAN_AGAIN)
return;
- if (!cfg80211_get_conn_bss(wdev)) {
+ bss = cfg80211_get_conn_bss(wdev);
+ if (bss) {
+ cfg80211_put_bss(bss);
+ } else {
/* not found */
if (wdev->conn->state == CFG80211_CONN_SCAN_AGAIN)
schedule_work(&rdev->conn_work);
@@ -670,6 +673,7 @@ int __cfg80211_connect(struct cfg80211_r
{
struct wireless_dev *wdev = dev->ieee80211_ptr;
struct ieee80211_channel *chan;
+ struct cfg80211_bss *bss = NULL;
int err;
ASSERT_WDEV_LOCK(wdev);
@@ -760,7 +764,7 @@ int __cfg80211_connect(struct cfg80211_r
/* don't care about result -- but fill bssid & channel */
if (!wdev->conn->params.bssid || !wdev->conn->params.channel)
- cfg80211_get_conn_bss(wdev);
+ bss = cfg80211_get_conn_bss(wdev);
wdev->sme_state = CFG80211_SME_CONNECTING;
wdev->connect_keys = connkeys;
@@ -770,10 +774,11 @@ int __cfg80211_connect(struct cfg80211_r
wdev->conn->prev_bssid_valid = true;
}
- /* we're good if we have both BSSID and channel */
- if (wdev->conn->params.bssid && wdev->conn->params.channel) {
+ /* we're good if we have a matching bss struct */
+ if (bss) {
wdev->conn->state = CFG80211_CONN_AUTHENTICATE_NEXT;
err = cfg80211_conn_do_work(wdev);
+ cfg80211_put_bss(bss);
} else {
/* otherwise we'll need to scan for the AP first */
err = cfg80211_conn_scan(wdev);
^ permalink raw reply
* Re: [b43] About supporting of BCM4312 [14e4:4315] with Low Power PHY
From: Larry Finger @ 2009-09-16 15:52 UTC (permalink / raw)
To: Bryan Wu; +Cc: Gábor Stefanik, mb, linux-wireless
In-Reply-To: <4AB0EDEB.9010803@canonical.com>
Bryan Wu wrote:
> Do you guys think it is related to 64bit DMA issue? I really want to help to develop this b43 opensource driver,
> anything need me to do, please feel free ping me.
Not an issue with 64-bit DMA. Those people with 64-bit DMA problems
get error messages.
Larry
^ permalink raw reply
* Re: iwlagn: order 2 page allocation failures
From: Frans Pop @ 2009-09-16 15:37 UTC (permalink / raw)
To: Mel Gorman
Cc: Larry Finger, John W. Linville, Pekka Enberg, linux-kernel,
linux-wireless, ipw3945-devel, Andrew Morton, cl, Assaf Krauss,
Johannes Berg, Mohamed Abbas
In-Reply-To: <20090916150239.GG1993@csn.ul.ie>
On Wednesday 16 September 2009, Mel Gorman wrote:
> > kcryptd: page allocation failure. order:2, mode:0x4020
> > Pid: 1347, comm: kcryptd Not tainted 2.6.31-rc9 #16
>
> Is this with Reinette Chatre's patch applied or vanilla?
Vanilla.
^ permalink raw reply
* Re: Re[6]: cfg80211 and rfkill_backport question.
From: Hin-Tak Leung @ 2009-09-16 15:24 UTC (permalink / raw)
To: Nikolai ZHUBR
Cc: Luis R. Rodriguez, linux-wireless, Gaurav Jauhar,
Senthil Balasubramanian
In-Reply-To: <1382256815.20090916121443@mail.ru>
On Wed, Sep 16, 2009 at 10:14 AM, Nikolai ZHUBR <zhubr@mail.ru> wrote:
> Hello Luis!
>
> Wednesday, September 16, 2009, 4:17:40 AM, Luis R. Rodriguez wrote:
>> They don't have to be exported and inlined, its one or the other. So
> Yes, that's what I supposed.
>> just ensure you your symbols you have conflicts with as
>> EXPORT_SYMBOL() or defined in a header file as inline. You will
>> obviously also need the header declaration if defined as an
>> EXPORT_SYMBOL.
> From what I checked it all looks fine to me, except that there is
> a circular dependency between cfg80211 and rfkill_backport (which
> is confirmed by nm output I suppose). Is this circular dependency
> intentional? Or, could it be avoided? (My understanding was that
> as module loader loads one file at a time, it just have no way
> to resolve such symbols, maybe I'm wrong on this)
Hmm, yes and no... insmod loads modules one at a time; but as long as
you run depmod, modprobe loads dependent modules automatically. I
don't know if modprobe works for circular dependency, but it probably
works correctly (since AFAIK, it reference-counts)?
^ 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