* [PATCH 0/2] ath9k_htc fixes, resend
From: Oleksij Rempel @ 2013-07-19 18:16 UTC (permalink / raw)
To: linux-wireless, ath9k-devel, linville; +Cc: Oleksij Rempel
Hi John,
this patches needed to fix firmare/adapter hang issue on
reboot or module reload.
Oleksij Rempel (2):
ath9k_htc: do some initial hardware configuration
ath9k_htc: reboot firmware if it was loaded
drivers/net/wireless/ath/ath9k/hif_usb.c | 4 +++-
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
--
1.8.1.2
^ permalink raw reply
* Re: Wake-On-Wireless and Deauthentication
From: greg.huber @ 2013-07-19 18:06 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, daniel.wagner, Dan Williams
In-Reply-To: <CAB=NE6UPz=6NuCMvy5FEM9QBg9rhwFTw0mG2YVTX3r3dLG=1cQ@mail.gmail.com>
Thank you for your reply, I'm trying this now.
Greg
On 07/18/2013 09:38 PM, Luis R. Rodriguez wrote:
> On Wed, Jul 17, 2013 at 11:11 AM, greg.huber <greg.huber@carestream.com> wrote:
>> I'm trying to get Wake-on-wireless working with an Atheros AR9462.
>> The problem I seem to be having is that there is a Deauth requested
>> when the system is suspended. Does anyone know how to keep the
>> association while suspended?? I'm using kernel 3.9.9.
>>
>> The log after waking (from keyboard)
>>
>> [ 320.117062] wlp3s0: deauthenticating from 00:24:01:12:de:7a by local choice
>> (reason=3)
> Typical managers for networking will disassociate you (and therefore
> deauth first) prior to kicking the system to suspend. To test WoW you
> need to run the supplicant manually because as far as I can tell the
> GUI managers don't consider if WoW was enabled or not. In such a case
> that WoW was enabled the GUI managers should not send the
> deauth/disassoc.
>
> Luis
>
^ permalink raw reply
* pull request: wireless 2013-07-19
From: John W. Linville @ 2013-07-19 17:19 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 24997 bytes --]
Dave,
Please accept this batch of fixes intended for the 3.11 tree...
Alexey Khoroshilov fixes a suspend-related race in ath9k_htc.
Arnd Bergmann corrects the alignment of a structure in the ssb code
to be compatible with ARM devices.
Bob Copeland provides an ath5k fix that corrects a mistaken variable
initialization.
Felix Fietkau corrects some frame accounting for dropped frames
in ath9k.
Geert Uytterhoeven brings a Kconfig fix to indicate the DMA
requirements for rt2x00.
Larry Finger offers two rtlwifi fixes: one that properly initializes
a callback; and, a scattered collection of Kconfig, Makefile, and
EXPORT_SYMBOL changes that correct some build problems.
Finally, Sujith Manoharan provides an ath9k fix to disable a feature
on a specific hardware device.
Please let me know if there are any problems!
Thanks,
John
---
The following changes since commit ecb2cf1a6b63825a258ff4fe0d7f3070fbe4676b:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2013-07-18 20:08:47 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem
for you to fetch changes up to 876fbb5d3ebab01685fef3839d245481c30eab5f:
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem (2013-07-19 12:54:28 -0400)
----------------------------------------------------------------
Alexey Khoroshilov (1):
ath9k_htc: fix data race between request_firmware_nowait() callback and suspend()
Arnd Bergmann (1):
ssb: fix alignment of struct bcma_device_id
Bob Copeland (1):
ath5k: fix extra set bit in multicast mask
Felix Fietkau (1):
ath9k: fix tx pending frames accounting for dropped packets
Geert Uytterhoeven (1):
rt2x00: RT2X00 should depend on HAS_DMA
John W. Linville (1):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Larry Finger (2):
rtlwifi: Initialize power-setting callback for USB devices
rtlwifi: Fix build errors for unusual cases
Sujith Manoharan (1):
ath9k_hw: Fix multicast search for AR9002 family
drivers/net/wireless/ath/ath5k/mac80211-ops.c | 2 +-
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 10 +++-
drivers/net/wireless/ath/ath9k/hif_usb.c | 9 ++--
drivers/net/wireless/ath/ath9k/xmit.c | 44 ++++++++++------
drivers/net/wireless/rt2x00/Kconfig | 2 +-
drivers/net/wireless/rtlwifi/Kconfig | 72 ++++++++++++++++++---------
drivers/net/wireless/rtlwifi/Makefile | 10 ++--
drivers/net/wireless/rtlwifi/base.c | 19 +++++--
drivers/net/wireless/rtlwifi/base.h | 2 +-
drivers/net/wireless/rtlwifi/core.c | 1 +
drivers/net/wireless/rtlwifi/debug.c | 1 +
drivers/net/wireless/rtlwifi/efuse.c | 1 +
drivers/net/wireless/rtlwifi/pci.c | 22 +++-----
drivers/net/wireless/rtlwifi/ps.c | 16 ++++++
drivers/net/wireless/rtlwifi/ps.h | 1 +
drivers/net/wireless/rtlwifi/usb.c | 9 ++++
include/linux/mod_devicetable.h | 5 +-
17 files changed, 154 insertions(+), 72 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/mac80211-ops.c b/drivers/net/wireless/ath/ath5k/mac80211-ops.c
index 81b686c..40825d4 100644
--- a/drivers/net/wireless/ath/ath5k/mac80211-ops.c
+++ b/drivers/net/wireless/ath/ath5k/mac80211-ops.c
@@ -325,7 +325,7 @@ ath5k_prepare_multicast(struct ieee80211_hw *hw,
struct netdev_hw_addr *ha;
mfilt[0] = 0;
- mfilt[1] = 1;
+ mfilt[1] = 0;
netdev_hw_addr_list_for_each(ha, mc_list) {
/* calculate XOR of eight 6-bit values */
diff --git a/drivers/net/wireless/ath/ath9k/ar5008_phy.c b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
index d1acfe9..1576d58 100644
--- a/drivers/net/wireless/ath/ath9k/ar5008_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar5008_phy.c
@@ -610,7 +610,15 @@ static void ar5008_hw_override_ini(struct ath_hw *ah,
REG_SET_BIT(ah, AR_DIAG_SW, (AR_DIAG_RX_DIS | AR_DIAG_RX_ABORT));
if (AR_SREV_9280_20_OR_LATER(ah)) {
- val = REG_READ(ah, AR_PCU_MISC_MODE2);
+ /*
+ * For AR9280 and above, there is a new feature that allows
+ * Multicast search based on both MAC Address and Key ID.
+ * By default, this feature is enabled. But since the driver
+ * is not using this feature, we switch it off; otherwise
+ * multicast search based on MAC addr only will fail.
+ */
+ val = REG_READ(ah, AR_PCU_MISC_MODE2) &
+ (~AR_ADHOC_MCAST_KEYID_ENABLE);
if (!AR_SREV_9271(ah))
val &= ~AR_PCU_MISC_MODE2_HWWAR1;
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 9e582e1..2469db5 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -1082,7 +1082,7 @@ static void ath9k_hif_usb_firmware_fail(struct hif_device_usb *hif_dev)
struct device *dev = &hif_dev->udev->dev;
struct device *parent = dev->parent;
- complete(&hif_dev->fw_done);
+ complete_all(&hif_dev->fw_done);
if (parent)
device_lock(parent);
@@ -1131,7 +1131,7 @@ static void ath9k_hif_usb_firmware_cb(const struct firmware *fw, void *context)
release_firmware(fw);
hif_dev->flags |= HIF_USB_READY;
- complete(&hif_dev->fw_done);
+ complete_all(&hif_dev->fw_done);
return;
@@ -1316,7 +1316,10 @@ static int ath9k_hif_usb_suspend(struct usb_interface *interface,
if (!(hif_dev->flags & HIF_USB_START))
ath9k_htc_suspend(hif_dev->htc_handle);
- ath9k_hif_usb_dealloc_urbs(hif_dev);
+ wait_for_completion(&hif_dev->fw_done);
+
+ if (hif_dev->flags & HIF_USB_READY)
+ ath9k_hif_usb_dealloc_urbs(hif_dev);
return 0;
}
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index c59ae43..9279927 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -146,6 +146,28 @@ static void ath_set_rates(struct ieee80211_vif *vif, struct ieee80211_sta *sta,
ARRAY_SIZE(bf->rates));
}
+static void ath_txq_skb_done(struct ath_softc *sc, struct ath_txq *txq,
+ struct sk_buff *skb)
+{
+ int q;
+
+ q = skb_get_queue_mapping(skb);
+ if (txq == sc->tx.uapsdq)
+ txq = sc->tx.txq_map[q];
+
+ if (txq != sc->tx.txq_map[q])
+ return;
+
+ if (WARN_ON(--txq->pending_frames < 0))
+ txq->pending_frames = 0;
+
+ if (txq->stopped &&
+ txq->pending_frames < sc->tx.txq_max_pending[q]) {
+ ieee80211_wake_queue(sc->hw, q);
+ txq->stopped = false;
+ }
+}
+
static void ath_tx_flush_tid(struct ath_softc *sc, struct ath_atx_tid *tid)
{
struct ath_txq *txq = tid->ac->txq;
@@ -167,6 +189,7 @@ static void ath_tx_flush_tid(struct ath_softc *sc, struct ath_atx_tid *tid)
if (!bf) {
bf = ath_tx_setup_buffer(sc, txq, tid, skb);
if (!bf) {
+ ath_txq_skb_done(sc, txq, skb);
ieee80211_free_txskb(sc->hw, skb);
continue;
}
@@ -811,6 +834,7 @@ ath_tx_get_tid_subframe(struct ath_softc *sc, struct ath_txq *txq,
if (!bf) {
__skb_unlink(skb, &tid->buf_q);
+ ath_txq_skb_done(sc, txq, skb);
ieee80211_free_txskb(sc->hw, skb);
continue;
}
@@ -1824,6 +1848,7 @@ static void ath_tx_send_ampdu(struct ath_softc *sc, struct ath_txq *txq,
bf = ath_tx_setup_buffer(sc, txq, tid, skb);
if (!bf) {
+ ath_txq_skb_done(sc, txq, skb);
ieee80211_free_txskb(sc->hw, skb);
return;
}
@@ -2090,6 +2115,7 @@ int ath_tx_start(struct ieee80211_hw *hw, struct sk_buff *skb,
bf = ath_tx_setup_buffer(sc, txq, tid, skb);
if (!bf) {
+ ath_txq_skb_done(sc, txq, skb);
if (txctl->paprd)
dev_kfree_skb_any(skb);
else
@@ -2189,7 +2215,7 @@ static void ath_tx_complete(struct ath_softc *sc, struct sk_buff *skb,
struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb);
struct ath_common *common = ath9k_hw_common(sc->sc_ah);
struct ieee80211_hdr * hdr = (struct ieee80211_hdr *)skb->data;
- int q, padpos, padsize;
+ int padpos, padsize;
unsigned long flags;
ath_dbg(common, XMIT, "TX complete: skb: %p\n", skb);
@@ -2225,21 +2251,7 @@ static void ath_tx_complete(struct ath_softc *sc, struct sk_buff *skb,
spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
__skb_queue_tail(&txq->complete_q, skb);
-
- q = skb_get_queue_mapping(skb);
- if (txq == sc->tx.uapsdq)
- txq = sc->tx.txq_map[q];
-
- if (txq == sc->tx.txq_map[q]) {
- if (WARN_ON(--txq->pending_frames < 0))
- txq->pending_frames = 0;
-
- if (txq->stopped &&
- txq->pending_frames < sc->tx.txq_max_pending[q]) {
- ieee80211_wake_queue(sc->hw, q);
- txq->stopped = false;
- }
- }
+ ath_txq_skb_done(sc, txq, skb);
}
static void ath_tx_complete_buf(struct ath_softc *sc, struct ath_buf *bf,
diff --git a/drivers/net/wireless/rt2x00/Kconfig b/drivers/net/wireless/rt2x00/Kconfig
index 9b915d3..3e60a31 100644
--- a/drivers/net/wireless/rt2x00/Kconfig
+++ b/drivers/net/wireless/rt2x00/Kconfig
@@ -1,6 +1,6 @@
menuconfig RT2X00
tristate "Ralink driver support"
- depends on MAC80211
+ depends on MAC80211 && HAS_DMA
---help---
This will enable the support for the Ralink drivers,
developed in the rt2x00 project <http://rt2x00.serialmonkey.com>.
diff --git a/drivers/net/wireless/rtlwifi/Kconfig b/drivers/net/wireless/rtlwifi/Kconfig
index 7253de3..c2ffce7 100644
--- a/drivers/net/wireless/rtlwifi/Kconfig
+++ b/drivers/net/wireless/rtlwifi/Kconfig
@@ -1,27 +1,20 @@
-config RTLWIFI
- tristate "Realtek wireless card support"
- depends on MAC80211
- select FW_LOADER
- ---help---
- This is common code for RTL8192CE/RTL8192CU/RTL8192SE/RTL8723AE
- drivers. This module does nothing by itself - the various front-end
- drivers need to be enabled to support any desired devices.
-
- If you choose to build as a module, it'll be called rtlwifi.
-
-config RTLWIFI_DEBUG
- bool "Debugging output for rtlwifi driver family"
- depends on RTLWIFI
+menuconfig RTL_CARDS
+ tristate "Realtek rtlwifi family of devices"
+ depends on MAC80211 && (PCI || USB)
default y
---help---
- To use the module option that sets the dynamic-debugging level for,
- the front-end driver, this parameter must be "Y". For memory-limited
- systems, choose "N". If in doubt, choose "Y".
+ This option will enable support for the Realtek mac80211-based
+ wireless drivers. Drivers rtl8192ce, rtl8192cu, rtl8192se, rtl8192de,
+ rtl8723eu, and rtl8188eu share some common code.
+
+if RTL_CARDS
config RTL8192CE
tristate "Realtek RTL8192CE/RTL8188CE Wireless Network Adapter"
- depends on RTLWIFI && PCI
+ depends on PCI
select RTL8192C_COMMON
+ select RTLWIFI
+ select RTLWIFI_PCI
---help---
This is the driver for Realtek RTL8192CE/RTL8188CE 802.11n PCIe
wireless network adapters.
@@ -30,7 +23,9 @@ config RTL8192CE
config RTL8192SE
tristate "Realtek RTL8192SE/RTL8191SE PCIe Wireless Network Adapter"
- depends on RTLWIFI && PCI
+ depends on PCI
+ select RTLWIFI
+ select RTLWIFI_PCI
---help---
This is the driver for Realtek RTL8192SE/RTL8191SE 802.11n PCIe
wireless network adapters.
@@ -39,7 +34,9 @@ config RTL8192SE
config RTL8192DE
tristate "Realtek RTL8192DE/RTL8188DE PCIe Wireless Network Adapter"
- depends on RTLWIFI && PCI
+ depends on PCI
+ select RTLWIFI
+ select RTLWIFI_PCI
---help---
This is the driver for Realtek RTL8192DE/RTL8188DE 802.11n PCIe
wireless network adapters.
@@ -48,7 +45,9 @@ config RTL8192DE
config RTL8723AE
tristate "Realtek RTL8723AE PCIe Wireless Network Adapter"
- depends on RTLWIFI && PCI
+ depends on PCI
+ select RTLWIFI
+ select RTLWIFI_PCI
---help---
This is the driver for Realtek RTL8723AE 802.11n PCIe
wireless network adapters.
@@ -57,7 +56,9 @@ config RTL8723AE
config RTL8188EE
tristate "Realtek RTL8188EE Wireless Network Adapter"
- depends on RTLWIFI && PCI
+ depends on PCI
+ select RTLWIFI
+ select RTLWIFI_PCI
---help---
This is the driver for Realtek RTL8188EE 802.11n PCIe
wireless network adapters.
@@ -66,7 +67,9 @@ config RTL8188EE
config RTL8192CU
tristate "Realtek RTL8192CU/RTL8188CU USB Wireless Network Adapter"
- depends on RTLWIFI && USB
+ depends on USB
+ select RTLWIFI
+ select RTLWIFI_USB
select RTL8192C_COMMON
---help---
This is the driver for Realtek RTL8192CU/RTL8188CU 802.11n USB
@@ -74,7 +77,28 @@ config RTL8192CU
If you choose to build it as a module, it will be called rtl8192cu
+config RTLWIFI
+ tristate
+ select FW_LOADER
+
+config RTLWIFI_PCI
+ tristate
+
+config RTLWIFI_USB
+ tristate
+
+config RTLWIFI_DEBUG
+ bool "Debugging output for rtlwifi driver family"
+ depends on RTLWIFI
+ default y
+ ---help---
+ To use the module option that sets the dynamic-debugging level for,
+ the front-end driver, this parameter must be "Y". For memory-limited
+ systems, choose "N". If in doubt, choose "Y".
+
config RTL8192C_COMMON
tristate
depends on RTL8192CE || RTL8192CU
- default m
+ default y
+
+endif
diff --git a/drivers/net/wireless/rtlwifi/Makefile b/drivers/net/wireless/rtlwifi/Makefile
index ff02b87..d56f023 100644
--- a/drivers/net/wireless/rtlwifi/Makefile
+++ b/drivers/net/wireless/rtlwifi/Makefile
@@ -12,13 +12,11 @@ rtlwifi-objs := \
rtl8192c_common-objs += \
-ifneq ($(CONFIG_PCI),)
-rtlwifi-objs += pci.o
-endif
+obj-$(CONFIG_RTLWIFI_PCI) += rtl_pci.o
+rtl_pci-objs := pci.o
-ifneq ($(CONFIG_USB),)
-rtlwifi-objs += usb.o
-endif
+obj-$(CONFIG_RTLWIFI_USB) += rtl_usb.o
+rtl_usb-objs := usb.o
obj-$(CONFIG_RTL8192C_COMMON) += rtl8192c/
obj-$(CONFIG_RTL8192CE) += rtl8192ce/
diff --git a/drivers/net/wireless/rtlwifi/base.c b/drivers/net/wireless/rtlwifi/base.c
index 9d558ac..7651f5a 100644
--- a/drivers/net/wireless/rtlwifi/base.c
+++ b/drivers/net/wireless/rtlwifi/base.c
@@ -172,6 +172,7 @@ u8 rtl_tid_to_ac(u8 tid)
{
return tid_to_ac[tid];
}
+EXPORT_SYMBOL_GPL(rtl_tid_to_ac);
static void _rtl_init_hw_ht_capab(struct ieee80211_hw *hw,
struct ieee80211_sta_ht_cap *ht_cap)
@@ -406,6 +407,7 @@ void rtl_deinit_deferred_work(struct ieee80211_hw *hw)
cancel_delayed_work(&rtlpriv->works.ps_rfon_wq);
cancel_delayed_work(&rtlpriv->works.fwevt_wq);
}
+EXPORT_SYMBOL_GPL(rtl_deinit_deferred_work);
void rtl_init_rfkill(struct ieee80211_hw *hw)
{
@@ -439,6 +441,7 @@ void rtl_deinit_rfkill(struct ieee80211_hw *hw)
{
wiphy_rfkill_stop_polling(hw->wiphy);
}
+EXPORT_SYMBOL_GPL(rtl_deinit_rfkill);
int rtl_init_core(struct ieee80211_hw *hw)
{
@@ -489,10 +492,12 @@ int rtl_init_core(struct ieee80211_hw *hw)
return 0;
}
+EXPORT_SYMBOL_GPL(rtl_init_core);
void rtl_deinit_core(struct ieee80211_hw *hw)
{
}
+EXPORT_SYMBOL_GPL(rtl_deinit_core);
void rtl_init_rx_config(struct ieee80211_hw *hw)
{
@@ -501,6 +506,7 @@ void rtl_init_rx_config(struct ieee80211_hw *hw)
rtlpriv->cfg->ops->get_hw_reg(hw, HW_VAR_RCR, (u8 *) (&mac->rx_conf));
}
+EXPORT_SYMBOL_GPL(rtl_init_rx_config);
/*********************************************************
*
@@ -879,6 +885,7 @@ bool rtl_tx_mgmt_proc(struct ieee80211_hw *hw, struct sk_buff *skb)
return true;
}
+EXPORT_SYMBOL_GPL(rtl_tx_mgmt_proc);
void rtl_get_tcb_desc(struct ieee80211_hw *hw,
struct ieee80211_tx_info *info,
@@ -1052,6 +1059,7 @@ bool rtl_action_proc(struct ieee80211_hw *hw, struct sk_buff *skb, u8 is_tx)
return true;
}
+EXPORT_SYMBOL_GPL(rtl_action_proc);
/*should call before software enc*/
u8 rtl_is_special_data(struct ieee80211_hw *hw, struct sk_buff *skb, u8 is_tx)
@@ -1125,6 +1133,7 @@ u8 rtl_is_special_data(struct ieee80211_hw *hw, struct sk_buff *skb, u8 is_tx)
return false;
}
+EXPORT_SYMBOL_GPL(rtl_is_special_data);
/*********************************************************
*
@@ -1300,6 +1309,7 @@ void rtl_beacon_statistic(struct ieee80211_hw *hw, struct sk_buff *skb)
rtlpriv->link_info.bcn_rx_inperiod++;
}
+EXPORT_SYMBOL_GPL(rtl_beacon_statistic);
void rtl_watchdog_wq_callback(void *data)
{
@@ -1793,6 +1803,7 @@ void rtl_recognize_peer(struct ieee80211_hw *hw, u8 *data, unsigned int len)
mac->vendor = vendor;
}
+EXPORT_SYMBOL_GPL(rtl_recognize_peer);
/*********************************************************
*
@@ -1849,6 +1860,7 @@ struct attribute_group rtl_attribute_group = {
.name = "rtlsysfs",
.attrs = rtl_sysfs_entries,
};
+EXPORT_SYMBOL_GPL(rtl_attribute_group);
MODULE_AUTHOR("lizhaoming <chaoming_li@realsil.com.cn>");
MODULE_AUTHOR("Realtek WlanFAE <wlanfae@realtek.com>");
@@ -1856,7 +1868,8 @@ MODULE_AUTHOR("Larry Finger <Larry.FInger@lwfinger.net>");
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Realtek 802.11n PCI wireless core");
-struct rtl_global_var global_var = {};
+struct rtl_global_var rtl_global_var = {};
+EXPORT_SYMBOL_GPL(rtl_global_var);
static int __init rtl_core_module_init(void)
{
@@ -1864,8 +1877,8 @@ static int __init rtl_core_module_init(void)
pr_err("Unable to register rtl_rc, use default RC !!\n");
/* init some global vars */
- INIT_LIST_HEAD(&global_var.glb_priv_list);
- spin_lock_init(&global_var.glb_list_lock);
+ INIT_LIST_HEAD(&rtl_global_var.glb_priv_list);
+ spin_lock_init(&rtl_global_var.glb_list_lock);
return 0;
}
diff --git a/drivers/net/wireless/rtlwifi/base.h b/drivers/net/wireless/rtlwifi/base.h
index 8576bc3..0e5fe09 100644
--- a/drivers/net/wireless/rtlwifi/base.h
+++ b/drivers/net/wireless/rtlwifi/base.h
@@ -147,7 +147,7 @@ void rtl_recognize_peer(struct ieee80211_hw *hw, u8 *data, unsigned int len);
u8 rtl_tid_to_ac(u8 tid);
extern struct attribute_group rtl_attribute_group;
void rtl_easy_concurrent_retrytimer_callback(unsigned long data);
-extern struct rtl_global_var global_var;
+extern struct rtl_global_var rtl_global_var;
int rtlwifi_rate_mapping(struct ieee80211_hw *hw,
bool isht, u8 desc_rate, bool first_ampdu);
bool rtl_tx_mgmt_proc(struct ieee80211_hw *hw, struct sk_buff *skb);
diff --git a/drivers/net/wireless/rtlwifi/core.c b/drivers/net/wireless/rtlwifi/core.c
index ee84844..733b7ce 100644
--- a/drivers/net/wireless/rtlwifi/core.c
+++ b/drivers/net/wireless/rtlwifi/core.c
@@ -1330,3 +1330,4 @@ const struct ieee80211_ops rtl_ops = {
.rfkill_poll = rtl_op_rfkill_poll,
.flush = rtl_op_flush,
};
+EXPORT_SYMBOL_GPL(rtl_ops);
diff --git a/drivers/net/wireless/rtlwifi/debug.c b/drivers/net/wireless/rtlwifi/debug.c
index 7d52d3d..76e2086 100644
--- a/drivers/net/wireless/rtlwifi/debug.c
+++ b/drivers/net/wireless/rtlwifi/debug.c
@@ -51,3 +51,4 @@ void rtl_dbgp_flag_init(struct ieee80211_hw *hw)
/*Init Debug flag enable condition */
}
+EXPORT_SYMBOL_GPL(rtl_dbgp_flag_init);
diff --git a/drivers/net/wireless/rtlwifi/efuse.c b/drivers/net/wireless/rtlwifi/efuse.c
index 9e38941..838a1ed 100644
--- a/drivers/net/wireless/rtlwifi/efuse.c
+++ b/drivers/net/wireless/rtlwifi/efuse.c
@@ -229,6 +229,7 @@ void read_efuse_byte(struct ieee80211_hw *hw, u16 _offset, u8 *pbuf)
*pbuf = (u8) (value32 & 0xff);
}
+EXPORT_SYMBOL_GPL(read_efuse_byte);
void read_efuse(struct ieee80211_hw *hw, u16 _offset, u16 _size_byte, u8 *pbuf)
{
diff --git a/drivers/net/wireless/rtlwifi/pci.c b/drivers/net/wireless/rtlwifi/pci.c
index c97e9d3..703f839 100644
--- a/drivers/net/wireless/rtlwifi/pci.c
+++ b/drivers/net/wireless/rtlwifi/pci.c
@@ -35,6 +35,13 @@
#include "efuse.h"
#include <linux/export.h>
#include <linux/kmemleak.h>
+#include <linux/module.h>
+
+MODULE_AUTHOR("lizhaoming <chaoming_li@realsil.com.cn>");
+MODULE_AUTHOR("Realtek WlanFAE <wlanfae@realtek.com>");
+MODULE_AUTHOR("Larry Finger <Larry.FInger@lwfinger.net>");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("PCI basic driver for rtlwifi");
static const u16 pcibridge_vendors[PCI_BRIDGE_VENDOR_MAX] = {
PCI_VENDOR_ID_INTEL,
@@ -1008,19 +1015,6 @@ static void _rtl_pci_prepare_bcn_tasklet(struct ieee80211_hw *hw)
return;
}
-static void rtl_lps_change_work_callback(struct work_struct *work)
-{
- struct rtl_works *rtlworks =
- container_of(work, struct rtl_works, lps_change_work);
- struct ieee80211_hw *hw = rtlworks->hw;
- struct rtl_priv *rtlpriv = rtl_priv(hw);
-
- if (rtlpriv->enter_ps)
- rtl_lps_enter(hw);
- else
- rtl_lps_leave(hw);
-}
-
static void _rtl_pci_init_trx_var(struct ieee80211_hw *hw)
{
struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
@@ -1899,7 +1893,7 @@ int rtl_pci_probe(struct pci_dev *pdev,
rtlpriv->rtlhal.interface = INTF_PCI;
rtlpriv->cfg = (struct rtl_hal_cfg *)(id->driver_data);
rtlpriv->intf_ops = &rtl_pci_ops;
- rtlpriv->glb_var = &global_var;
+ rtlpriv->glb_var = &rtl_global_var;
/*
*init dbgp flags before all
diff --git a/drivers/net/wireless/rtlwifi/ps.c b/drivers/net/wireless/rtlwifi/ps.c
index 884bcea..298b615 100644
--- a/drivers/net/wireless/rtlwifi/ps.c
+++ b/drivers/net/wireless/rtlwifi/ps.c
@@ -269,6 +269,7 @@ void rtl_ips_nic_on(struct ieee80211_hw *hw)
spin_unlock_irqrestore(&rtlpriv->locks.ips_lock, flags);
}
+EXPORT_SYMBOL_GPL(rtl_ips_nic_on);
/*for FW LPS*/
@@ -518,6 +519,7 @@ void rtl_swlps_beacon(struct ieee80211_hw *hw, void *data, unsigned int len)
"u_bufferd: %x, m_buffered: %x\n", u_buffed, m_buffed);
}
}
+EXPORT_SYMBOL_GPL(rtl_swlps_beacon);
void rtl_swlps_rf_awake(struct ieee80211_hw *hw)
{
@@ -611,6 +613,19 @@ void rtl_swlps_rf_sleep(struct ieee80211_hw *hw)
MSECS(sleep_intv * mac->vif->bss_conf.beacon_int - 40));
}
+void rtl_lps_change_work_callback(struct work_struct *work)
+{
+ struct rtl_works *rtlworks =
+ container_of(work, struct rtl_works, lps_change_work);
+ struct ieee80211_hw *hw = rtlworks->hw;
+ struct rtl_priv *rtlpriv = rtl_priv(hw);
+
+ if (rtlpriv->enter_ps)
+ rtl_lps_enter(hw);
+ else
+ rtl_lps_leave(hw);
+}
+EXPORT_SYMBOL_GPL(rtl_lps_change_work_callback);
void rtl_swlps_wq_callback(void *data)
{
@@ -922,3 +937,4 @@ void rtl_p2p_info(struct ieee80211_hw *hw, void *data, unsigned int len)
else
rtl_p2p_noa_ie(hw, data, len - FCS_LEN);
}
+EXPORT_SYMBOL_GPL(rtl_p2p_info);
diff --git a/drivers/net/wireless/rtlwifi/ps.h b/drivers/net/wireless/rtlwifi/ps.h
index 4d682b7..88bd76e 100644
--- a/drivers/net/wireless/rtlwifi/ps.h
+++ b/drivers/net/wireless/rtlwifi/ps.h
@@ -49,5 +49,6 @@ void rtl_swlps_rf_awake(struct ieee80211_hw *hw);
void rtl_swlps_rf_sleep(struct ieee80211_hw *hw);
void rtl_p2p_ps_cmd(struct ieee80211_hw *hw, u8 p2p_ps_state);
void rtl_p2p_info(struct ieee80211_hw *hw, void *data, unsigned int len);
+void rtl_lps_change_work_callback(struct work_struct *work);
#endif
diff --git a/drivers/net/wireless/rtlwifi/usb.c b/drivers/net/wireless/rtlwifi/usb.c
index a3532e0..e56778c 100644
--- a/drivers/net/wireless/rtlwifi/usb.c
+++ b/drivers/net/wireless/rtlwifi/usb.c
@@ -32,6 +32,13 @@
#include "ps.h"
#include "rtl8192c/fw_common.h"
#include <linux/export.h>
+#include <linux/module.h>
+
+MODULE_AUTHOR("lizhaoming <chaoming_li@realsil.com.cn>");
+MODULE_AUTHOR("Realtek WlanFAE <wlanfae@realtek.com>");
+MODULE_AUTHOR("Larry Finger <Larry.FInger@lwfinger.net>");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("USB basic driver for rtlwifi");
#define REALTEK_USB_VENQT_READ 0xC0
#define REALTEK_USB_VENQT_WRITE 0x40
@@ -1070,6 +1077,8 @@ int rtl_usb_probe(struct usb_interface *intf,
spin_lock_init(&rtlpriv->locks.usb_lock);
INIT_WORK(&rtlpriv->works.fill_h2c_cmd,
rtl_fill_h2c_cmd_work_callback);
+ INIT_WORK(&rtlpriv->works.lps_change_work,
+ rtl_lps_change_work_callback);
rtlpriv->usb_data_index = 0;
init_completion(&rtlpriv->firmware_loading_complete);
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index b62d4af..45e9214 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -361,7 +361,8 @@ struct ssb_device_id {
__u16 vendor;
__u16 coreid;
__u8 revision;
-};
+ __u8 __pad;
+} __attribute__((packed, aligned(2)));
#define SSB_DEVICE(_vendor, _coreid, _revision) \
{ .vendor = _vendor, .coreid = _coreid, .revision = _revision, }
#define SSB_DEVTABLE_END \
@@ -377,7 +378,7 @@ struct bcma_device_id {
__u16 id;
__u8 rev;
__u8 class;
-};
+} __attribute__((packed,aligned(2)));
#define BCMA_CORE(_manuf, _id, _rev, _class) \
{ .manuf = _manuf, .id = _id, .rev = _rev, .class = _class, }
#define BCMA_CORETABLE_END \
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* Re: net-next is now OPEN
From: Eric Dumazet @ 2013-07-19 13:52 UTC (permalink / raw)
To: Eliezer Tamir; +Cc: David Miller, netdev, netfilter-devel, linux-wireless
In-Reply-To: <1374241922.26476.6.camel@edumazet-glaptop>
On Fri, 2013-07-19 at 06:52 -0700, Eric Dumazet wrote:
> > In the next couple of weeks, I would like to post changes to epoll that
> > add busy polling support.
> >
> > Who should be CC-ed on the patches?
>
> netdev is fine ;)
I meant : netdev + lkml
^ permalink raw reply
* Re: net-next is now OPEN
From: Eric Dumazet @ 2013-07-19 13:52 UTC (permalink / raw)
To: Eliezer Tamir; +Cc: David Miller, netdev, netfilter-devel, linux-wireless
In-Reply-To: <51E93ECE.9000108@linux.intel.com>
On Fri, 2013-07-19 at 16:27 +0300, Eliezer Tamir wrote:
> On 19/07/2013 12:35, David Miller wrote:
> >
> > Please feel free to submit net-next patches now, thanks for being
> > so patient.
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> In the next couple of weeks, I would like to post changes to epoll that
> add busy polling support.
>
> Who should be CC-ed on the patches?
netdev is fine ;)
^ permalink raw reply
* Re: net-next is now OPEN
From: Eliezer Tamir @ 2013-07-19 13:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev, netfilter-devel, linux-wireless
In-Reply-To: <20130719.023518.589482296695696122.davem@davemloft.net>
On 19/07/2013 12:35, David Miller wrote:
>
> Please feel free to submit net-next patches now, thanks for being
> so patient.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
In the next couple of weeks, I would like to post changes to epoll that
add busy polling support.
Who should be CC-ed on the patches?
BTW, Right now I'm seeing very good results.
I have tested with up to 10,000 sockets using sockperf.
There are a few more things I want to do before submitting.
Thanks,
Eliezer
^ permalink raw reply
* Re: brcm80211: machine freezing hard with rfkill on
From: Arend van Spriel @ 2013-07-19 13:15 UTC (permalink / raw)
To: Jiri Slaby
Cc: brcm80211-dev-list, linux-wireless@vger.kernel.org,
Linux kernel mailing list
In-Reply-To: <51E8E482.30505@suse.cz>
On 07/19/13 09:02, Jiri Slaby wrote:
> Hi,
>
> our users report [1] that their machines freeze hard when they have
> rfkill turned on and try to run wpa_supplicant or enable network
> otherwise. This is with BCM43225 over PCI chip.
>
> Any ideas what that could be or how to fix this?
>
> [1] https://bugzilla.novell.com/show_bug.cgi?id=787649
>
> thanks,
Hi Jiri,
Looking in the bug report it seems to be on 3.4 kernel. The commit below
is done later.
Regards,
Arend
---------------
commit 82d8eba358badb466a4e988ecabf0668a8d92e9c
Author: Piotr Haber <phaber@broadcom.com>
Date: Wed Sep 19 22:21:15 2012 +0200
brcmsmac: don't start device when RfKill is engaged
This patch fixes a bug when device is being started
while RfKill switch is engaged, leading to hang
due to partial initialization of hardware.
Tested-by: <dragonn@op.pl>
Reviewed-by: Arend van Spriel <arend@broadcom.com>
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Piotr Haber <phaber@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
^ permalink raw reply
* Re: [BUG] 3.10 regression: hang on suspend
From: Ortwin Glück @ 2013-07-19 12:15 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Arend van Spriel, linux-kernel, linux-wireless
In-Reply-To: <20130719120842.GA1570@redhat.com>
On 19.07.2013 14:08, Stanislaw Gruszka wrote:
> Does crash happen on any suspend or on second one ?
The crash always happens on the first suspend.
Thanks for the patch, I will send results tonight.
Ortwin
^ permalink raw reply
* Re: [BUG] 3.10 regression: hang on suspend
From: Stanislaw Gruszka @ 2013-07-19 12:11 UTC (permalink / raw)
To: Ortwin Glück; +Cc: Arend van Spriel, linux-kernel, linux-wireless
In-Reply-To: <20130719120842.GA1570@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]
On Fri, Jul 19, 2013 at 02:08:42PM +0200, Stanislaw Gruszka wrote:
> On Thu, Jul 18, 2013 at 08:57:59PM +0200, Ortwin Glück wrote:
> > On 07/18/2013 12:55 PM, Stanislaw Gruszka wrote:
> > >objdump -r -d --prefix-addresses net/mac80211/mac80211.ko > mac80211.txt
> > >objdump -r -d --prefix-addresses drivers/net/wireless/iwlwifi/dvm/iwldvm.ko > iwldvm.txt
> >
> > Here you go. Please note, that the offsets have changed due to
> > .config changes. New trace attached. Transcript:
> >
> > iwlagn_mac_remove_interface+0x5f/0x160
> > __ieee80211_suspend+0x4a1/0xb30
> > ieee80211_suspend+0x1a/0x20
>
> Crash happen because we call iwlagn_mac_remove_interface with
> vif_priv->ctx NULL. I do not see any possibility of that other than
> doing ->remove_interface without previous ->add_interface, but I do
> not see how that possible.
>
> Does crash happen on any suspend or on second one ?
>
> I'm attaching patch, which should prevent crash (but not fix the issue,
> just workaround it), plese apply it. If it make suspend work, please then
> reload iwlwifi module with debug=0x3 option, suspend/resume machine and
> provide dmesg output after that.
This time really attaching forgotten patch.
Stanislaw
[-- Attachment #2: iwlwifi_check_ctx_null.patch --]
[-- Type: text/plain, Size: 501 bytes --]
diff --git a/drivers/net/wireless/iwlwifi/dvm/mac80211.c b/drivers/net/wireless/iwlwifi/dvm/mac80211.c
index cab23af..7f25fe1 100644
--- a/drivers/net/wireless/iwlwifi/dvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/dvm/mac80211.c
@@ -1536,6 +1536,9 @@ static void iwlagn_mac_remove_interface(struct ieee80211_hw *hw,
IWL_DEBUG_MAC80211(priv, "enter\n");
+ if (WARN(ctx == NULL, "remove interface with NULL ctx\n"))
+ return;
+
mutex_lock(&priv->mutex);
if (WARN_ON(ctx->vif != vif)) {
^ permalink raw reply related
* Re: [BUG] 3.10 regression: hang on suspend
From: Stanislaw Gruszka @ 2013-07-19 12:08 UTC (permalink / raw)
To: Ortwin Glück; +Cc: Arend van Spriel, linux-kernel, linux-wireless
In-Reply-To: <51E83AB7.6020002@odi.ch>
On Thu, Jul 18, 2013 at 08:57:59PM +0200, Ortwin Glück wrote:
> On 07/18/2013 12:55 PM, Stanislaw Gruszka wrote:
> >objdump -r -d --prefix-addresses net/mac80211/mac80211.ko > mac80211.txt
> >objdump -r -d --prefix-addresses drivers/net/wireless/iwlwifi/dvm/iwldvm.ko > iwldvm.txt
>
> Here you go. Please note, that the offsets have changed due to
> .config changes. New trace attached. Transcript:
>
> iwlagn_mac_remove_interface+0x5f/0x160
> __ieee80211_suspend+0x4a1/0xb30
> ieee80211_suspend+0x1a/0x20
Crash happen because we call iwlagn_mac_remove_interface with
vif_priv->ctx NULL. I do not see any possibility of that other than
doing ->remove_interface without previous ->add_interface, but I do
not see how that possible.
Does crash happen on any suspend or on second one ?
I'm attaching patch, which should prevent crash (but not fix the issue,
just workaround it), plese apply it. If it make suspend work, please then
reload iwlwifi module with debug=0x3 option, suspend/resume machine and
provide dmesg output after that.
Thanks
Stanislaw
^ permalink raw reply
* Re: [PATCH 1/3] ath10k: prevent HTC from being used after stopping
From: Kalle Valo @ 2013-07-19 11:44 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <CA+BoTQkD7U4KY5xq7YhTWz-qFP2f3NuQ=nHDZ2LgYaq+5M3pjg@mail.gmail.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> On 19 July 2013 13:04, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>> Michal Kazior <michal.kazior@tieto.com> writes:
>>
>>> It was possible to submit new HTC commands
>>> after/while HTC stopped. This led to memory
>>> corruption in some rare cases.
>>>
>>> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>>
>> [...]
>>
>>> @@ -957,7 +955,6 @@ void ath10k_htc_stop(struct ath10k_htc *htc)
>>> }
>>>
>>> ath10k_hif_stop(htc->ar);
>>> - ath10k_htc_reset_endpoint_states(htc);
>>> }
>>
>> Is this on purpose? I can't fit it to the description.
>
> You're right. I should've mentioned that in the commit message.
>
> This line is simply unnecessary. Do you prefer fixing the commit
> message accordingly or should I post it as a separate patch?
A separate patch, please. Makes it easier to bisect issues later on.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 0/3] ath10k: fixes
From: Kalle Valo @ 2013-07-19 11:43 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <CA+BoTQna=a66_g+_WG8mnENEDEiUcAysa-joeP-xmTM+mYfY=Q@mail.gmail.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> On 19 July 2013 13:07, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>> Michal Kazior <michal.kazior@tieto.com> writes:
>>
>>> Hi,
>>>
>>> Here are some fixes for ath10k. The rts threshold
>>> patch addresses my mistake in commit
>>> 9aeb6fe53d1f0d6e58658484ce9ad7b59f0ef16b which
>>> caused rts to be always enabled causing throughput
>>> issues in some cases.
>>>
>>>
>>> Michal Kazior (3):
>>> ath10k: prevent HTC from being used after stopping
>>> ath10k: fix memleak in mac setup
>>> ath10k: fix rts/fragmentation threshold setup
>>
>> Doesn't apply:
>>
>> Applying: ath10k: prevent HTC from being used after stopping
>> Applying: ath10k: fix memleak in mac setup
>> Applying: ath10k: fix rts/fragmentation threshold setup
>> fatal: sha1 information is lacking or useless (drivers/net/wireless/ath/ath10k/mac.c).
>> Repository lacks necessary blobs to fall back on 3-way merge.
>> Cannot fall back to three-way merge.
>> Patch failed at 0003 ath10k: fix rts/fragmentation threshold setup
>
> Eww. Sorry about that (I did warn you though). Perhaps that's because
> you skipped one of the recovery patches that git is confused now.
No worries. Most likely I could have fixed the conflict myself, but if
3-way merge doesn't work it's too much work.
> I'll resend the whole patchset rebased and with the HTC patch fixed.
Thanks.
--
Kalle Valo
^ permalink raw reply
* Re: v3.10/v3.11-rc1: mac80211/minstrel kernel crash
From: Felix Fietkau @ 2013-07-19 11:36 UTC (permalink / raw)
To: Larry Finger; +Cc: Aaro Koskinen, linux-wireless, netdev, Johannes Berg
In-Reply-To: <51E87A2F.5070305@lwfinger.net>
On 2013-07-19 1:28 AM, Larry Finger wrote:
> On 07/18/2013 05:21 PM, Aaro Koskinen wrote:
>> Hello,
>>
>> It seems this has been broken already a while, I bisected it back to
>> 06d961a8e210035bff7e82f466107f9ab4a8fd94 (mac80211/minstrel: use the
>> new rate control API).
>>
>> Test case:
>>
>> modprobe b43
>> ifconfig wlan0 up
>> iwlist wlan0 scanning
>>
>> Result:
>>
>> [ 95.244268] b43-phy0: Broadcom 4318 WLAN found (core revision 9)
>> [ 95.352823] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7
>> [ 95.423298] ieee80211 phy0: Selected rate control algorithm 'minstrel'
>> [ 95.438266] Broadcom 43xx driver loaded [ Features: PN ]
>> [ 99.482832] b43-phy0: Loading firmware version 666.2 (2011-02-23 01:15:07)
>> [ 99.522916] b43-pci-bridge 0001:01:01.0: Using 32-bit DMA via iommu
>> [ 123.452854] Unable to handle kernel paging request for data at address 0x00000048
>> [ 123.466119] Faulting instruction address: 0xc000000000673a1c
>> [ 123.479072] Oops: Kernel access of bad area, sig: 11 [#1]
>> [ 123.491678] PREEMPT PowerMac
>> [ 123.503946] Modules linked in: b43 netconsole
>> [ 123.515992] CPU: 0 PID: 490 Comm: kworker/u2:4 Not tainted 3.11.0-rc1-imac #1
>> [ 123.527834] Workqueue: phy0 .ieee80211_scan_work
>> [ 123.539275] task: c00000011a6bbdb0 ti: c00000011a120000 task.ti: c00000011a120000
>> [ 123.551071] NIP: c000000000673a1c LR: c000000000653288 CTR: c0000000006739e0
>> [ 123.563010] REGS: c00000011a123310 TRAP: 0300 Not tainted (3.11.0-rc1-imac)
>> [ 123.575142] MSR: 9000000000009032 <SF,HV,EE,ME,IR,DR,RI> CR: 24002082 XER: 00000000
>> [ 123.587884] SOFTE: 1
>> [ 123.600276] DAR: 0000000000000048, DSISR: 40000000
>> [ 123.612867]
>> GPR00: c000000000653288 c00000011a123590 c0000000009dba98 0000000000000000
>> GPR04: 0000000000000000 c00000011a123730 c00000011a123730 0000000000000000
>> GPR08: c00000011a162609 c0000000009d36d8 c0000000006739e0 c00000011a162600
>> GPR12: 0000000024002088 c00000000ffff000 c000000000077d90 c00000011a4dfa70
>> GPR16: 0000000000000000 0000000000000000 0000000000000001 0000000000000000
>> GPR20: 0000000000000000 0000000000000001 c00000000092df7f c00000011a355130
>> GPR24: 000000000000000a c00000011a123b60 c00000011a356660 c00000011a162600
>> GPR28: c00000011a461fc0 c00000011a162600 c00000011a123730 0000000000000000
>> [ 123.728058] NIP [c000000000673a1c] .minstrel_get_rate+0x3c/0x2e0
>> [ 123.740466] LR [c000000000653288] .rate_control_get_rate+0xf8/0x140
>> [ 123.752720] Call Trace:
>> [ 123.764951] [c00000011a123590] [c00000011a123620] 0xc00000011a123620 (unreliable)
>> [ 123.777526] [c00000011a123630] [c000000000653288] .rate_control_get_rate+0xf8/0x140
>> [ 123.790079] [c00000011a1236c0] [c000000000660ac8] .invoke_tx_handlers+0x8c8/0x14f0
>> [ 123.802633] [c00000011a1237f0] [c000000000662304] .ieee80211_tx+0x84/0x140
>> [ 123.815205] [c00000011a1238e0] [c000000000663c70] .__ieee80211_tx_skb_tid_band+0x70/0xa0
>> [ 123.827893] [c00000011a123970] [c000000000669b70] .ieee80211_send_probe_req+0x100/0x150
>> [ 123.840688] [c00000011a123a20] [c000000000645290] .ieee80211_scan_state_send_probe+0xc0/0x120
>> [ 123.853578] [c00000011a123af0] [c00000000064624c] .ieee80211_scan_work+0x26c/0x530
>> [ 123.866581] [c00000011a123bd0] [c00000000006ef5c] .process_one_work+0x17c/0x410
>> [ 123.879178] [c00000011a123c70] [c00000000006fd80] .worker_thread+0x180/0x4d0
>> [ 123.891354] [c00000011a123d40] [c000000000077e78] .kthread+0xe8/0xf0
>> [ 123.903468] [c00000011a123e30] [c000000000008ea0] .ret_from_kernel_thread+0x5c/0xbc
>> [ 123.915706] Instruction dump:
>> [ 123.927916] fbe1fff8 fb61ffd8 fba1ffe8 f8010010 f821ff61 7cbf2b78 7c7c1b78 7cc53378
>> [ 123.940781] 7c832378 7fe4fb78 7cde3378 eba60018 <8b7f0048> 4bfdec61 60000000 2fa30000
>> [ 123.953961] ---[ end trace 5ead5367d5fdf880 ]---
>> [ 123.966739]
>> [ 124.969488] Kernel panic - not syncing: Fatal exception in interrupt
>> [ 124.982408] Rebooting in 180 seconds..
>
> Does it help if you enable CONFIG_MAC80211_RC_MINSTREL_HT and make it default? I
> also have a PPC box with a PCMCIA-based BCM4318 and I do not see the problem
> with those differences. The other difference that I see is that I use the LXDE
> desktop and control the network with NetworkManager.
That bug is known, and Johannes already picked up my fix for it:
https://git.kernel.org/cgit/linux/kernel/git/jberg/mac80211.git/commit/?id=5c9fc93bc9bc417418fc1b6366833ae6a07b804d
Enabling CONFIG_MAC80211_RC_MINSTREL_HT will indeed completely get rid
of the crash.
- Felix
^ permalink raw reply
* Re: [PATCH 0/3] ath10k: fixes
From: Michal Kazior @ 2013-07-19 11:10 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <871u6u4xkk.fsf@kamboji.qca.qualcomm.com>
On 19 July 2013 13:07, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior@tieto.com> writes:
>
>> Hi,
>>
>> Here are some fixes for ath10k. The rts threshold
>> patch addresses my mistake in commit
>> 9aeb6fe53d1f0d6e58658484ce9ad7b59f0ef16b which
>> caused rts to be always enabled causing throughput
>> issues in some cases.
>>
>>
>> Michal Kazior (3):
>> ath10k: prevent HTC from being used after stopping
>> ath10k: fix memleak in mac setup
>> ath10k: fix rts/fragmentation threshold setup
>
> Doesn't apply:
>
> Applying: ath10k: prevent HTC from being used after stopping
> Applying: ath10k: fix memleak in mac setup
> Applying: ath10k: fix rts/fragmentation threshold setup
> fatal: sha1 information is lacking or useless (drivers/net/wireless/ath/ath10k/mac.c).
> Repository lacks necessary blobs to fall back on 3-way merge.
> Cannot fall back to three-way merge.
> Patch failed at 0003 ath10k: fix rts/fragmentation threshold setup
Eww. Sorry about that (I did warn you though). Perhaps that's because
you skipped one of the recovery patches that git is confused now.
I'll resend the whole patchset rebased and with the HTC patch fixed.
Pozdrawiam / Best regards,
Michał Kazior.
^ permalink raw reply
* Re: [PATCH 1/3] ath10k: prevent HTC from being used after stopping
From: Michal Kazior @ 2013-07-19 11:08 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <8761w64xr0.fsf@kamboji.qca.qualcomm.com>
On 19 July 2013 13:04, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior@tieto.com> writes:
>
>> It was possible to submit new HTC commands
>> after/while HTC stopped. This led to memory
>> corruption in some rare cases.
>>
>> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>
> [...]
>
>> @@ -957,7 +955,6 @@ void ath10k_htc_stop(struct ath10k_htc *htc)
>> }
>>
>> ath10k_hif_stop(htc->ar);
>> - ath10k_htc_reset_endpoint_states(htc);
>> }
>
> Is this on purpose? I can't fit it to the description.
You're right. I should've mentioned that in the commit message.
This line is simply unnecessary. Do you prefer fixing the commit
message accordingly or should I post it as a separate patch?
Pozdrawiam / Best regards,
Michał Kazior.
^ permalink raw reply
* Re: [PATCH 0/3] ath10k: fixes
From: Kalle Valo @ 2013-07-19 11:07 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1374129193-3533-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> Hi,
>
> Here are some fixes for ath10k. The rts threshold
> patch addresses my mistake in commit
> 9aeb6fe53d1f0d6e58658484ce9ad7b59f0ef16b which
> caused rts to be always enabled causing throughput
> issues in some cases.
>
>
> Michal Kazior (3):
> ath10k: prevent HTC from being used after stopping
> ath10k: fix memleak in mac setup
> ath10k: fix rts/fragmentation threshold setup
Doesn't apply:
Applying: ath10k: prevent HTC from being used after stopping
Applying: ath10k: fix memleak in mac setup
Applying: ath10k: fix rts/fragmentation threshold setup
fatal: sha1 information is lacking or useless (drivers/net/wireless/ath/ath10k/mac.c).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0003 ath10k: fix rts/fragmentation threshold setup
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/3] ath10k: prevent HTC from being used after stopping
From: Kalle Valo @ 2013-07-19 11:04 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1374129193-3533-2-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> It was possible to submit new HTC commands
> after/while HTC stopped. This led to memory
> corruption in some rare cases.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
[...]
> @@ -957,7 +955,6 @@ void ath10k_htc_stop(struct ath10k_htc *htc)
> }
>
> ath10k_hif_stop(htc->ar);
> - ath10k_htc_reset_endpoint_states(htc);
> }
Is this on purpose? I can't fit it to the description.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath10k: fix NULL dereference for injected packets
From: Kalle Valo @ 2013-07-19 10:36 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless, ymir.kr
In-Reply-To: <1373965494-17726-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> Tx processing functions dereference vif and caused
> NULL to be dereferenced for injected frames.
>
> Don't call these functions at all for injected
> frames. It doesn't make much sense to do so
> anyway.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Thanks, applied.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v3 0/3] ath10k: hardware recovery
From: Kalle Valo @ 2013-07-19 10:32 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1373961277-14784-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> Respin of hw recovery. This implements recovery
> from a firmware crash.
>
> Note: this is based on my
> "ath10k: device setup refactor" patchset.
>
> v3:
> * rename RESTARTING_ON/OFF to RESTARTING/RESTARTED
> * update commit message for 'create debufs..'
>
> Michal Kazior (3):
> ath10k: implement device recovery
> ath10k: implement fw crash simulation command
> ath10k: create debugfs interface to trigger fw crash
Thanks, applied patches 1-2 and dropped patch 3.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v3 3/3] ath10k: create debugfs interface to trigger fw crash
From: Kalle Valo @ 2013-07-19 10:29 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1373961277-14784-4-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> This can be useful for testing. To perform a
> forced firmware crash write 'crash' to
> 'simulate_fw_crash' debugfs file. E.g.
>
> echo crash > /sys/kernel/debug/ieee80211/phy1/ath10k/simulate_fw_crash
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
[...]
> +static ssize_t ath10k_write_simulate_fw_crash(struct file *file,
> + const char __user *user_buf,
> + size_t count, loff_t *ppos)
> +{
> + struct ath10k *ar = file->private_data;
> + char buf[32] = {};
> + int ret;
> +
> + mutex_lock(&ar->conf_mutex);
> +
> + simple_write_to_buffer(buf, sizeof(buf) - 1, ppos, user_buf, count);
> + if (strcmp(buf, "crash") && strcmp(buf, "crash\n")) {
> + ath10k_warn("write keyword `crash` to simulate firmware crash\n");
> + goto exit;
> + }
Better to just return an error here.
> + if (ar->state != ATH10K_STATE_ON &&
> + ar->state != ATH10K_STATE_RESTARTED) {
> + ath10k_warn("firmware isn't loaded yet, nothing to crash\n");
> + goto exit;
> + }
Ditto.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v4 00/10] ath10k: device setup refactor
From: Kalle Valo @ 2013-07-19 10:18 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1373960339-8525-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> This is a respin of my patchset that addresses
> hibernation issues.
>
> This is also groundwork for proper hw recovery
> that I'm going to post too.
>
> v4:
> * update comments in pci logic decoupling
> * add missing commit message for one of the patches
> * update commit message for free_vdev_map patch
>
> Michal Kazior (10):
> ath10k: decouple pci start/stop logic
> ath10k: decouple core start/stop logic
> ath10k: allow deferred regd update
> ath10k: reset BMI state upon init
> ath10k: decouple suspend code
> ath10k: move free_vdev_map initialization
> ath10k: make sure all resources are freed upon ath10k_stop()
> ath10k: defer hw setup to start/stop mac80211 hooks
> ath10k: store firmware files in memory
> ath10k: skip fw stats debugfs interface if device is down
Thanks, all 10 applied.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] brcmsmac: Fix WARNING caused by lack of calls to dma_mapping_error()
From: Arend van Spriel @ 2013-07-19 10:03 UTC (permalink / raw)
To: Larry Finger
Cc: linville, linux-wireless, netdev, Stable, Brett Rudley,
Franky (Zhenhui) Lin, Hante Meuleman, brcm80211-dev-list,
Neil Horman
In-Reply-To: <51D29391.4080000@broadcom.com>
Hi Larry,
Found it catching dust in a corner of my mailbox ;-)
Regards,
Arend
On 07/02/2013 10:47 AM, Arend van Spriel wrote:
> On 07/01/2013 11:08 PM, Larry Finger wrote:
>> The driver fails to check the results of DMA mapping in twp places,
>> which results
>> in the following warning:
>>
>> [ 28.078515] ------------[ cut here ]------------
>> [ 28.078529] WARNING: at lib/dma-debug.c:937 check_unmap+0x47e/0x930()
>> [ 28.078533] bcma-pci-bridge 0000:0e:00.0: DMA-API: device driver
>> failed to check map error[device address=0x00000000b5d60d6c]
>> [size=1876 bytes] [mapped as
>> single]
>> [ 28.078536] Modules linked in: bnep bluetooth vboxpci(O)
>> vboxnetadp(O) vboxnetflt(O) vboxdrv(O) ipv6 b43 brcmsmac rtl8192cu
>> rtl8192c_common rtlwifi mac802
>> 11 brcmutil cfg80211 snd_hda_codec_conexant rng_core snd_hda_intel
>> kvm_amd snd_hda_codec ssb kvm mmc_core snd_pcm snd_seq snd_timer
>> snd_seq_device snd k8temp
>> cordic joydev serio_raw hwmon sr_mod sg pcmcia pcmcia_core soundcore
>> cdrom i2c_nforce2 i2c_core forcedeth bcma snd_page_alloc autofs4 ext4
>> jbd2 mbcache crc1
>> 6 scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh
>> ata_generic pata_amd
>> [ 28.078602] CPU: 1 PID: 2570 Comm: NetworkManager Tainted:
>> G O 3.10.0-rc7-wl+ #42
>> [ 28.078605] Hardware name: Hewlett-Packard HP Pavilion dv2700
>> Notebook PC/30D6, BIOS F.27 11/27/2008
>> [ 28.078607] 0000000000000009 ffff8800bbb03ad8 ffffffff8144f898
>> ffff8800bbb03b18
>> [ 28.078612] ffffffff8103e1eb 0000000000000002 ffff8800b719f480
>> ffff8800b7b9c010
>> [ 28.078617] ffffffff824204c0 ffffffff81754d57 0000000000000754
>> ffff8800bbb03b78
>> [ 28.078622] Call Trace:
>> [ 28.078624] <IRQ> [<ffffffff8144f898>] dump_stack+0x19/0x1b
>> [ 28.078634] [<ffffffff8103e1eb>] warn_slowpath_common+0x6b/0xa0
>> [ 28.078638] [<ffffffff8103e2c1>] warn_slowpath_fmt+0x41/0x50
>> [ 28.078650] [<ffffffff8122d7ae>] check_unmap+0x47e/0x930
>> [ 28.078655] [<ffffffff8122de4c>] debug_dma_unmap_page+0x5c/0x70
>> [ 28.078679] [<ffffffffa04a808c>] dma64_getnextrxp+0x10c/0x190
>> [brcmsmac]
>> [ 28.078691] [<ffffffffa04a9042>] dma_rx+0x62/0x240 [brcmsmac]
>> [ 28.078707] [<ffffffffa0479101>] brcms_c_dpc+0x211/0x9d0 [brcmsmac]
>> [ 28.078717] [<ffffffffa046d927>] ? brcms_dpc+0x27/0xf0 [brcmsmac]
>> [ 28.078731] [<ffffffffa046d947>] brcms_dpc+0x47/0xf0 [brcmsmac]
>> [ 28.078736] [<ffffffff81047dcc>] tasklet_action+0x6c/0xf0
>> --snip--
>> [ 28.078974] [<ffffffff813891bd>] SyS_sendmsg+0xd/0x20
>> [ 28.078979] [<ffffffff81455c24>] tracesys+0xdd/0xe2
>> [ 28.078982] ---[ end trace 6164d1a08148e9c8 ]---
>> [ 28.078984] Mapped at:
>> [ 28.078985] [<ffffffff8122c8fd>] debug_dma_map_page+0x9d/0x150
>> [ 28.078989] [<ffffffffa04a9322>] dma_rxfill+0x102/0x3d0 [brcmsmac]
>> [ 28.079001] [<ffffffffa047a13d>] brcms_c_init+0x87d/0x1100 [brcmsmac]
>> [ 28.079010] [<ffffffffa046d851>] brcms_init+0x21/0x30 [brcmsmac]
>> [ 28.079018] [<ffffffffa04786e0>] brcms_c_up+0x150/0x430 [brcmsmac]
>>
>> As the patch adds a new failure mechanism to dma_rxfill(). When I
>> changed the
>> comment at the start of the routine to add that information, I also
>> polished
>> the wording.
>
> Thanks, Larry
>
> I think there a bugzilla issue for this that you might want to reference:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=60261
>
>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>> Cc: Stable <stable@vger.kernel.org>
>> Cc: Brett Rudley <brudley@broadcom.com>
>> Cc: Arend van Spriel <arend@broadcom.com>
>> Cc: Franky (Zhenhui) Lin <frankyl@broadcom.com>
>> Cc: Hante Meuleman <meuleman@broadcom.com>
>> Cc: brcm80211-dev-list@broadcom.com
>> ---
>>
>> drivers/net/wireless/brcm80211/brcmsmac/dma.c | 12 ++++++++----
>> 1 file changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/wireless/brcm80211/brcmsmac/dma.c
>> b/drivers/net/wireless/brcm80211/brcmsmac/dma.c
>> index 1860c57..6260571 100644
>> --- a/drivers/net/wireless/brcm80211/brcmsmac/dma.c
>> +++ b/drivers/net/wireless/brcm80211/brcmsmac/dma.c
>> @@ -1015,9 +1015,10 @@ static bool dma64_txidle(struct dma_info *di)
>>
>> /*
>> * post receive buffers
>> - * return false is refill failed completely and ring is empty this
>> will stall
>> - * the rx dma and user might want to call rxfill again asap. This
>> unlikely
>> - * happens on memory-rich NIC, but often on memory-constrained dongle
>> + * return false is refill failed completely or dma mapping failed.
>> The ring
>
> Missed some polishing opportunity: return false is refill... -> return
> false if refill...
>
>> + * is empty, which will stall the rx dma and user might want to call
>> rxfill
>> + * again asap. This is unlikely to happen on a memory-rich NIC, but
>> often on
>> + * memory-constrained dongle
>> */
>> bool dma_rxfill(struct dma_pub *pub)
>> {
>> @@ -1078,6 +1079,8 @@ bool dma_rxfill(struct dma_pub *pub)
>>
>> pa = dma_map_single(di->dmadev, p->data, di->rxbufsize,
>> DMA_FROM_DEVICE);
>> + if (dma_mapping_error(di->dmadev,pa))
>> + return false;
>>
>> /* save the free packet pointer */
>> di->rxp[rxout] = p;
>> @@ -1284,7 +1287,8 @@ static void dma_txenq(struct dma_info *di,
>> struct sk_buff *p)
>>
>> /* get physical address of buffer start */
>> pa = dma_map_single(di->dmadev, data, len, DMA_TO_DEVICE);
>> -
>> + if(dma_mapping_error(di->dmadev, pa))
>> + return;
>
> I think the caller(s) should be informed or silently free the sk_buff
> here so we are not leaking it.
>
>> /* With a DMA segment list, Descriptor table is filled
>> * using the segment list instead of looping over
>> * buffers in multi-chain DMA. Therefore, EOF for SGLIST
>>
>
> Regards,
> Arend
^ permalink raw reply
* Re: Connection not established with Realtek RTL8188CUS based USB device (EDIMAX)
From: Paul Menzel @ 2013-07-19 9:47 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless
In-Reply-To: <1371681372.11916.5.camel@mattotaupa>
[-- Attachment #1: Type: text/plain, Size: 5237 bytes --]
Am Donnerstag, den 20.06.2013, 00:36 +0200 schrieb Paul Menzel:
> Am Samstag, den 15.06.2013, 16:08 -0500 schrieb Larry Finger:
> > On 06/15/2013 02:57 PM, Paul Menzel wrote:
>
> > > hopefully I am contacting the correct list. I am not able to use the
> > > Realtek RTL8188CUS based USB WLAN device Edimax EW-7811Un.
> > >
> > > Bus 002 Device 005: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]
> > >
> > > The device did not work with Debian Wheezy with Linux 3.2.x, Debian
> > > Sid/unstable with Linux 3.9.x, Ubuntu 12.04 with Linux 3.2.12 to 3.5 and
> > > Ubuntu 13.04 with Linux 3.8. The person, from whom the device is from,
> > > claims the device once worked with Ubuntu, but I do not know which
> > > version and what WLAN type(?) this was with.
> > >
> > > The behavior is always the same. The device is detected and the
> > > NetworkManager applet `nm-applet` is also able to detect the available
> > > networks. But wanting to connect to one and entering the correct
> > > password, the connection cannot be established and I am asked for the
> > > password again. I tested this with different systems and different
> > > networks and also with wpa_supplicant. A Ralink based WLAN USB device
> > > works just fine.
> > >
> > > The Realtek RTL8188CUS WLAN device works also fine under Microsoft
> > > Windows, so the device is functional.
> >
> > Use a compat-wireless package from 3.10-rc1 or later. If that fails, then I will
> > give you a debug sequence to run.
>
> I just built Linux 3.10-rc6+ (containing the patch you attached in your
> other reply)
>
> $ git describe
> v3.10-rc6-84-gc069114
>
> and it still fails. Though with a different error message.
>
> kernel: [ 174.729668] rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try to reconnect now
> kernel: [ 174.729753] wlan1: Connection to AP yy:yy:yy:yy:yy:yy lost
> wpa_supplicant[5247]: wlan1: WPA: 4-Way Handshake failed - pre-shared key may be incorrect
> wpa_supplicant[5247]: wlan1: CTRL-EVENT-DISCONNECTED bssid=yy:yy:yy:yy:yy:yy reason=4
>
> I am pretty sure I am using a WPA2 WLAN. The NetworkManager developer
> Dan Williams confirmed that [1].
>
> Please find the parts from `/var/log/syslog` attached.
>
> It also contains a backtrace, which I reported a bug about already
> somewhere. (I’ll get the reference later.)
>
> [ 168.601781] ------------[ cut here ]------------
> [ 168.601805] WARNING: at kernel/workqueue.c:1365 __queue_work+0x177/0x1d1()
> [ 168.601809] Modules linked in: arc4 rtl8192cu rtlwifi mac80211 cfg80211 rtl8192c_common ip6table_filter ip6_tables iptable_filter ip_tables x_tables binfmt_misc reiserfs xfs crc32c libcrc32c w83627ehf hwmon_vid loop firewire_sbp2 firewire_core crc_itu_t fuse radeon snd_hda_codec_realtek snd_hda_intel snd_hda_codec backlight snd_hwdep drm_kms_helper snd_pcm snd_page_alloc ttm snd_seq_midi snd_seq_midi_event snd_rawmidi drm snd_seq snd_seq_device snd_timer kvm_amd kvm snd i2c_algo_bit soundcore psmouse processor button serio_raw evdev ext3 mbcache jbd sha256_generic cbc dm_crypt dm_mod raid1 md_mod usbhid sd_mod crc_t10dif r8169 mii fan thermal thermal_sys ahci libahci libata scsi_mod sp5100_tco
> [ 168.601896] CPU: 1 PID: 39 Comm: kworker/1:2 Not tainted 3.10.0-rc6+ #103
> [ 168.601900] Hardware name: ASROCK E350M1, BIOS 4.0-4334-geca6d02 06/19/2013
> [ 168.601912] Workqueue: rtl92c_usb rtl_watchdog_wq_callback [rtlwifi]
> [ 168.601916] f66e17b8 c1023f9b c10364f3 f66e6f00 f4032840 f2c51084 00000001 c1023fbb
> [ 168.601925] 00000009 00000000 c10364f3 f66d8f80 00000008 00000297 f2c51084 00000008
> [ 168.601933] f2c50e00 c1036585 f4032840 f2c50d80 00000000 00000000 f8429287 00000000
> [ 168.601942] Call Trace:
> [ 168.601952] [<c1023f9b>] ? warn_slowpath_common+0x4d/0x60
> [ 168.601958] [<c10364f3>] ? __queue_work+0x177/0x1d1
> [ 168.601964] [<c1023fbb>] ? warn_slowpath_null+0xd/0x10
> [ 168.601969] [<c10364f3>] ? __queue_work+0x177/0x1d1
> [ 168.601975] [<c1036585>] ? queue_work_on+0x2b/0x36
> [ 168.601984] [<f8429287>] ? rtl_watchdog_wq_callback+0x1d9/0x37f [rtlwifi]
> [ 168.601992] [<c1042a00>] ? finish_task_switch+0x37/0x89
> [ 168.601998] [<c12fe282>] ? __schedule+0x441/0x4c7
> [ 168.602004] [<c1037459>] ? process_one_work+0x14c/0x230
> [ 168.602010] [<c1037871>] ? worker_thread+0x107/0x1bd
> [ 168.602015] [<c103776a>] ? rescuer_thread+0x210/0x210
> [ 168.602021] [<c103b099>] ? kthread+0x68/0x6d
> [ 168.602027] [<c1302f37>] ? ret_from_kernel_thread+0x1b/0x28
> [ 168.602032] [<c103b031>] ? __kthread_parkme+0x50/0x50
> [ 168.602036] ---[ end trace 40aa884081d482ce ]---
the device still does not work with Linux 3.10. Larry, could you please
give me the instructions how to debug this? That would be great.
Thanks,
Paul
> [1] https://mail.gnome.org/archives/networkmanager-list/2013-June/msg00112.html
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH v2] mac80211: prevent the buffering or frame transmission to non-assoc mesh STA
From: Chun-Yeow Yeoh @ 2013-07-19 9:37 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, linville, Chun-Yeow Yeoh
This patch is intended to avoid the buffering to non-assoc mesh STA
and also to avoid the triggering of frame to non-assoc mesh STA which
could cause kernel panic in specific hw.
One of the examples, is kernel panic happens to ath9k if user space
inserts the mesh STA and not proceed with the SAE and AMPE, and later
the same mesh STA is detected again. The sta_state of the mesh STA remains
at IEEE80211_STA_NONE and if the ieee80211_sta_ps_deliver_wakeup is called
and subsequently the ath_tx_aggr_wakeup, the kernel panic due to
ath_tx_node_init is not called before to initialize the require data
structures.
This issue is reported by Cedric Voncken before.
http://www.spinics.net/lists/linux-wireless/msg106342.html
[<831ea6b4>] ath_tx_aggr_wakeup+0x44/0xcc [ath9k]
[<83084214>] ieee80211_sta_ps_deliver_wakeup+0xb8/0x208 [mac80211]
[<830b9824>] ieee80211_mps_sta_status_update+0x94/0x108 [mac80211]
[<83099398>] ieee80211_sta_ps_transition+0xc94/0x34d8 [mac80211]
[<8022399c>] nf_iterate+0x98/0x104
[<8309bb60>] ieee80211_sta_ps_transition+0x345c/0x34d8 [mac80211]
Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com>
---
v2:
change the subject to be less ath9k-centric (Johannes)
push the checking higher to prevent buffering for non-assoc STA (Bob Copeland)
net/mac80211/mesh_ps.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/mesh_ps.c b/net/mac80211/mesh_ps.c
index 3b7bfc0..22290a9 100644
--- a/net/mac80211/mesh_ps.c
+++ b/net/mac80211/mesh_ps.c
@@ -229,6 +229,10 @@ void ieee80211_mps_sta_status_update(struct sta_info *sta)
enum nl80211_mesh_power_mode pm;
bool do_buffer;
+ /* For non-assoc STA, prevent buffering or frame transmission */
+ if (sta->sta_state < IEEE80211_STA_ASSOC)
+ return;
+
/*
* use peer-specific power mode if peering is established and the
* peer's power mode is known
--
1.7.0.4
^ permalink raw reply related
* net-next is now OPEN
From: David Miller @ 2013-07-19 9:35 UTC (permalink / raw)
To: netdev; +Cc: netfilter-devel, linux-wireless
Please feel free to submit net-next patches now, thanks for being
so patient.
^ 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