* wireless-drivers-next is closed for 4.10
From: Kalle Valo @ 2016-12-08 12:53 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <87oa0zwymr.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@codeaurora.org> writes:
> Linus said that he will release 4.9 either next Sunday or a week after,
> which means that the merge window is getting close. If there's something
> you absolutely need to have in 4.10 better send them NOW to not miss the
> window.
Dave closed net-next earlier than normally so wireless-drivers-next is
closed as well:
https://www.spinics.net/lists/netdev/msg409280.html
I had two patches pending in w-d-next but now I'll need to submit those
to net-next after the merge window and they will go to 4.11.
> Important bug fixes can go to 4.10 also after the merge window, but not
> new features.
wireless-drivers is open for bug fixes going to 4.10.
--
Kalle Valo
^ permalink raw reply
* [PATCH] cfg80211/mac80211: fix BSS leaks when abandoning assoc attempts
From: Johannes Berg @ 2016-12-08 16:28 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
When mac80211 abandons an association attempt, it may free
all the data structures, but inform cfg80211 and userspace
about it only by sending the deauth frame it received, in
which case cfg80211 has no link to the BSS struct that was
used and will not cfg80211_unhold_bss() it.
Fix this by providing a way to inform cfg80211 of this with
the BSS entry passed, so that it can clean up properly, and
use this ability in the appropriate places in mac80211.
This isn't ideal: some code is more or less duplicated and
tracing is missing. However, it's a fairly small change and
it's thus easier to backport - cleanups can come later.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/cfg80211.h | 11 +++++++++++
net/mac80211/mlme.c | 21 ++++++++++++---------
net/wireless/core.h | 1 +
net/wireless/mlme.c | 12 ++++++++++++
net/wireless/sme.c | 14 ++++++++++++++
5 files changed, 50 insertions(+), 9 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index ef42749f785f..ca2ac1ce5862 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -4675,6 +4675,17 @@ void cfg80211_rx_assoc_resp(struct net_device *dev,
void cfg80211_assoc_timeout(struct net_device *dev, struct cfg80211_bss *bss);
/**
+ * cfg80211_abandon_assoc - notify cfg80211 of abandoned association attempt
+ * @dev: network device
+ * @bss: The BSS entry with which association was abandoned.
+ *
+ * Call this whenever - for reasons reported through other API, like deauth RX,
+ * an association attempt was abandoned.
+ * This function may sleep. The caller must hold the corresponding wdev's mutex.
+ */
+void cfg80211_abandon_assoc(struct net_device *dev, struct cfg80211_bss *bss);
+
+/**
* cfg80211_tx_mlme_mgmt - notification of transmitted deauth/disassoc frame
* @dev: network device
* @buf: 802.11 frame (header + body)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 68172d5d2ca0..8a6344518674 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2514,7 +2514,7 @@ static void ieee80211_destroy_auth_data(struct ieee80211_sub_if_data *sdata,
}
static void ieee80211_destroy_assoc_data(struct ieee80211_sub_if_data *sdata,
- bool assoc)
+ bool assoc, bool abandon)
{
struct ieee80211_mgd_assoc_data *assoc_data = sdata->u.mgd.assoc_data;
@@ -2537,6 +2537,9 @@ static void ieee80211_destroy_assoc_data(struct ieee80211_sub_if_data *sdata,
mutex_lock(&sdata->local->mtx);
ieee80211_vif_release_channel(sdata);
mutex_unlock(&sdata->local->mtx);
+
+ if (abandon)
+ cfg80211_abandon_assoc(sdata->dev, assoc_data->bss);
}
kfree(assoc_data);
@@ -2769,7 +2772,7 @@ static void ieee80211_rx_mgmt_deauth(struct ieee80211_sub_if_data *sdata,
bssid, reason_code,
ieee80211_get_reason_code_string(reason_code));
- ieee80211_destroy_assoc_data(sdata, false);
+ ieee80211_destroy_assoc_data(sdata, false, true);
cfg80211_rx_mlme_mgmt(sdata->dev, (u8 *)mgmt, len);
return;
@@ -3178,14 +3181,14 @@ static void ieee80211_rx_mgmt_assoc_resp(struct ieee80211_sub_if_data *sdata,
if (status_code != WLAN_STATUS_SUCCESS) {
sdata_info(sdata, "%pM denied association (code=%d)\n",
mgmt->sa, status_code);
- ieee80211_destroy_assoc_data(sdata, false);
+ ieee80211_destroy_assoc_data(sdata, false, false);
event.u.mlme.status = MLME_DENIED;
event.u.mlme.reason = status_code;
drv_event_callback(sdata->local, sdata, &event);
} else {
if (!ieee80211_assoc_success(sdata, bss, mgmt, len)) {
/* oops -- internal error -- send timeout for now */
- ieee80211_destroy_assoc_data(sdata, false);
+ ieee80211_destroy_assoc_data(sdata, false, false);
cfg80211_assoc_timeout(sdata->dev, bss);
return;
}
@@ -3198,7 +3201,7 @@ static void ieee80211_rx_mgmt_assoc_resp(struct ieee80211_sub_if_data *sdata,
* recalc after assoc_data is NULL but before associated
* is set can cause the interface to go idle
*/
- ieee80211_destroy_assoc_data(sdata, true);
+ ieee80211_destroy_assoc_data(sdata, true, false);
/* get uapsd queues configuration */
uapsd_queues = 0;
@@ -3897,7 +3900,7 @@ void ieee80211_sta_work(struct ieee80211_sub_if_data *sdata)
.u.mlme.status = MLME_TIMEOUT,
};
- ieee80211_destroy_assoc_data(sdata, false);
+ ieee80211_destroy_assoc_data(sdata, false, false);
cfg80211_assoc_timeout(sdata->dev, bss);
drv_event_callback(sdata->local, sdata, &event);
}
@@ -4036,7 +4039,7 @@ void ieee80211_mgd_quiesce(struct ieee80211_sub_if_data *sdata)
WLAN_REASON_DEAUTH_LEAVING,
false, frame_buf);
if (ifmgd->assoc_data)
- ieee80211_destroy_assoc_data(sdata, false);
+ ieee80211_destroy_assoc_data(sdata, false, true);
if (ifmgd->auth_data)
ieee80211_destroy_auth_data(sdata, false);
cfg80211_tx_mlme_mgmt(sdata->dev, frame_buf,
@@ -4945,7 +4948,7 @@ int ieee80211_mgd_deauth(struct ieee80211_sub_if_data *sdata,
IEEE80211_STYPE_DEAUTH,
req->reason_code, tx,
frame_buf);
- ieee80211_destroy_assoc_data(sdata, false);
+ ieee80211_destroy_assoc_data(sdata, false, true);
ieee80211_report_disconnect(sdata, frame_buf,
sizeof(frame_buf), true,
req->reason_code);
@@ -5020,7 +5023,7 @@ void ieee80211_mgd_stop(struct ieee80211_sub_if_data *sdata)
sdata_lock(sdata);
if (ifmgd->assoc_data) {
struct cfg80211_bss *bss = ifmgd->assoc_data->bss;
- ieee80211_destroy_assoc_data(sdata, false);
+ ieee80211_destroy_assoc_data(sdata, false, false);
cfg80211_assoc_timeout(sdata->dev, bss);
}
if (ifmgd->auth_data)
diff --git a/net/wireless/core.h b/net/wireless/core.h
index fb2fcd5581fe..9820fa251daa 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -409,6 +409,7 @@ void cfg80211_sme_disassoc(struct wireless_dev *wdev);
void cfg80211_sme_deauth(struct wireless_dev *wdev);
void cfg80211_sme_auth_timeout(struct wireless_dev *wdev);
void cfg80211_sme_assoc_timeout(struct wireless_dev *wdev);
+void cfg80211_sme_abandon_assoc(struct wireless_dev *wdev);
/* internal helpers */
bool cfg80211_supported_cipher_suite(struct wiphy *wiphy, u32 cipher);
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index bd1f7a159d6a..4646cf5695b9 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -149,6 +149,18 @@ void cfg80211_assoc_timeout(struct net_device *dev, struct cfg80211_bss *bss)
}
EXPORT_SYMBOL(cfg80211_assoc_timeout);
+void cfg80211_abandon_assoc(struct net_device *dev, struct cfg80211_bss *bss)
+{
+ struct wireless_dev *wdev = dev->ieee80211_ptr;
+ struct wiphy *wiphy = wdev->wiphy;
+
+ cfg80211_sme_abandon_assoc(wdev);
+
+ cfg80211_unhold_bss(bss_from_pub(bss));
+ cfg80211_put_bss(wiphy, bss);
+}
+EXPORT_SYMBOL(cfg80211_abandon_assoc);
+
void cfg80211_tx_mlme_mgmt(struct net_device *dev, const u8 *buf, size_t len)
{
struct wireless_dev *wdev = dev->ieee80211_ptr;
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index 2b5bb380414b..5e0d19380302 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -39,6 +39,7 @@ struct cfg80211_conn {
CFG80211_CONN_ASSOCIATING,
CFG80211_CONN_ASSOC_FAILED,
CFG80211_CONN_DEAUTH,
+ CFG80211_CONN_ABANDON,
CFG80211_CONN_CONNECTED,
} state;
u8 bssid[ETH_ALEN], prev_bssid[ETH_ALEN];
@@ -206,6 +207,8 @@ static int cfg80211_conn_do_work(struct wireless_dev *wdev)
cfg80211_mlme_deauth(rdev, wdev->netdev, params->bssid,
NULL, 0,
WLAN_REASON_DEAUTH_LEAVING, false);
+ /* fall through */
+ case CFG80211_CONN_ABANDON:
/* free directly, disconnected event already sent */
cfg80211_sme_free(wdev);
return 0;
@@ -423,6 +426,17 @@ void cfg80211_sme_assoc_timeout(struct wireless_dev *wdev)
schedule_work(&rdev->conn_work);
}
+void cfg80211_sme_abandon_assoc(struct wireless_dev *wdev)
+{
+ struct cfg80211_registered_device *rdev = wiphy_to_rdev(wdev->wiphy);
+
+ if (!wdev->conn)
+ return;
+
+ wdev->conn->state = CFG80211_CONN_ABANDON;
+ schedule_work(&rdev->conn_work);
+}
+
static int cfg80211_sme_get_conn_ies(struct wireless_dev *wdev,
const u8 *ies, size_t ies_len,
const u8 **out_ies, size_t *out_ies_len)
--
2.9.3
^ permalink raw reply related
* Re: ATH9 driver issues on ARM64
From: Kalle Valo @ 2016-12-08 17:36 UTC (permalink / raw)
To: Bharat Kumar Gogada
Cc: Bjorn Helgaas, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, Marc Zyngier,
Janusz.Dziedzic@tieto.com, rmanohar@qti.qualcomm.com,
ath9k-devel@qca.qualcomm.com, linux-wireless
In-Reply-To: <8520D5D51A55D047800579B094147198263A72F5@XAP-PVEXMBX02.xlnx.xilinx.com>
Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com> writes:
> > [+cc Kalle, ath9k list]
Thanks, but please also CC linux-wireless. Full thread below for the
folks there.
>> On Thu, Dec 08, 2016 at 01:49:42PM +0000, Bharat Kumar Gogada wrote:
>> > Hi,
>> >
>> > Did anyone test Atheros ATH9 driver(drivers/net/wireless/ath/ath9k/)
>> > on ARM64. The end point is TP link wifi card with which supports
>> > only legacy interrupts.
>>
>> If it works on other arches and the arm64 PCI enumeration works, my
>> first guess would be an INTx issue, e.g., maybe the driver is waiting
>> for an interrupt that never arrives.
> We are not sure for now.
>>
>> > We are trying to test it on ARM64 with
>> > (drivers/pci/host/pcie-xilinx-nwl.c) as root port.
>> >
>> > EP is getting enumerated and able to link up.
>> >
>> > But when we start scan system gets hanged.
>>
>> When you say the system hangs when you start a scan, I assume you mean
>> a wifi scan, not the PCI enumeration. A problem with a wifi scan
>> might cause a *process* to hang, but it shouldn't hang the entire
>> system.
>>
> Yes wifi scan.
>> > When we took trace we see that after we start scan assert message is
>> > sent but there is no de assert from end point.
>>
>> Are you talking about a trace from a PCIe analyzer? Do you see an
>> Assert_INTx PCIe message on the link?
>>
> Yes lecroy trace, yes we do see Assert_INTx and Deassert_INTx happening when we do interface link up.
> When we have less debug prints in Atheros driver, and do wifi scan we see Assert_INTx but never Deassert_INTx,
>> > What might cause end point not sending de assert ?
>>
>> If the endpoint doesn't send a Deassert_INTx message, I expect that
>> would mean the driver didn't service the interrupt and remove the
>> condition that caused the device to assert the interrupt in the first
>> place.
>>
>> If the driver didn't receive the interrupt, it couldn't service it, of
>> course. You could add a printk in the ath9k interrupt service
>> routine to see if you ever get there.
>>
> The interrupt behavior is changing w.r.t amount of debug prints we add. (I kept many prints to aid debug)
> root@Xilinx-ZCU102-2016_3:~# iw dev wlan0 scan
> [ 83.064675] ath9k: ath9k_iowrite32 ffffff800a400024
> [ 83.069486] ath9k: ath9k_ioread32 ffffff800a400024
> [ 83.074257] ath9k_hw_kill_interrupts 793
> [ 83.078260] ath9k: ath9k_iowrite32 ffffff800a400024
> [ 83.083107] ath9k: ath9k_ioread32 ffffff800a400024
> [ 83.087882] ath9k_hw_kill_interrupts 793
> [ 83.095450] ath9k_hw_enable_interrupts 821
> [ 83.099557] ath9k_hw_enable_interrupts 825
> [ 83.103721] ath9k_hw_enable_interrupts 832
> [ 83.107887] ath9k: ath9k_iowrite32 ffffff800a400024
> [ 83.112748] AR_SREV_9100 0
> [ 83.115438] ath9k_hw_enable_interrupts 848
> [ 83.119607] ath9k: ath9k_ioread32 ffffff800a400024
> [ 83.124389] ath9k_hw_intrpend 762
> [ 83.127761] (AR_SREV_9340(ah) val 0
> [ 83.131234] ath9k_hw_intrpend 767
> [ 83.134628] ath_isr 603
> [ 83.137134] ath9k: ath9k_iowrite32 ffffff800a400024
> [ 83.141995] ath9k: ath9k_ioread32 ffffff800a400024
> [ 83.146771] ath9k_hw_kill_interrupts 793
> [ 83.150864] ath9k_hw_enable_interrupts 821
> [ 83.154971] ath9k_hw_enable_interrupts 825
> [ 83.159135] ath9k_hw_enable_interrupts 832
> [ 83.163300] ath9k: ath9k_iowrite32 ffffff800a400024
> [ 83.168161] AR_SREV_9100 0
> [ 83.170852] ath9k_hw_enable_interrupts 848
> [ 83.170855] ath9k_hw_intrpend 762
> [ 83.178398] (AR_SREV_9340(ah) val 0
> [ 83.181873] ath9k_hw_intrpend 767
> [ 83.185265] ath_isr 603
> [ 83.187773] ath9k: ath9k_iowrite32 ffffff800a400024
> [ 83.192635] ath9k: ath9k_ioread32 ffffff800a400024
> [ 83.197411] ath9k_hw_kill_interrupts 793
> [ 83.201414] ath9k: ath9k_ioread32 ffffff800a400024
> [ 83.206258] ath9k_hw_enable_interrupts 821
> [ 83.210368] ath9k_hw_enable_interrupts 825
> [ 83.214531] ath9k_hw_enable_interrupts 832
> [ 83.218698] ath9k: ath9k_iowrite32 ffffff800a400024
> [ 83.223558] AR_SREV_9100 0
> [ 83.226243] ath9k_hw_enable_interrupts 848
> [ 83.226246] ath9k_hw_intrpend 762
> [ 83.233794] (AR_SREV_9340(ah) val 0
> [ 83.237268] ath9k_hw_intrpend 767
> [ 83.240661] ath_isr 603
> [ 83.243169] ath9k: ath9k_iowrite32 ffffff800a400024
> [ 83.248030] ath9k: ath9k_ioread32 ffffff800a400024
> [ 83.252806] ath9k_hw_kill_interrupts 793
> [ 83.256811] ath9k: ath9k_ioread32 ffffff800a400024
> [ 83.261651] ath9k_hw_enable_interrupts 821
> [ 83.265753] ath9k_hw_enable_interrupts 825
> [ 83.269919] ath9k_hw_enable_interrupts 832
> [ 83.274083] ath9k: ath9k_iowrite32 ffffff800a400024
> [ 83.278945] AR_SREV_9100 0
> [ 83.281630] ath9k_hw_enable_interrupts 848
> [ 83.281633] ath9k_hw_intrpend 762
> [ 83.281634] (AR_SREV_9340(ah) val 0
> [ 83.281637] ath9k_hw_intrpend 767
> [ 83.281648] ath_isr 603
> [ 83.281649] ath9k: ath9k_iowrite32 ffffff800a400024
> [ 83.281651] ath9k: ath9k_ioread32 ffffff800a400024
> [ 83.281654] ath9k_hw_kill_interrupts 793
> [ 83.312192] ath9k: ath9k_ioread32 ffffff800a400024
> [ 83.317030] ath9k_hw_enable_interrupts 821
> [ 83.321132] ath9k_hw_enable_interrupts 825
> [ 83.325297] ath9k_hw_enable_interrupts 832
> [ 83.329463] ath9k: ath9k_iowrite32 ffffff800a400024
> [ 83.334324] AR_SREV_9100 0
> [ 83.337014] ath9k_hw_enable_interrupts 848
> ..
> ..
> This log continues until I turn off board without obtaining scanning result.
>
> In between I get following cpu stall outputs :
> 230.457179] INFO: rcu_sched self-detected stall on CPU
> [ 230.457185] 2-...: (31314 ticks this GP) idle=2d1/140000000000001/0 softirq=1400/1400 fqs=36713
> [ 230.457189] (t=36756 jiffies g=161 c=160 q=16169)
> [ 230.457191] Task dump for CPU 2:
> [ 230.457196] kworker/u8:4 R running task 0 1342 2 0x00000002
> [ 230.457207] Workqueue: phy0 ieee80211_scan_work
> [ 230.457208] Call trace:
> [ 230.457214] [<ffffff8008089860>] dump_backtrace+0x0/0x198
> [ 230.457219] [<ffffff8008089a0c>] show_stack+0x14/0x20
> [ 230.457224] [<ffffff80080c0930>] sched_show_task+0x98/0xf8
> [ 230.457228] [<ffffff80080c2628>] dump_cpu_task+0x40/0x50
> [ 230.457233] [<ffffff80080e14a8>] rcu_dump_cpu_stacks+0xa0/0xf0
> [ 230.457239] [<ffffff80080e4cd8>] rcu_check_callbacks+0x468/0x748
> [ 230.457243] [<ffffff80080e7cfc>] update_process_times+0x3c/0x68
> [ 230.457249] [<ffffff80080f6dfc>] tick_sched_handle.isra.5+0x3c/0x50
> [ 230.457253] [<ffffff80080f6e54>] tick_sched_timer+0x44/0x90
> [ 230.457257] [<ffffff80080e86b0>] __hrtimer_run_queues+0xf0/0x178
> ** 10 printk messages dropped ** [ 230.457302] f8c0: 0000000000000000 0000000005f5e0ff 000000000001379a 3866666666666620
> [ 230.457306] f8e0: ffffff800a1b4065 0000000000000006 ffffff800a129000 ffffffc87b8010a8
> [ 230.457310] f900: ffffff808a1b4057 ffffff800a1c3000 ffffff800a1b3000 ffffff800a13b000
> [ 230.457314] f920: 0000000000000140 0000000000000006 ffffff800a1b3b10 ffffff800a1c39e8
> [ 230.457318] f940: 000000000000002f ffffff800a1b8a98 ffffff800a1b3ae8 ffffffc87b07f990
> [ 230.457322] f960: ffffff80080d6230 ffffffc87b07f990 ffffff80080d6234 0000000060000145
> ** 1 printk messages dropped ** [ 230.457329] [<ffffff8008085720>] el1_irq+0xa0/0x100
> ** 9 printk messages dropped ** [ 230.457373] [<ffffff800885ad60>] ieee80211_hw_config+0x50/0x290
> [ 230.457377] [<ffffff8008863690>] ieee80211_scan_work+0x1f8/0x480
> [ 230.457383] [<ffffff80080b15d0>] process_one_work+0x120/0x378
> [ 230.457386] [<ffffff80080b1870>] worker_thread+0x48/0x4b0
> [ 230.457391] [<ffffff80080b7108>] kthread+0xd0/0xe8
> [ 230.457395] [<ffffff8008085dd0>] ret_from_fork+0x10/0x40
> [ 230.480389] ath9k_hw_intrpend 762
>
>
> [ 545.487987] ath9k: ath9k_ioread32 ffffff800a400024
> [ 545.526189] INFO: rcu_sched self-detected stall on CPU
> [ 545.526195] 2-...: (97636 ticks this GP) idle=2d1/140000000000001/0 softirq=1400/1400 fqs=115374
> [ 545.526199] (t=115523 jiffies g=161 c=160 q=51066)
> [ 545.526201] Task dump for CPU 2:
> [ 545.526206] kworker/u8:4 R running task 0 1342 2 0x00000002
> ** 3 printk messages dropped ** [ 545.526231] [<ffffff8008089a0c>] show_stack+0x14/0x20
> ** 9 printk messages dropped ** [ 545.526280] [<ffffff80086a71e8>] arch_timer_handler_phys+0x30/0x40
> [ 545.526284] [<ffffff80080dbe18>] handle_percpu_devid_irq+0x78/0xa0
> [ 545.526291] [<ffffff80080d760c>] generic_handle_irq+0x24/0x38
> [ 545.526296] [<ffffff80080d7944>] __handle_domain_irq+0x5c/0xb8
> [ 545.526299] [<ffffff80080824bc>] gic_handle_irq+0x64/0xc0
> [ 545.526302] Exception stack(0xffffffc87b07f870 to 0xffffffc87b07f990)
> [ 545.526306] f860: 0000000000009732 ffffff800a1eaaa8
> ** 8 printk messages dropped ** [ 545.526341] f980: ffffff800a1c39e8 0000000000000036
> [ 545.526345] [<ffffff8008085720>] el1_irq+0xa0/0x100
> [ 545.526349] [<ffffff80080d6234>] console_unlock+0x384/0x5b0
> [ 545.526353] [<ffffff80080d673c>] vprintk_emit+0x2dc/0x4b0
> [ 545.526357] [<ffffff80080d6a50>] vprintk_default+0x38/0x40
> [ 545.526362] [<ffffff8008129704>] printk+0x58/0x60
> [ 545.526366] [<ffffff800859e3e4>] ath9k_iowrite32+0x9c/0xa8
> [ 545.526372] [<ffffff80085c7ca8>] ath9k_hw_kill_interrupts+0x28/0xf0
> [ 545.526376] [<ffffff80085a18ec>] ath_reset+0x24/0x68
> ** 2 printk messages dropped ** [ 545.526391] [<ffffff800885ad60>] ieee80211_hw_config+0x50/0x290
> ** 11 printk messages dropped ** [ 545.532834] ath9k_hw_kill_interrupts 793
> [ 545.532890] ath9k_hw_enable_interrupts 821
>
>
> But if we have less debug prints it does not reach EP handler sometimes, due to following
> Condition in "kernel/irq/chip.c" in function handle_simple_irq
>
> if (unlikely(!desc->action || irqd_irq_disabled(&desc->irq_data))) {
> desc->istate |= IRQS_PENDING;
> goto out_unlock;
> }
> Here irqd_irq_disabled is being set to 1.
>
> With lesser debug prints it stops after following prints:
> root@Xilinx-ZCU102-2016_3:~# iw dev wlan0 scan
> [ 54.781045] ath9k_hw_kill_interrupts 793
> [ 54.785007] ath9k_hw_kill_interrupts 793
> [ 54.792535] ath9k_hw_enable_interrupts 821
> [ 54.796642] ath9k_hw_enable_interrupts 825
> [ 54.800807] ath9k_hw_enable_interrupts 832
> [ 54.804973] AR_SREV_9100 0
> [ 54.807663] ath9k_hw_enable_interrupts 848
> [ 54.811843] ath9k_hw_intrpend 762
> [ 54.815211] (AR_SREV_9340(ah) val 0
> [ 54.818684] ath9k_hw_intrpend 767
> [ 54.822078] ath_isr 603
> [ 54.824587] ath9k_hw_kill_interrupts 793
> [ 54.828601] ath9k_hw_enable_interrupts 821
> [ 54.832750] ath9k_hw_enable_interrupts 825
> [ 54.836916] ath9k_hw_enable_interrupts 832
> [ 54.841082] AR_SREV_9100 0
> [ 54.843772] ath9k_hw_enable_interrupts 848
> [ 54.843775] ath9k_hw_intrpend 762
> [ 54.851319] (AR_SREV_9340(ah) val 0
> [ 54.854793] ath9k_hw_intrpend 767
> [ 54.858185] ath_isr 603
> [ 54.860696] ath9k_hw_kill_interrupts 793
> [ 54.864776] ath9k_hw_enable_interrupts 821
> [ 54.867061] ath9k_hw_kill_interrupts 793
> [ 54.872870] ath9k_hw_enable_interrupts 825
> [ 54.877036] ath9k_hw_enable_interrupts 832
> [ 54.881202] AR_SREV_9100 0
> [ 54.883892] ath9k_hw_enable_interrupts 848
> [ 75.963129] INFO: rcu_sched detected stalls on CPUs/tasks:
> [ 75.968602] 0-...: (2 GPs behind) idle=9d5/140000000000001/0 softirq=1103/1109 fqs=519
> [ 75.976675] (detected by 2, t=5274 jiffies, g=64, c=63, q=11)
> [ 75.982485] Task dump for CPU 0:
> [ 75.985696] ksoftirqd/0 R running task 0 3 2 0x00000002
> [ 75.992726] Call trace:
> [ 75.995165] [<ffffff8008086b3c>] __switch_to+0xc4/0xd0
> [ 76.000281] [<ffffffc87b830500>] 0xffffffc87b830500
> [ 139.059027] INFO: rcu_sched detected stalls on CPUs/tasks:
> [ 139.064430] 0-...: (2 GPs behind) idle=9d5/140000000000001/0 softirq=1103/1109 fqs=2097
> [ 139.072593] (detected by 2, t=21049 jiffies, g=64, c=63, q=11)
> [ 139.078489] Task dump for CPU 0:
> [ 139.081700] ksoftirqd/0 R running task 0 3 2 0x00000002
> [ 139.088731] Call trace:
> [ 139.091165] [<ffffff8008086b3c>] __switch_to+0xc4/0xd0
> [ 139.096285] [<ffffffc87b830500>] 0xffffffc87b830500
>
>
>> > We are not seeing any issues on 32-bit ARM platform and X86
>> > platform.
>>
>> Can you collect a dmesg log (or, if the system hang means you can't
>> collect that, a console log with "ignore_loglevel"), and "lspci -vv"
>> output as root? That should have clues about whether the INTx got
>> routed correctly. /proc/interrupts should also show whether we're
>> receiving interrupts from the device.
>
> Here is the lspci output:
> 00:00.0 PCI bridge: Xilinx Corporation Device d022 (prog-if 00 [Normal decode])
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0
> Interrupt: pin A routed to IRQ 224
> Bus: primary=00, secondary=01, subordinate=0c, sec-latency=0
> I/O behind bridge: 00000000-00000fff
> Memory behind bridge: e0000000-e00fffff
> Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
> Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
> BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
> PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
> Capabilities: [40] Power Management version 3
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
> Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [60] Express (v2) Root Port (Slot-), MSI 00
> DevCap: MaxPayload 256 bytes, PhantFunc 0
> ExtTag- RBE+
> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
> MaxPayload 128 bytes, MaxReadReq 512 bytes
> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend+
> LnkCap: Port #0, Speed 5GT/s, Width x2, ASPM not supported, Exit Latency L0s unlimited, L1 unlimited
> ClockPM- Surprise- LLActRep- BwNot+ ASPMOptComp+
> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
> RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible+
> RootCap: CRSVisible+
> RootSta: PME ReqID 0000, PMEStatus- PMEPending-
> DevCap2: Completion Timeout: Range B, TimeoutDis+, LTR-, OBFF Not Supported ARIFwd-
> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd-
> LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
> Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
> Compliance De-emphasis: -6dB
> LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1-
> EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
> Capabilities: [100 v1] Device Serial Number 00-00-00-00-00-00-00-00
> Capabilities: [10c v1] Virtual Channel
> Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
> Arb: Fixed- WRR32- WRR64- WRR128-
> Ctrl: ArbSelect=Fixed
> Status: InProgress-
> VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
> Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
> Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
> Status: NegoPending- InProgress-
> Capabilities: [128 v1] Vendor Specific Information: ID=1234 Rev=1 Len=018 <?>
>
> 01:00.0 Network controller: Qualcomm Atheros AR93xx Wireless Network Adapter (rev 01)
> Subsystem: Qualcomm Atheros Device 3112
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 128 bytes
> Interrupt: pin A routed to IRQ 224
> Region 0: Memory at e0000000 (64-bit, non-prefetchable) [size=128K]
> [virtual] Expansion ROM at e0020000 [disabled] [size=64K]
> Capabilities: [40] Power Management version 3
> Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA PME(D0+,D1+,D2-,D3hot+,D3cold-)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
> Address: 0000000000000000 Data: 0000
> Masking: 00000000 Pending: 00000000
> Capabilities: [70] Express (v2) Endpoint, MSI 00
> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <1us, L1 <8us
> ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W
> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
> MaxPayload 128 bytes, MaxReadReq 512 bytes
> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <2us, L1 <64us
> ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
> DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-, OBFF Not Supported
> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
> LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
> Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
> Compliance De-emphasis: -6dB
> LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
> EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
> Capabilities: [100 v1] Advanced Error Reporting
> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
> AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
> Capabilities: [140 v1] Virtual Channel
> Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
> Arb: Fixed- WRR32- WRR64- WRR128-
> Ctrl: ArbSelect=Fixed
> Status: InProgress-
> VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
> Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
> Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
> Status: NegoPending- InProgress-
> Capabilities: [300 v1] Device Serial Number 00-00-00-00-00-00-00-00
> Kernel driver in use: ath9k
>
> Here is the cat /proc/interrupts (after we do interface up):
>
> root@:~# ifconfig wlan0 up
> [ 1548.926601] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> root@Xilinx-ZCU102-2016_3:~# cat /proc/interrupts
> CPU0 CPU1 CPU2 CPU3
> 1: 0 0 0 0 GICv2 29 Edge arch_timer
> 2: 19873 20058 19089 17435 GICv2 30 Edge arch_timer
> 12: 0 0 0 0 GICv2 156 Level zynqmp-dma
> 13: 0 0 0 0 GICv2 157 Level zynqmp-dma
> 14: 0 0 0 0 GICv2 158 Level zynqmp-dma
> 15: 0 0 0 0 GICv2 159 Level zynqmp-dma
> 16: 0 0 0 0 GICv2 160 Level zynqmp-dma
> 17: 0 0 0 0 GICv2 161 Level zynqmp-dma
> 18: 0 0 0 0 GICv2 162 Level zynqmp-dma
> 19: 0 0 0 0 GICv2 163 Level zynqmp-dma
> 20: 0 0 0 0 GICv2 164 Level Mali_GP_MMU, Mali_GP, Mali_PP0_MMU, Mali_PP0, Mali_PP1_MMU, Mali_PP1
> 30: 0 0 0 0 GICv2 95 Level eth0, eth0
> 206: 314 0 0 0 GICv2 49 Level cdns-i2c
> 207: 40 0 0 0 GICv2 50 Level cdns-i2c
> 209: 0 0 0 0 GICv2 150 Level nwl_pcie:misc
> 214: 12 0 0 0 GICv2 47 Level ff0f0000.spi
> 215: 0 0 0 0 GICv2 58 Level ffa60000.rtc
> 216: 0 0 0 0 GICv2 59 Level ffa60000.rtc
> 217: 0 0 0 0 GICv2 165 Level ahci-ceva[fd0c0000.ahci]
> 218: 61 0 0 0 GICv2 81 Level mmc0
> 219: 0 0 0 0 GICv2 187 Level arm-smmu global fault
> 220: 471 0 0 0 GICv2 53 Level xuartps
> 223: 0 0 0 0 GICv2 154 Level fd4c0000.dma
> 224: 3 0 0 0 dummy 1 Edge ath9k
> 225: 0 0 0 0 GICv2 97 Level xhci-hcd:usb1
>
> Regards,
> Bharat
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 2/2] cfg80211: Add support to sched scan to report better BSSs
From: Malinen, Jouni @ 2016-12-08 17:52 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Vamsi, Krishna, Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <280cb669-2360-d4fc-779b-80196c944e2e@broadcom.com>
On Wed, Dec 07, 2016 at 09:03:23PM +0100, Arend Van Spriel wrote:
> On 7-12-2016 10:33, Vamsi, Krishna wrote:
> >> -----Original Message-----
> >> From: Johannes Berg [mailto:johannes@sipsolutions.net]
> >=20
> >> What about Arend's comment regarding this functionality overlapping wi=
th the
> >> BSS selection offload configuration?
> >>
> >> Do you think there's any ability to share attributes/functionality?
> >=20
> > Hi Johannes,
> >=20
> > I think the later comment from Luca on this which I pasted below is mor=
e agreeable.
> >=20
> > Yes, similar but not quite the same. The existing case is for finding =
BSSs that are worth waking the host up for (while disconnected), so it need=
s to be better than the RSSI passed (absolute number). Now this is about r=
elative RSSI as compared to the current connection, so RELATIVE_RSSI is dif=
ferent than RSSI and I think the same attribute should not be used, to avoi=
d confusion.
>=20
> I noticed the response from Luca, but did not get back on this. I know
> it is not the same, but what I meant is whether we could extend it so it
> also covers your scenario.
I'm not sure I see the point of trying to avoid the new RELATIVE_RSSI
attribute. We need to clearly specify that this new constraint is indeed
for relative comparison against the currently connected BSS.
As far as your second email is concerned, it might make more sense to
use the existing NL80211_ATTR_BSS_SELECT instead of the new
NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF since they cover very
similar purpose in defining RSSI preference between bands. We can take a
look at doing so. One thing to be a careful about this is in what claims
there are about using NL80211_ATTR_BSS_SELECT for capability indication
in GET_WIPHY. I guess we can leave that as-is to apply for _CONNECT and
the new EXT_FEATURE flag we are adding for sched_scan applies for this
attribute in SCHED_SCAN.
--=20
Jouni Malinen PGP id EFC895FA=
^ permalink raw reply
* Re: [PATCH v2 2/2] cfg80211: Add support to sched scan to report better BSSs
From: Arend Van Spriel @ 2016-12-08 20:35 UTC (permalink / raw)
To: Malinen, Jouni
Cc: Vamsi, Krishna, Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <20161208175236.GA6121@jouni.qca.qualcomm.com>
On 8-12-2016 18:52, Malinen, Jouni wrote:
> On Wed, Dec 07, 2016 at 09:03:23PM +0100, Arend Van Spriel wrote:
>> On 7-12-2016 10:33, Vamsi, Krishna wrote:
>>>> -----Original Message-----
>>>> From: Johannes Berg [mailto:johannes@sipsolutions.net]
>>>
>>>> What about Arend's comment regarding this functionality overlapping with the
>>>> BSS selection offload configuration?
>>>>
>>>> Do you think there's any ability to share attributes/functionality?
>>>
>>> Hi Johannes,
>>>
>>> I think the later comment from Luca on this which I pasted below is more agreeable.
>>>
>>> Yes, similar but not quite the same. The existing case is for finding BSSs that are worth waking the host up for (while disconnected), so it needs to be better than the RSSI passed (absolute number). Now this is about relative RSSI as compared to the current connection, so RELATIVE_RSSI is different than RSSI and I think the same attribute should not be used, to avoid confusion.
>>
>> I noticed the response from Luca, but did not get back on this. I know
>> it is not the same, but what I meant is whether we could extend it so it
>> also covers your scenario.
>
> I'm not sure I see the point of trying to avoid the new RELATIVE_RSSI
> attribute. We need to clearly specify that this new constraint is indeed
> for relative comparison against the currently connected BSS.
Hi Jouni,
I am not saying it should be avoided. Just looking at it conceptually
the scheduled scan request holds so-called matchsets that specify the
constraints to determine whether a BSS was found that is worth notifying
the host/user-space about. As such I would expect the relative RSSI
attribute(s) to be part of the matchset. That way you can specify it
together with the currently connected SSID in a single matchset.
> As far as your second email is concerned, it might make more sense to
> use the existing NL80211_ATTR_BSS_SELECT instead of the new
> NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF since they cover very
> similar purpose in defining RSSI preference between bands. We can take a
> look at doing so. One thing to be a careful about this is in what claims
> there are about using NL80211_ATTR_BSS_SELECT for capability indication
> in GET_WIPHY. I guess we can leave that as-is to apply for _CONNECT and
> the new EXT_FEATURE flag we are adding for sched_scan applies for this
> attribute in SCHED_SCAN.
The NL80211_ATTR_BSS_SELECT supports different methods for BSS
selection. One of them being RSSI_ADJUST which is similar to this. It
lets user-space specify the band and adjustment instead of having a band
implied in the attribute name. Agree that if reusing it for scheduled
scan you would still need the EXT_FEATURE flag.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] RFC: Universal scan proposal
From: Dmitry Shmidt @ 2016-12-08 22:35 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <93d4475c-58bd-d497-3347-a988d551f374@broadcom.com>
On Wed, Dec 7, 2016 at 12:51 PM, Arend Van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 7-12-2016 19:39, Dmitry Shmidt wrote:
>> On Tue, Dec 6, 2016 at 10:44 PM, Johannes Berg
>> <johannes@sipsolutions.net> wrote:
>>>
>>>> Indeed, results are results. I just want to take care of two things:
>>>> 1) Memory consumption - we can clear stale scan results for
>>>> connection, but not for location if we are using history scan.
>>>
>>> Well eventually we also have to clear for location if we run out of
>>> memory, that usually means dumping them out to the host, no?
>>
>> Being out of memory and consuming more memory are different
>> things, but I agree - maybe we don't need to worry about it.
>>
>>>> 2) Use of insufficient results for connection - in case we had
>>>> history or hotlist scan only for very limited amount of channels,
>>>> then we may not have enough APs in our result for "sterling"
>>>> connection decision.
>>>
>>> I'm not entirely sure about this case - surely noticing "we can do
>>> better now" is still better than waiting for being able to make the
>>> perfect decision?
>>
>> Maybe we can just keep flag saying that currently available results
>> were not received by usual full scan.
>>
>>>>>> Report: none / batch / immediate
>>>>>
>>>>> Not sure I see much point in "none"??
>>>>>
>>>>> Can you define these more clearly? Do you think "batch" reporting
>>>>> should be like the gscan buckets? Or actually have full
>>>>> information?
>>>>
>>>> None - means that there is not need to report. It can be useful
>>>> in case of roaming scan, scheduling or hotlist scan - you didn't find
>>>> anything suitable - don't report that there is no scan results.
>>>
>>> But that seems more of a filtering thing, combined with "immediate" for
>>> anything passing the filter?
>>
>> We can use this approach as well.
>>
>>>>>> Request may have priority and can be inserted into
>>>>>> the head of the queue.
>>>>>> Types of scans:
>>>>>> - Normal scan
>>>>>> - Scheduled scan
>>>>>> - Hotlist (BSSID scan)
>>>>>> - Roaming
>>>>>> - AutoJoin
>>>>>
>>>>> I think somebody else said this but I didn't find it now - I think
>>>>> this would make more sense to define in terms of expected behaviour
>>>>> than use cases for each type of scan.
>>>>
>>>> I think Luca made this statement.
>>>
>>> Yeah - I just couldn't find it again on re-reading the thread :)
>>>
>>>> It is totally ok from SW point of
>>>> view - especially due to the fact that scan is scan. However,
>>>> I suspect it will be harder to handle from user experience. I mean
>>>> at the end wireless framework / driver / FW will convert special
>>>> scan type to usual scan with special params and response, but why
>>>> to put this burden on user?
>
> I don't think this will put burden on the user although it depends
> who/what you mean by this. If you mean the mere mortal end-user I would
> say no as indeed there must be some software entity (in user-space) that
> will have to initiate a nl80211 command with appropriate attributes
> according to whatever user-space is trying to accomplish.
>
>>> I just think it's more flexible and open-ended. The actual definition
>>> of the resulting parameters needs to be somewhere anyway - putting it
>>> into driver/firmware (vs. wifi framework or so) seems to duplicate it
>>> and certainly makes it harder to modify/extend in the future, no?
>>
>> So, let's summarize:
>> Instead of creating new type of generic scan with special types,
>> we want to go with additional expansion of scheduled scan options and
>> parameters (in order not to "multiply entities"), including ability to send
>> new scheduled scan request without stopping previous one.
>>
>> Is it Ok?
>
> Sounds ok. To me a generic scan command with type attribute is
> equivalent to having seperate commands for each type so there seems to
> be no gain. Now whether this all can be accomplished by extending the
> scheduled scan depends on the problem that you are trying to solve.
>
> Main purpose seems to be offloading different scanning tasks which could
> make scheduled scan a good candidate. Now I want to add gscan to this
> mix as it seems some concepts for that are in play in this discussion as
> well, eg. hotlist. gscan is like scheduled scan, but it supports
> multiple schedules. However, it is still a single request from a single
> user-space process. I think Luca mentioned supporting requests from
> different user-space processes. Is that also what you mean by "ability
> to send new scheduled scan request without stopping previous one" or is
> that still from a single user-space process. Do we need a limit to the
> amount of scheduled scan requests that can be handled simultaneously.
Supporting requests (or more precisely requests and results) differentiated
by user-space entity can be tricky. Right now we are not checking current
caller pid, right? Maybe it is also good idea - or maybe we can just
make result filtering per user-space caller?
> A maybe more important aspect of gscan is user-space control of result
> reporting and thus the frequency of waking up host and/or user-space. I
> suspect this would be needed in the scheduled scan extension as well, right?
It will be always up to user-space caller to make system more or less
power-efficient, right?
> Regards,
> Arend
^ permalink raw reply
* RE: ATH9 driver issues on ARM64
From: Bharat Kumar Gogada @ 2016-12-09 5:00 UTC (permalink / raw)
To: Kalle Valo
Cc: Bjorn Helgaas, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, Marc Zyngier,
Janusz.Dziedzic@tieto.com, ath9k-devel@qca.qualcomm.com,
linux-wireless@vger.kernel.org, rmanohar@qca.qualcomm.com
In-Reply-To: <874m2emif9.fsf@purkki.adurom.net>
Hi,
Can any one tell, when exactly the chip sends ASSERT & DEASSERT in driver.
It might help us to debug issue further.
Thanks & Regards,
Bharat=20
> > > [+cc Kalle, ath9k list]
>=20
> Thanks, but please also CC linux-wireless. Full thread below for the folk=
s there.
>=20
> >> On Thu, Dec 08, 2016 at 01:49:42PM +0000, Bharat Kumar Gogada wrote:
> >> > Hi,
> >> >
> >> > Did anyone test Atheros ATH9
> >> > driver(drivers/net/wireless/ath/ath9k/)
> >> > on ARM64. The end point is TP link wifi card with which supports
> >> > only legacy interrupts.
> >>
> >> If it works on other arches and the arm64 PCI enumeration works, my
> >> first guess would be an INTx issue, e.g., maybe the driver is waiting
> >> for an interrupt that never arrives.
> > We are not sure for now.
> >>
> >> > We are trying to test it on ARM64 with
> >> > (drivers/pci/host/pcie-xilinx-nwl.c) as root port.
> >> >
> >> > EP is getting enumerated and able to link up.
> >> >
> >> > But when we start scan system gets hanged.
> >>
> >> When you say the system hangs when you start a scan, I assume you
> >> mean a wifi scan, not the PCI enumeration. A problem with a wifi
> >> scan might cause a *process* to hang, but it shouldn't hang the
> >> entire system.
> >>
> > Yes wifi scan.
> >> > When we took trace we see that after we start scan assert message
> >> > is sent but there is no de assert from end point.
> >>
> >> Are you talking about a trace from a PCIe analyzer? Do you see an
> >> Assert_INTx PCIe message on the link?
> >>
> > Yes lecroy trace, yes we do see Assert_INTx and Deassert_INTx happening
> when we do interface link up.
> > When we have less debug prints in Atheros driver, and do wifi scan we
> > see Assert_INTx but never Deassert_INTx,
> >> > What might cause end point not sending de assert ?
> >>
> >> If the endpoint doesn't send a Deassert_INTx message, I expect that
> >> would mean the driver didn't service the interrupt and remove the
> >> condition that caused the device to assert the interrupt in the first
> >> place.
> >>
> >> If the driver didn't receive the interrupt, it couldn't service it,
> >> of course. You could add a printk in the ath9k interrupt service
> >> routine to see if you ever get there.
> >>
> > The interrupt behavior is changing w.r.t amount of debug prints we
> > add. (I kept many prints to aid debug) root@Xilinx-ZCU102-2016_3:~# iw =
dev
> wlan0 scan
> > [ 83.064675] ath9k: ath9k_iowrite32 ffffff800a400024
> > [ 83.069486] ath9k: ath9k_ioread32 ffffff800a400024
> > [ 83.074257] ath9k_hw_kill_interrupts 793
> > [ 83.078260] ath9k: ath9k_iowrite32 ffffff800a400024
> > [ 83.083107] ath9k: ath9k_ioread32 ffffff800a400024
> > [ 83.087882] ath9k_hw_kill_interrupts 793
> > [ 83.095450] ath9k_hw_enable_interrupts 821
> > [ 83.099557] ath9k_hw_enable_interrupts 825
> > [ 83.103721] ath9k_hw_enable_interrupts 832
> > [ 83.107887] ath9k: ath9k_iowrite32 ffffff800a400024
> > [ 83.112748] AR_SREV_9100 0
> > [ 83.115438] ath9k_hw_enable_interrupts 848
> > [ 83.119607] ath9k: ath9k_ioread32 ffffff800a400024
> > [ 83.124389] ath9k_hw_intrpend 762
> > [ 83.127761] (AR_SREV_9340(ah) val 0
> > [ 83.131234] ath9k_hw_intrpend 767
> > [ 83.134628] ath_isr 603
> > [ 83.137134] ath9k: ath9k_iowrite32 ffffff800a400024
> > [ 83.141995] ath9k: ath9k_ioread32 ffffff800a400024
> > [ 83.146771] ath9k_hw_kill_interrupts 793
> > [ 83.150864] ath9k_hw_enable_interrupts 821
> > [ 83.154971] ath9k_hw_enable_interrupts 825
> > [ 83.159135] ath9k_hw_enable_interrupts 832
> > [ 83.163300] ath9k: ath9k_iowrite32 ffffff800a400024
> > [ 83.168161] AR_SREV_9100 0
> > [ 83.170852] ath9k_hw_enable_interrupts 848
> > [ 83.170855] ath9k_hw_intrpend 762
> > [ 83.178398] (AR_SREV_9340(ah) val 0
> > [ 83.181873] ath9k_hw_intrpend 767
> > [ 83.185265] ath_isr 603
> > [ 83.187773] ath9k: ath9k_iowrite32 ffffff800a400024
> > [ 83.192635] ath9k: ath9k_ioread32 ffffff800a400024
> > [ 83.197411] ath9k_hw_kill_interrupts 793
> > [ 83.201414] ath9k: ath9k_ioread32 ffffff800a400024
> > [ 83.206258] ath9k_hw_enable_interrupts 821
> > [ 83.210368] ath9k_hw_enable_interrupts 825
> > [ 83.214531] ath9k_hw_enable_interrupts 832
> > [ 83.218698] ath9k: ath9k_iowrite32 ffffff800a400024
> > [ 83.223558] AR_SREV_9100 0
> > [ 83.226243] ath9k_hw_enable_interrupts 848
> > [ 83.226246] ath9k_hw_intrpend 762
> > [ 83.233794] (AR_SREV_9340(ah) val 0
> > [ 83.237268] ath9k_hw_intrpend 767
> > [ 83.240661] ath_isr 603
> > [ 83.243169] ath9k: ath9k_iowrite32 ffffff800a400024
> > [ 83.248030] ath9k: ath9k_ioread32 ffffff800a400024
> > [ 83.252806] ath9k_hw_kill_interrupts 793
> > [ 83.256811] ath9k: ath9k_ioread32 ffffff800a400024
> > [ 83.261651] ath9k_hw_enable_interrupts 821
> > [ 83.265753] ath9k_hw_enable_interrupts 825
> > [ 83.269919] ath9k_hw_enable_interrupts 832
> > [ 83.274083] ath9k: ath9k_iowrite32 ffffff800a400024
> > [ 83.278945] AR_SREV_9100 0
> > [ 83.281630] ath9k_hw_enable_interrupts 848
> > [ 83.281633] ath9k_hw_intrpend 762
> > [ 83.281634] (AR_SREV_9340(ah) val 0
> > [ 83.281637] ath9k_hw_intrpend 767
> > [ 83.281648] ath_isr 603
> > [ 83.281649] ath9k: ath9k_iowrite32 ffffff800a400024
> > [ 83.281651] ath9k: ath9k_ioread32 ffffff800a400024
> > [ 83.281654] ath9k_hw_kill_interrupts 793
> > [ 83.312192] ath9k: ath9k_ioread32 ffffff800a400024
> > [ 83.317030] ath9k_hw_enable_interrupts 821
> > [ 83.321132] ath9k_hw_enable_interrupts 825
> > [ 83.325297] ath9k_hw_enable_interrupts 832
> > [ 83.329463] ath9k: ath9k_iowrite32 ffffff800a400024
> > [ 83.334324] AR_SREV_9100 0
> > [ 83.337014] ath9k_hw_enable_interrupts 848
> > ..
> > ..
> > This log continues until I turn off board without obtaining scanning re=
sult.
> >
> > In between I get following cpu stall outputs :
> > 230.457179] INFO: rcu_sched self-detected stall on CPU
> > [ 230.457185] 2-...: (31314 ticks this GP)
> idle=3D2d1/140000000000001/0 softirq=3D1400/1400 fqs=3D36713
> > [ 230.457189] (t=3D36756 jiffies g=3D161 c=3D160 q=3D16169)
> > [ 230.457191] Task dump for CPU 2:
> > [ 230.457196] kworker/u8:4 R running task 0 1342 2 0x=
00000002
> > [ 230.457207] Workqueue: phy0 ieee80211_scan_work [ 230.457208] Call
> > trace:
> > [ 230.457214] [<ffffff8008089860>] dump_backtrace+0x0/0x198 [
> > 230.457219] [<ffffff8008089a0c>] show_stack+0x14/0x20 [ 230.457224]
> > [<ffffff80080c0930>] sched_show_task+0x98/0xf8 [ 230.457228]
> > [<ffffff80080c2628>] dump_cpu_task+0x40/0x50 [ 230.457233]
> > [<ffffff80080e14a8>] rcu_dump_cpu_stacks+0xa0/0xf0 [ 230.457239]
> > [<ffffff80080e4cd8>] rcu_check_callbacks+0x468/0x748 [ 230.457243]
> > [<ffffff80080e7cfc>] update_process_times+0x3c/0x68 [ 230.457249]
> > [<ffffff80080f6dfc>] tick_sched_handle.isra.5+0x3c/0x50
> > [ 230.457253] [<ffffff80080f6e54>] tick_sched_timer+0x44/0x90 [
> > 230.457257] [<ffffff80080e86b0>] __hrtimer_run_queues+0xf0/0x178
> > ** 10 printk messages dropped ** [ 230.457302] f8c0: 0000000000000000
> > 0000000005f5e0ff 000000000001379a 3866666666666620 [ 230.457306]
> > f8e0: ffffff800a1b4065 0000000000000006 ffffff800a129000
> > ffffffc87b8010a8 [ 230.457310] f900: ffffff808a1b4057
> > ffffff800a1c3000 ffffff800a1b3000 ffffff800a13b000 [ 230.457314]
> > f920: 0000000000000140 0000000000000006 ffffff800a1b3b10
> > ffffff800a1c39e8 [ 230.457318] f940: 000000000000002f
> > ffffff800a1b8a98 ffffff800a1b3ae8 ffffffc87b07f990 [ 230.457322]
> > f960: ffffff80080d6230 ffffffc87b07f990 ffffff80080d6234
> > 0000000060000145
> > ** 1 printk messages dropped ** [ 230.457329] [<ffffff8008085720>]
> > el1_irq+0xa0/0x100
> > ** 9 printk messages dropped ** [ 230.457373] [<ffffff800885ad60>]
> > ieee80211_hw_config+0x50/0x290 [ 230.457377] [<ffffff8008863690>]
> > ieee80211_scan_work+0x1f8/0x480 [ 230.457383] [<ffffff80080b15d0>]
> > process_one_work+0x120/0x378 [ 230.457386] [<ffffff80080b1870>]
> > worker_thread+0x48/0x4b0 [ 230.457391] [<ffffff80080b7108>]
> > kthread+0xd0/0xe8 [ 230.457395] [<ffffff8008085dd0>]
> ret_from_fork+0x10/0x40
> > [ 230.480389] ath9k_hw_intrpend 762
> >
> >
> > [ 545.487987] ath9k: ath9k_ioread32 ffffff800a400024 [ 545.526189]
> > INFO: rcu_sched self-detected stall on CPU
> > [ 545.526195] 2-...: (97636 ticks this GP)
> idle=3D2d1/140000000000001/0 softirq=3D1400/1400 fqs=3D115374
> > [ 545.526199] (t=3D115523 jiffies g=3D161 c=3D160 q=3D51066)
> > [ 545.526201] Task dump for CPU 2:
> > [ 545.526206] kworker/u8:4 R running task 0 1342 2 0x=
00000002
> > ** 3 printk messages dropped ** [ 545.526231] [<ffffff8008089a0c>]
> > show_stack+0x14/0x20
> > ** 9 printk messages dropped ** [ 545.526280] [<ffffff80086a71e8>]
> > arch_timer_handler_phys+0x30/0x40 [ 545.526284] [<ffffff80080dbe18>]
> > handle_percpu_devid_irq+0x78/0xa0 [ 545.526291] [<ffffff80080d760c>]
> > generic_handle_irq+0x24/0x38 [ 545.526296] [<ffffff80080d7944>]
> > __handle_domain_irq+0x5c/0xb8 [ 545.526299] [<ffffff80080824bc>]
> > gic_handle_irq+0x64/0xc0 [ 545.526302] Exception stack(0xffffffc87b07f=
870
> to 0xffffffc87b07f990)
> > [ 545.526306] f860: 0000000000009732=
ffffff800a1eaaa8
> > ** 8 printk messages dropped ** [ 545.526341] f980: ffffff800a1c39e8
> > 0000000000000036 [ 545.526345] [<ffffff8008085720>]
> > el1_irq+0xa0/0x100 [ 545.526349] [<ffffff80080d6234>]
> > console_unlock+0x384/0x5b0 [ 545.526353] [<ffffff80080d673c>]
> > vprintk_emit+0x2dc/0x4b0 [ 545.526357] [<ffffff80080d6a50>]
> > vprintk_default+0x38/0x40 [ 545.526362] [<ffffff8008129704>]
> > printk+0x58/0x60 [ 545.526366] [<ffffff800859e3e4>]
> > ath9k_iowrite32+0x9c/0xa8 [ 545.526372] [<ffffff80085c7ca8>]
> > ath9k_hw_kill_interrupts+0x28/0xf0
> > [ 545.526376] [<ffffff80085a18ec>] ath_reset+0x24/0x68
> > ** 2 printk messages dropped ** [ 545.526391] [<ffffff800885ad60>]
> ieee80211_hw_config+0x50/0x290
> > ** 11 printk messages dropped ** [ 545.532834] ath9k_hw_kill_interrupt=
s
> 793
> > [ 545.532890] ath9k_hw_enable_interrupts 821
> >
> >
> > But if we have less debug prints it does not reach EP handler
> > sometimes, due to following Condition in "kernel/irq/chip.c" in
> > function handle_simple_irq
> >
> > if (unlikely(!desc->action || irqd_irq_disabled(&desc->irq_data))) {
> > desc->istate |=3D IRQS_PENDING;
> > goto out_unlock;
> > }
> > Here irqd_irq_disabled is being set to 1.
> >
> > With lesser debug prints it stops after following prints:
> > root@Xilinx-ZCU102-2016_3:~# iw dev wlan0 scan
> > [ 54.781045] ath9k_hw_kill_interrupts 793
> > [ 54.785007] ath9k_hw_kill_interrupts 793
> > [ 54.792535] ath9k_hw_enable_interrupts 821
> > [ 54.796642] ath9k_hw_enable_interrupts 825
> > [ 54.800807] ath9k_hw_enable_interrupts 832
> > [ 54.804973] AR_SREV_9100 0
> > [ 54.807663] ath9k_hw_enable_interrupts 848
> > [ 54.811843] ath9k_hw_intrpend 762
> > [ 54.815211] (AR_SREV_9340(ah) val 0
> > [ 54.818684] ath9k_hw_intrpend 767
> > [ 54.822078] ath_isr 603
> > [ 54.824587] ath9k_hw_kill_interrupts 793
> > [ 54.828601] ath9k_hw_enable_interrupts 821
> > [ 54.832750] ath9k_hw_enable_interrupts 825
> > [ 54.836916] ath9k_hw_enable_interrupts 832
> > [ 54.841082] AR_SREV_9100 0
> > [ 54.843772] ath9k_hw_enable_interrupts 848
> > [ 54.843775] ath9k_hw_intrpend 762
> > [ 54.851319] (AR_SREV_9340(ah) val 0
> > [ 54.854793] ath9k_hw_intrpend 767
> > [ 54.858185] ath_isr 603
> > [ 54.860696] ath9k_hw_kill_interrupts 793
> > [ 54.864776] ath9k_hw_enable_interrupts 821
> > [ 54.867061] ath9k_hw_kill_interrupts 793
> > [ 54.872870] ath9k_hw_enable_interrupts 825
> > [ 54.877036] ath9k_hw_enable_interrupts 832
> > [ 54.881202] AR_SREV_9100 0
> > [ 54.883892] ath9k_hw_enable_interrupts 848
> > [ 75.963129] INFO: rcu_sched detected stalls on CPUs/tasks:
> > [ 75.968602] 0-...: (2 GPs behind) idle=3D9d5/140000000000001/0
> softirq=3D1103/1109 fqs=3D519
> > [ 75.976675] (detected by 2, t=3D5274 jiffies, g=3D64, c=3D63, q=3D1=
1)
> > [ 75.982485] Task dump for CPU 0:
> > [ 75.985696] ksoftirqd/0 R running task 0 3 2 0x=
00000002
> > [ 75.992726] Call trace:
> > [ 75.995165] [<ffffff8008086b3c>] __switch_to+0xc4/0xd0
> > [ 76.000281] [<ffffffc87b830500>] 0xffffffc87b830500
> > [ 139.059027] INFO: rcu_sched detected stalls on CPUs/tasks:
> > [ 139.064430] 0-...: (2 GPs behind) idle=3D9d5/140000000000001/0
> softirq=3D1103/1109 fqs=3D2097
> > [ 139.072593] (detected by 2, t=3D21049 jiffies, g=3D64, c=3D63, q=3D=
11)
> > [ 139.078489] Task dump for CPU 0:
> > [ 139.081700] ksoftirqd/0 R running task 0 3 2 0x=
00000002
> > [ 139.088731] Call trace:
> > [ 139.091165] [<ffffff8008086b3c>] __switch_to+0xc4/0xd0 [
> > 139.096285] [<ffffffc87b830500>] 0xffffffc87b830500
> >
> >
> >> > We are not seeing any issues on 32-bit ARM platform and X86
> >> > platform.
> >>
> >> Can you collect a dmesg log (or, if the system hang means you can't
> >> collect that, a console log with "ignore_loglevel"), and "lspci -vv"
> >> output as root? That should have clues about whether the INTx got
> >> routed correctly. /proc/interrupts should also show whether we're
> >> receiving interrupts from the device.
> >
> > Here is the lspci output:
> > 00:00.0 PCI bridge: Xilinx Corporation Device d022 (prog-if 00 [Normal
> decode])
> > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx-
> > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> > Latency: 0
> > Interrupt: pin A routed to IRQ 224
> > Bus: primary=3D00, secondary=3D01, subordinate=3D0c, sec-latency=3D0
> > I/O behind bridge: 00000000-00000fff
> > Memory behind bridge: e0000000-e00fffff
> > Prefetchable memory behind bridge: 00000000fff00000-
> 00000000000fffff
> > Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=3Dfast >TAbort-
> <TAbort- <MAbort- <SERR- <PERR-
> > BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
> > PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
> > Capabilities: [40] Power Management version 3
> > Flags: PMEClk- DSI- D1- D2- AuxCurrent=3D0mA
> PME(D0+,D1+,D2+,D3hot+,D3cold-)
> > Status: D0 NoSoftRst+ PME-Enable- DSel=3D0 DScale=3D0 PME-
> > Capabilities: [60] Express (v2) Root Port (Slot-), MSI 00
> > DevCap: MaxPayload 256 bytes, PhantFunc 0
> > ExtTag- RBE+
> > DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> Unsupported-
> > RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
> > MaxPayload 128 bytes, MaxReadReq 512 bytes
> > DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr-
> TransPend+
> > LnkCap: Port #0, Speed 5GT/s, Width x2, ASPM not supported,
> Exit Latency L0s unlimited, L1 unlimited
> > ClockPM- Surprise- LLActRep- BwNot+ ASPMOptComp+
> > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
> > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> > LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
> DLActive- BWMgmt- ABWMgmt-
> > RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna-
> CRSVisible+
> > RootCap: CRSVisible+
> > RootSta: PME ReqID 0000, PMEStatus- PMEPending-
> > DevCap2: Completion Timeout: Range B, TimeoutDis+, LTR-,
> OBFF Not Supported ARIFwd-
> > DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-,
> OBFF Disabled ARIFwd-
> > LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
> > Transmit Margin: Normal Operating Range,
> EnterModifiedCompliance- ComplianceSOS-
> > Compliance De-emphasis: -6dB
> > LnkSta2: Current De-emphasis Level: -3.5dB,
> EqualizationComplete-, EqualizationPhase1-
> > EqualizationPhase2-, EqualizationPhase3-,
> LinkEqualizationRequest-
> > Capabilities: [100 v1] Device Serial Number 00-00-00-00-00-00-00-00
> > Capabilities: [10c v1] Virtual Channel
> > Caps: LPEVC=3D0 RefClk=3D100ns PATEntryBits=3D1
> > Arb: Fixed- WRR32- WRR64- WRR128-
> > Ctrl: ArbSelect=3DFixed
> > Status: InProgress-
> > VC0: Caps: PATOffset=3D00 MaxTimeSlots=3D1 RejSnoopTrans-
> > Arb: Fixed- WRR32- WRR64- WRR128- TWRR128-
> WRR256-
> > Ctrl: Enable+ ID=3D0 ArbSelect=3DFixed TC/VC=3Dff
> > Status: NegoPending- InProgress-
> > Capabilities: [128 v1] Vendor Specific Information: ID=3D1234 Rev=3D1
> > Len=3D018 <?>
> >
> > 01:00.0 Network controller: Qualcomm Atheros AR93xx Wireless Network
> Adapter (rev 01)
> > Subsystem: Qualcomm Atheros Device 3112
> > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx-
> > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> > Latency: 0, Cache Line Size: 128 bytes
> > Interrupt: pin A routed to IRQ 224
> > Region 0: Memory at e0000000 (64-bit, non-prefetchable) [size=3D128K]
> > [virtual] Expansion ROM at e0020000 [disabled] [size=3D64K]
> > Capabilities: [40] Power Management version 3
> > Flags: PMEClk- DSI- D1+ D2- AuxCurrent=3D375mA
> PME(D0+,D1+,D2-,D3hot+,D3cold-)
> > Status: D0 NoSoftRst- PME-Enable- DSel=3D0 DScale=3D0 PME-
> > Capabilities: [50] MSI: Enable- Count=3D1/4 Maskable+ 64bit+
> > Address: 0000000000000000 Data: 0000
> > Masking: 00000000 Pending: 00000000
> > Capabilities: [70] Express (v2) Endpoint, MSI 00
> > DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency
> L0s <1us, L1 <8us
> > ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
> SlotPowerLimit 0.000W
> > DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> Unsupported-
> > RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
> > MaxPayload 128 bytes, MaxReadReq 512 bytes
> > DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr-
> TransPend-
> > LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit
> Latency L0s <2us, L1 <64us
> > ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
> > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
> > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> > LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
> DLActive- BWMgmt- ABWMgmt-
> > DevCap2: Completion Timeout: Not Supported, TimeoutDis+,
> LTR-, OBFF Not Supported
> > DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-,
> OBFF Disabled
> > LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance-
> SpeedDis-
> > Transmit Margin: Normal Operating Range,
> EnterModifiedCompliance- ComplianceSOS-
> > Compliance De-emphasis: -6dB
> > LnkSta2: Current De-emphasis Level: -6dB,
> EqualizationComplete-, EqualizationPhase1-
> > EqualizationPhase2-, EqualizationPhase3-,
> LinkEqualizationRequest-
> > Capabilities: [100 v1] Advanced Error Reporting
> > UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> > UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> > UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt-
> RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
> > CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
> NonFatalErr-
> > CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
> NonFatalErr+
> > AERCap: First Error Pointer: 00, GenCap- CGenEn-
> ChkCap- ChkEn-
> > Capabilities: [140 v1] Virtual Channel
> > Caps: LPEVC=3D0 RefClk=3D100ns PATEntryBits=3D1
> > Arb: Fixed- WRR32- WRR64- WRR128-
> > Ctrl: ArbSelect=3DFixed
> > Status: InProgress-
> > VC0: Caps: PATOffset=3D00 MaxTimeSlots=3D1 RejSnoopTrans-
> > Arb: Fixed- WRR32- WRR64- WRR128- TWRR128-
> WRR256-
> > Ctrl: Enable+ ID=3D0 ArbSelect=3DFixed TC/VC=3Dff
> > Status: NegoPending- InProgress-
> > Capabilities: [300 v1] Device Serial Number 00-00-00-00-00-00-00-00
> > Kernel driver in use: ath9k
> >
> > Here is the cat /proc/interrupts (after we do interface up):
> >
> > root@:~# ifconfig wlan0 up
> > [ 1548.926601] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> > root@Xilinx-ZCU102-2016_3:~# cat /proc/interrupts
> > CPU0 CPU1 CPU2 CPU3
> > 1: 0 0 0 0 GICv2 29 Edge =
arch_timer
> > 2: 19873 20058 19089 17435 GICv2 30 Edge =
arch_timer
> > 12: 0 0 0 0 GICv2 156 Level =
zynqmp-dma
> > 13: 0 0 0 0 GICv2 157 Level =
zynqmp-dma
> > 14: 0 0 0 0 GICv2 158 Level =
zynqmp-dma
> > 15: 0 0 0 0 GICv2 159 Level =
zynqmp-dma
> > 16: 0 0 0 0 GICv2 160 Level =
zynqmp-dma
> > 17: 0 0 0 0 GICv2 161 Level =
zynqmp-dma
> > 18: 0 0 0 0 GICv2 162 Level =
zynqmp-dma
> > 19: 0 0 0 0 GICv2 163 Level =
zynqmp-dma
> > 20: 0 0 0 0 GICv2 164 Level =
Mali_GP_MMU, Mali_GP,
> Mali_PP0_MMU, Mali_PP0, Mali_PP1_MMU, Mali_PP1
> > 30: 0 0 0 0 GICv2 95 Level =
eth0, eth0
> > 206: 314 0 0 0 GICv2 49 Level =
cdns-i2c
> > 207: 40 0 0 0 GICv2 50 Level =
cdns-i2c
> > 209: 0 0 0 0 GICv2 150 Level =
nwl_pcie:misc
> > 214: 12 0 0 0 GICv2 47 Level =
ff0f0000.spi
> > 215: 0 0 0 0 GICv2 58 Level =
ffa60000.rtc
> > 216: 0 0 0 0 GICv2 59 Level =
ffa60000.rtc
> > 217: 0 0 0 0 GICv2 165 Level =
ahci-ceva[fd0c0000.ahci]
> > 218: 61 0 0 0 GICv2 81 Level =
mmc0
> > 219: 0 0 0 0 GICv2 187 Level =
arm-smmu global fault
> > 220: 471 0 0 0 GICv2 53 Level =
xuartps
> > 223: 0 0 0 0 GICv2 154 Level =
fd4c0000.dma
> > 224: 3 0 0 0 dummy 1 Edge =
ath9k
> > 225: 0 0 0 0 GICv2 97 Level =
xhci-hcd:usb1
> >
> > Regards,
> > Bharat
>=20
> --
> Kalle Valo
^ permalink raw reply
* RE: ATH9 driver issues on ARM64
From: Bharat Kumar Gogada @ 2016-12-09 6:55 UTC (permalink / raw)
To: Bharat Kumar Gogada, Kalle Valo
Cc: Bjorn Helgaas, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, Marc Zyngier,
Janusz.Dziedzic@tieto.com, ath9k-devel@qca.qualcomm.com,
linux-wireless@vger.kernel.org, rmanohar@qca.qualcomm.com
In-Reply-To: <8520D5D51A55D047800579B094147198263A7A64@XAP-PVEXMBX02.xlnx.xilinx.com>
Sorry, Forgot to add kernel version, we are using 4.6 kernel.=20
> Hi,
> Can any one tell, when exactly the chip sends ASSERT & DEASSERT in driver=
.
> It might help us to debug issue further.
>=20
> Thanks & Regards,
> Bharat
>=20
> > > > [+cc Kalle, ath9k list]
> >
> > Thanks, but please also CC linux-wireless. Full thread below for the fo=
lks there.
> >
> > >> On Thu, Dec 08, 2016 at 01:49:42PM +0000, Bharat Kumar Gogada wrote:
> > >> > Hi,
> > >> >
> > >> > Did anyone test Atheros ATH9
> > >> > driver(drivers/net/wireless/ath/ath9k/)
> > >> > on ARM64. The end point is TP link wifi card with which supports
> > >> > only legacy interrupts.
> > >>
> > >> If it works on other arches and the arm64 PCI enumeration works, my
> > >> first guess would be an INTx issue, e.g., maybe the driver is
> > >> waiting for an interrupt that never arrives.
> > > We are not sure for now.
> > >>
> > >> > We are trying to test it on ARM64 with
> > >> > (drivers/pci/host/pcie-xilinx-nwl.c) as root port.
> > >> >
> > >> > EP is getting enumerated and able to link up.
> > >> >
> > >> > But when we start scan system gets hanged.
> > >>
> > >> When you say the system hangs when you start a scan, I assume you
> > >> mean a wifi scan, not the PCI enumeration. A problem with a wifi
> > >> scan might cause a *process* to hang, but it shouldn't hang the
> > >> entire system.
> > >>
> > > Yes wifi scan.
> > >> > When we took trace we see that after we start scan assert message
> > >> > is sent but there is no de assert from end point.
> > >>
> > >> Are you talking about a trace from a PCIe analyzer? Do you see an
> > >> Assert_INTx PCIe message on the link?
> > >>
> > > Yes lecroy trace, yes we do see Assert_INTx and Deassert_INTx
> > > happening
> > when we do interface link up.
> > > When we have less debug prints in Atheros driver, and do wifi scan
> > > we see Assert_INTx but never Deassert_INTx,
> > >> > What might cause end point not sending de assert ?
> > >>
> > >> If the endpoint doesn't send a Deassert_INTx message, I expect that
> > >> would mean the driver didn't service the interrupt and remove the
> > >> condition that caused the device to assert the interrupt in the
> > >> first place.
> > >>
> > >> If the driver didn't receive the interrupt, it couldn't service it,
> > >> of course. You could add a printk in the ath9k interrupt service
> > >> routine to see if you ever get there.
> > >>
> > > The interrupt behavior is changing w.r.t amount of debug prints we
> > > add. (I kept many prints to aid debug) root@Xilinx-ZCU102-2016_3:~#
> > > iw dev
> > wlan0 scan
> > > [ 83.064675] ath9k: ath9k_iowrite32 ffffff800a400024
> > > [ 83.069486] ath9k: ath9k_ioread32 ffffff800a400024
> > > [ 83.074257] ath9k_hw_kill_interrupts 793
> > > [ 83.078260] ath9k: ath9k_iowrite32 ffffff800a400024
> > > [ 83.083107] ath9k: ath9k_ioread32 ffffff800a400024
> > > [ 83.087882] ath9k_hw_kill_interrupts 793
> > > [ 83.095450] ath9k_hw_enable_interrupts 821
> > > [ 83.099557] ath9k_hw_enable_interrupts 825
> > > [ 83.103721] ath9k_hw_enable_interrupts 832
> > > [ 83.107887] ath9k: ath9k_iowrite32 ffffff800a400024
> > > [ 83.112748] AR_SREV_9100 0
> > > [ 83.115438] ath9k_hw_enable_interrupts 848
> > > [ 83.119607] ath9k: ath9k_ioread32 ffffff800a400024
> > > [ 83.124389] ath9k_hw_intrpend 762
> > > [ 83.127761] (AR_SREV_9340(ah) val 0
> > > [ 83.131234] ath9k_hw_intrpend 767
> > > [ 83.134628] ath_isr 603
> > > [ 83.137134] ath9k: ath9k_iowrite32 ffffff800a400024
> > > [ 83.141995] ath9k: ath9k_ioread32 ffffff800a400024
> > > [ 83.146771] ath9k_hw_kill_interrupts 793
> > > [ 83.150864] ath9k_hw_enable_interrupts 821
> > > [ 83.154971] ath9k_hw_enable_interrupts 825
> > > [ 83.159135] ath9k_hw_enable_interrupts 832
> > > [ 83.163300] ath9k: ath9k_iowrite32 ffffff800a400024
> > > [ 83.168161] AR_SREV_9100 0
> > > [ 83.170852] ath9k_hw_enable_interrupts 848
> > > [ 83.170855] ath9k_hw_intrpend 762
> > > [ 83.178398] (AR_SREV_9340(ah) val 0
> > > [ 83.181873] ath9k_hw_intrpend 767
> > > [ 83.185265] ath_isr 603
> > > [ 83.187773] ath9k: ath9k_iowrite32 ffffff800a400024
> > > [ 83.192635] ath9k: ath9k_ioread32 ffffff800a400024
> > > [ 83.197411] ath9k_hw_kill_interrupts 793
> > > [ 83.201414] ath9k: ath9k_ioread32 ffffff800a400024
> > > [ 83.206258] ath9k_hw_enable_interrupts 821
> > > [ 83.210368] ath9k_hw_enable_interrupts 825
> > > [ 83.214531] ath9k_hw_enable_interrupts 832
> > > [ 83.218698] ath9k: ath9k_iowrite32 ffffff800a400024
> > > [ 83.223558] AR_SREV_9100 0
> > > [ 83.226243] ath9k_hw_enable_interrupts 848
> > > [ 83.226246] ath9k_hw_intrpend 762
> > > [ 83.233794] (AR_SREV_9340(ah) val 0
> > > [ 83.237268] ath9k_hw_intrpend 767
> > > [ 83.240661] ath_isr 603
> > > [ 83.243169] ath9k: ath9k_iowrite32 ffffff800a400024
> > > [ 83.248030] ath9k: ath9k_ioread32 ffffff800a400024
> > > [ 83.252806] ath9k_hw_kill_interrupts 793
> > > [ 83.256811] ath9k: ath9k_ioread32 ffffff800a400024
> > > [ 83.261651] ath9k_hw_enable_interrupts 821
> > > [ 83.265753] ath9k_hw_enable_interrupts 825
> > > [ 83.269919] ath9k_hw_enable_interrupts 832
> > > [ 83.274083] ath9k: ath9k_iowrite32 ffffff800a400024
> > > [ 83.278945] AR_SREV_9100 0
> > > [ 83.281630] ath9k_hw_enable_interrupts 848
> > > [ 83.281633] ath9k_hw_intrpend 762
> > > [ 83.281634] (AR_SREV_9340(ah) val 0
> > > [ 83.281637] ath9k_hw_intrpend 767
> > > [ 83.281648] ath_isr 603
> > > [ 83.281649] ath9k: ath9k_iowrite32 ffffff800a400024
> > > [ 83.281651] ath9k: ath9k_ioread32 ffffff800a400024
> > > [ 83.281654] ath9k_hw_kill_interrupts 793
> > > [ 83.312192] ath9k: ath9k_ioread32 ffffff800a400024
> > > [ 83.317030] ath9k_hw_enable_interrupts 821
> > > [ 83.321132] ath9k_hw_enable_interrupts 825
> > > [ 83.325297] ath9k_hw_enable_interrupts 832
> > > [ 83.329463] ath9k: ath9k_iowrite32 ffffff800a400024
> > > [ 83.334324] AR_SREV_9100 0
> > > [ 83.337014] ath9k_hw_enable_interrupts 848
> > > ..
> > > ..
> > > This log continues until I turn off board without obtaining scanning =
result.
> > >
> > > In between I get following cpu stall outputs :
> > > 230.457179] INFO: rcu_sched self-detected stall on CPU
> > > [ 230.457185] 2-...: (31314 ticks this GP)
> > idle=3D2d1/140000000000001/0 softirq=3D1400/1400 fqs=3D36713
> > > [ 230.457189] (t=3D36756 jiffies g=3D161 c=3D160 q=3D16169)
> > > [ 230.457191] Task dump for CPU 2:
> > > [ 230.457196] kworker/u8:4 R running task 0 1342 2 =
0x00000002
> > > [ 230.457207] Workqueue: phy0 ieee80211_scan_work [ 230.457208]
> > > Call
> > > trace:
> > > [ 230.457214] [<ffffff8008089860>] dump_backtrace+0x0/0x198 [
> > > 230.457219] [<ffffff8008089a0c>] show_stack+0x14/0x20 [ 230.457224]
> > > [<ffffff80080c0930>] sched_show_task+0x98/0xf8 [ 230.457228]
> > > [<ffffff80080c2628>] dump_cpu_task+0x40/0x50 [ 230.457233]
> > > [<ffffff80080e14a8>] rcu_dump_cpu_stacks+0xa0/0xf0 [ 230.457239]
> > > [<ffffff80080e4cd8>] rcu_check_callbacks+0x468/0x748 [ 230.457243]
> > > [<ffffff80080e7cfc>] update_process_times+0x3c/0x68 [ 230.457249]
> > > [<ffffff80080f6dfc>] tick_sched_handle.isra.5+0x3c/0x50
> > > [ 230.457253] [<ffffff80080f6e54>] tick_sched_timer+0x44/0x90 [
> > > 230.457257] [<ffffff80080e86b0>] __hrtimer_run_queues+0xf0/0x178
> > > ** 10 printk messages dropped ** [ 230.457302] f8c0:
> > > 0000000000000000 0000000005f5e0ff 000000000001379a
> 3866666666666620
> > > [ 230.457306]
> > > f8e0: ffffff800a1b4065 0000000000000006 ffffff800a129000
> > > ffffffc87b8010a8 [ 230.457310] f900: ffffff808a1b4057
> > > ffffff800a1c3000 ffffff800a1b3000 ffffff800a13b000 [ 230.457314]
> > > f920: 0000000000000140 0000000000000006 ffffff800a1b3b10
> > > ffffff800a1c39e8 [ 230.457318] f940: 000000000000002f
> > > ffffff800a1b8a98 ffffff800a1b3ae8 ffffffc87b07f990 [ 230.457322]
> > > f960: ffffff80080d6230 ffffffc87b07f990 ffffff80080d6234
> > > 0000000060000145
> > > ** 1 printk messages dropped ** [ 230.457329] [<ffffff8008085720>]
> > > el1_irq+0xa0/0x100
> > > ** 9 printk messages dropped ** [ 230.457373] [<ffffff800885ad60>]
> > > ieee80211_hw_config+0x50/0x290 [ 230.457377] [<ffffff8008863690>]
> > > ieee80211_scan_work+0x1f8/0x480 [ 230.457383] [<ffffff80080b15d0>]
> > > process_one_work+0x120/0x378 [ 230.457386] [<ffffff80080b1870>]
> > > worker_thread+0x48/0x4b0 [ 230.457391] [<ffffff80080b7108>]
> > > kthread+0xd0/0xe8 [ 230.457395] [<ffffff8008085dd0>]
> > ret_from_fork+0x10/0x40
> > > [ 230.480389] ath9k_hw_intrpend 762
> > >
> > >
> > > [ 545.487987] ath9k: ath9k_ioread32 ffffff800a400024 [ 545.526189]
> > > INFO: rcu_sched self-detected stall on CPU
> > > [ 545.526195] 2-...: (97636 ticks this GP)
> > idle=3D2d1/140000000000001/0 softirq=3D1400/1400 fqs=3D115374
> > > [ 545.526199] (t=3D115523 jiffies g=3D161 c=3D160 q=3D51066)
> > > [ 545.526201] Task dump for CPU 2:
> > > [ 545.526206] kworker/u8:4 R running task 0 1342 2 =
0x00000002
> > > ** 3 printk messages dropped ** [ 545.526231] [<ffffff8008089a0c>]
> > > show_stack+0x14/0x20
> > > ** 9 printk messages dropped ** [ 545.526280] [<ffffff80086a71e8>]
> > > arch_timer_handler_phys+0x30/0x40 [ 545.526284]
> > > [<ffffff80080dbe18>]
> > > handle_percpu_devid_irq+0x78/0xa0 [ 545.526291]
> > > [<ffffff80080d760c>]
> > > generic_handle_irq+0x24/0x38 [ 545.526296] [<ffffff80080d7944>]
> > > __handle_domain_irq+0x5c/0xb8 [ 545.526299] [<ffffff80080824bc>]
> > > gic_handle_irq+0x64/0xc0 [ 545.526302] Exception
> > > stack(0xffffffc87b07f870
> > to 0xffffffc87b07f990)
> > > [ 545.526306] f860: 00000000000097=
32 ffffff800a1eaaa8
> > > ** 8 printk messages dropped ** [ 545.526341] f980:
> > > ffffff800a1c39e8
> > > 0000000000000036 [ 545.526345] [<ffffff8008085720>]
> > > el1_irq+0xa0/0x100 [ 545.526349] [<ffffff80080d6234>]
> > > console_unlock+0x384/0x5b0 [ 545.526353] [<ffffff80080d673c>]
> > > vprintk_emit+0x2dc/0x4b0 [ 545.526357] [<ffffff80080d6a50>]
> > > vprintk_default+0x38/0x40 [ 545.526362] [<ffffff8008129704>]
> > > printk+0x58/0x60 [ 545.526366] [<ffffff800859e3e4>]
> > > ath9k_iowrite32+0x9c/0xa8 [ 545.526372] [<ffffff80085c7ca8>]
> > > ath9k_hw_kill_interrupts+0x28/0xf0
> > > [ 545.526376] [<ffffff80085a18ec>] ath_reset+0x24/0x68
> > > ** 2 printk messages dropped ** [ 545.526391] [<ffffff800885ad60>]
> > ieee80211_hw_config+0x50/0x290
> > > ** 11 printk messages dropped ** [ 545.532834]
> > > ath9k_hw_kill_interrupts
> > 793
> > > [ 545.532890] ath9k_hw_enable_interrupts 821
> > >
> > >
> > > But if we have less debug prints it does not reach EP handler
> > > sometimes, due to following Condition in "kernel/irq/chip.c" in
> > > function handle_simple_irq
> > >
> > > if (unlikely(!desc->action || irqd_irq_disabled(&desc->irq_data))) {
> > > desc->istate |=3D IRQS_PENDING;
> > > goto out_unlock;
> > > }
> > > Here irqd_irq_disabled is being set to 1.
> > >
> > > With lesser debug prints it stops after following prints:
> > > root@Xilinx-ZCU102-2016_3:~# iw dev wlan0 scan
> > > [ 54.781045] ath9k_hw_kill_interrupts 793
> > > [ 54.785007] ath9k_hw_kill_interrupts 793
> > > [ 54.792535] ath9k_hw_enable_interrupts 821
> > > [ 54.796642] ath9k_hw_enable_interrupts 825
> > > [ 54.800807] ath9k_hw_enable_interrupts 832
> > > [ 54.804973] AR_SREV_9100 0
> > > [ 54.807663] ath9k_hw_enable_interrupts 848
> > > [ 54.811843] ath9k_hw_intrpend 762
> > > [ 54.815211] (AR_SREV_9340(ah) val 0
> > > [ 54.818684] ath9k_hw_intrpend 767
> > > [ 54.822078] ath_isr 603
> > > [ 54.824587] ath9k_hw_kill_interrupts 793
> > > [ 54.828601] ath9k_hw_enable_interrupts 821
> > > [ 54.832750] ath9k_hw_enable_interrupts 825
> > > [ 54.836916] ath9k_hw_enable_interrupts 832
> > > [ 54.841082] AR_SREV_9100 0
> > > [ 54.843772] ath9k_hw_enable_interrupts 848
> > > [ 54.843775] ath9k_hw_intrpend 762
> > > [ 54.851319] (AR_SREV_9340(ah) val 0
> > > [ 54.854793] ath9k_hw_intrpend 767
> > > [ 54.858185] ath_isr 603
> > > [ 54.860696] ath9k_hw_kill_interrupts 793
> > > [ 54.864776] ath9k_hw_enable_interrupts 821
> > > [ 54.867061] ath9k_hw_kill_interrupts 793
> > > [ 54.872870] ath9k_hw_enable_interrupts 825
> > > [ 54.877036] ath9k_hw_enable_interrupts 832
> > > [ 54.881202] AR_SREV_9100 0
> > > [ 54.883892] ath9k_hw_enable_interrupts 848
> > > [ 75.963129] INFO: rcu_sched detected stalls on CPUs/tasks:
> > > [ 75.968602] 0-...: (2 GPs behind) idle=3D9d5/140000000000001/0
> > softirq=3D1103/1109 fqs=3D519
> > > [ 75.976675] (detected by 2, t=3D5274 jiffies, g=3D64, c=3D63, q=
=3D11)
> > > [ 75.982485] Task dump for CPU 0:
> > > [ 75.985696] ksoftirqd/0 R running task 0 3 2 =
0x00000002
> > > [ 75.992726] Call trace:
> > > [ 75.995165] [<ffffff8008086b3c>] __switch_to+0xc4/0xd0
> > > [ 76.000281] [<ffffffc87b830500>] 0xffffffc87b830500
> > > [ 139.059027] INFO: rcu_sched detected stalls on CPUs/tasks:
> > > [ 139.064430] 0-...: (2 GPs behind) idle=3D9d5/140000000000001/0
> > softirq=3D1103/1109 fqs=3D2097
> > > [ 139.072593] (detected by 2, t=3D21049 jiffies, g=3D64, c=3D63, q=
=3D11)
> > > [ 139.078489] Task dump for CPU 0:
> > > [ 139.081700] ksoftirqd/0 R running task 0 3 2 =
0x00000002
> > > [ 139.088731] Call trace:
> > > [ 139.091165] [<ffffff8008086b3c>] __switch_to+0xc4/0xd0 [
> > > 139.096285] [<ffffffc87b830500>] 0xffffffc87b830500
> > >
> > >
> > >> > We are not seeing any issues on 32-bit ARM platform and X86
> > >> > platform.
> > >>
> > >> Can you collect a dmesg log (or, if the system hang means you can't
> > >> collect that, a console log with "ignore_loglevel"), and "lspci -vv"
> > >> output as root? That should have clues about whether the INTx got
> > >> routed correctly. /proc/interrupts should also show whether we're
> > >> receiving interrupts from the device.
> > >
> > > Here is the lspci output:
> > > 00:00.0 PCI bridge: Xilinx Corporation Device d022 (prog-if 00
> > > [Normal
> > decode])
> > > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> > ParErr- Stepping- SERR- FastB2B- DisINTx-
> > > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort-
> > <TAbort- <MAbort- >SERR- <PERR- INTx-
> > > Latency: 0
> > > Interrupt: pin A routed to IRQ 224
> > > Bus: primary=3D00, secondary=3D01, subordinate=3D0c, sec-latency=3D0
> > > I/O behind bridge: 00000000-00000fff
> > > Memory behind bridge: e0000000-e00fffff
> > > Prefetchable memory behind bridge: 00000000fff00000-
> > 00000000000fffff
> > > Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=3Dfast >TAbort-
> > <TAbort- <MAbort- <SERR- <PERR-
> > > BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
> > > PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
> > > Capabilities: [40] Power Management version 3
> > > Flags: PMEClk- DSI- D1- D2- AuxCurrent=3D0mA
> > PME(D0+,D1+,D2+,D3hot+,D3cold-)
> > > Status: D0 NoSoftRst+ PME-Enable- DSel=3D0 DScale=3D0 PME-
> > > Capabilities: [60] Express (v2) Root Port (Slot-), MSI 00
> > > DevCap: MaxPayload 256 bytes, PhantFunc 0
> > > ExtTag- RBE+
> > > DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> > Unsupported-
> > > RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
> > > MaxPayload 128 bytes, MaxReadReq 512 bytes
> > > DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr-
> > TransPend+
> > > LnkCap: Port #0, Speed 5GT/s, Width x2, ASPM not supported,
> > Exit Latency L0s unlimited, L1 unlimited
> > > ClockPM- Surprise- LLActRep- BwNot+ ASPMOptComp+
> > > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
> > > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> > > LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
> > DLActive- BWMgmt- ABWMgmt-
> > > RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna-
> > CRSVisible+
> > > RootCap: CRSVisible+
> > > RootSta: PME ReqID 0000, PMEStatus- PMEPending-
> > > DevCap2: Completion Timeout: Range B, TimeoutDis+, LTR-,
> > OBFF Not Supported ARIFwd-
> > > DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-,
> > OBFF Disabled ARIFwd-
> > > LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
> > > Transmit Margin: Normal Operating Range,
> > EnterModifiedCompliance- ComplianceSOS-
> > > Compliance De-emphasis: -6dB
> > > LnkSta2: Current De-emphasis Level: -3.5dB,
> > EqualizationComplete-, EqualizationPhase1-
> > > EqualizationPhase2-, EqualizationPhase3-,
> > LinkEqualizationRequest-
> > > Capabilities: [100 v1] Device Serial Number 00-00-00-00-00-00-00-00
> > > Capabilities: [10c v1] Virtual Channel
> > > Caps: LPEVC=3D0 RefClk=3D100ns PATEntryBits=3D1
> > > Arb: Fixed- WRR32- WRR64- WRR128-
> > > Ctrl: ArbSelect=3DFixed
> > > Status: InProgress-
> > > VC0: Caps: PATOffset=3D00 MaxTimeSlots=3D1 RejSnoopTrans-
> > > Arb: Fixed- WRR32- WRR64- WRR128- TWRR128-
> > WRR256-
> > > Ctrl: Enable+ ID=3D0 ArbSelect=3DFixed TC/VC=3Dff
> > > Status: NegoPending- InProgress-
> > > Capabilities: [128 v1] Vendor Specific Information: ID=3D1234 Rev=3D=
1
> > > Len=3D018 <?>
> > >
> > > 01:00.0 Network controller: Qualcomm Atheros AR93xx Wireless Network
> > Adapter (rev 01)
> > > Subsystem: Qualcomm Atheros Device 3112
> > > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> > ParErr- Stepping- SERR- FastB2B- DisINTx-
> > > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort-
> > <TAbort- <MAbort- >SERR- <PERR- INTx-
> > > Latency: 0, Cache Line Size: 128 bytes
> > > Interrupt: pin A routed to IRQ 224
> > > Region 0: Memory at e0000000 (64-bit, non-prefetchable) [size=3D128K=
]
> > > [virtual] Expansion ROM at e0020000 [disabled] [size=3D64K]
> > > Capabilities: [40] Power Management version 3
> > > Flags: PMEClk- DSI- D1+ D2- AuxCurrent=3D375mA
> > PME(D0+,D1+,D2-,D3hot+,D3cold-)
> > > Status: D0 NoSoftRst- PME-Enable- DSel=3D0 DScale=3D0 PME-
> > > Capabilities: [50] MSI: Enable- Count=3D1/4 Maskable+ 64bit+
> > > Address: 0000000000000000 Data: 0000
> > > Masking: 00000000 Pending: 00000000
> > > Capabilities: [70] Express (v2) Endpoint, MSI 00
> > > DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency
> > L0s <1us, L1 <8us
> > > ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
> > SlotPowerLimit 0.000W
> > > DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> > Unsupported-
> > > RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
> > > MaxPayload 128 bytes, MaxReadReq 512 bytes
> > > DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr-
> > TransPend-
> > > LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit
> > Latency L0s <2us, L1 <64us
> > > ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
> > > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
> > > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> > > LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
> > DLActive- BWMgmt- ABWMgmt-
> > > DevCap2: Completion Timeout: Not Supported, TimeoutDis+,
> > LTR-, OBFF Not Supported
> > > DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-,
> > OBFF Disabled
> > > LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance-
> > SpeedDis-
> > > Transmit Margin: Normal Operating Range,
> > EnterModifiedCompliance- ComplianceSOS-
> > > Compliance De-emphasis: -6dB
> > > LnkSta2: Current De-emphasis Level: -6dB,
> > EqualizationComplete-, EqualizationPhase1-
> > > EqualizationPhase2-, EqualizationPhase3-,
> > LinkEqualizationRequest-
> > > Capabilities: [100 v1] Advanced Error Reporting
> > > UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
> > RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> > > UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
> > RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> > > UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt-
> > RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
> > > CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
> > NonFatalErr-
> > > CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
> > NonFatalErr+
> > > AERCap: First Error Pointer: 00, GenCap- CGenEn-
> > ChkCap- ChkEn-
> > > Capabilities: [140 v1] Virtual Channel
> > > Caps: LPEVC=3D0 RefClk=3D100ns PATEntryBits=3D1
> > > Arb: Fixed- WRR32- WRR64- WRR128-
> > > Ctrl: ArbSelect=3DFixed
> > > Status: InProgress-
> > > VC0: Caps: PATOffset=3D00 MaxTimeSlots=3D1 RejSnoopTrans-
> > > Arb: Fixed- WRR32- WRR64- WRR128- TWRR128-
> > WRR256-
> > > Ctrl: Enable+ ID=3D0 ArbSelect=3DFixed TC/VC=3Dff
> > > Status: NegoPending- InProgress-
> > > Capabilities: [300 v1] Device Serial Number 00-00-00-00-00-00-00-00
> > > Kernel driver in use: ath9k
> > >
> > > Here is the cat /proc/interrupts (after we do interface up):
> > >
> > > root@:~# ifconfig wlan0 up
> > > [ 1548.926601] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> > > root@Xilinx-ZCU102-2016_3:~# cat /proc/interrupts
> > > CPU0 CPU1 CPU2 CPU3
> > > 1: 0 0 0 0 GICv2 29 Edge =
arch_timer
> > > 2: 19873 20058 19089 17435 GICv2 30 Edge =
arch_timer
> > > 12: 0 0 0 0 GICv2 156 Level =
zynqmp-dma
> > > 13: 0 0 0 0 GICv2 157 Level =
zynqmp-dma
> > > 14: 0 0 0 0 GICv2 158 Level =
zynqmp-dma
> > > 15: 0 0 0 0 GICv2 159 Level =
zynqmp-dma
> > > 16: 0 0 0 0 GICv2 160 Level =
zynqmp-dma
> > > 17: 0 0 0 0 GICv2 161 Level =
zynqmp-dma
> > > 18: 0 0 0 0 GICv2 162 Level =
zynqmp-dma
> > > 19: 0 0 0 0 GICv2 163 Level =
zynqmp-dma
> > > 20: 0 0 0 0 GICv2 164 Level =
Mali_GP_MMU,
> Mali_GP,
> > Mali_PP0_MMU, Mali_PP0, Mali_PP1_MMU, Mali_PP1
> > > 30: 0 0 0 0 GICv2 95 Level =
eth0, eth0
> > > 206: 314 0 0 0 GICv2 49 Level =
cdns-i2c
> > > 207: 40 0 0 0 GICv2 50 Level =
cdns-i2c
> > > 209: 0 0 0 0 GICv2 150 Level =
nwl_pcie:misc
> > > 214: 12 0 0 0 GICv2 47 Level =
ff0f0000.spi
> > > 215: 0 0 0 0 GICv2 58 Level =
ffa60000.rtc
> > > 216: 0 0 0 0 GICv2 59 Level =
ffa60000.rtc
> > > 217: 0 0 0 0 GICv2 165 Level =
ahci-
> ceva[fd0c0000.ahci]
> > > 218: 61 0 0 0 GICv2 81 Level =
mmc0
> > > 219: 0 0 0 0 GICv2 187 Level =
arm-smmu global fault
> > > 220: 471 0 0 0 GICv2 53 Level =
xuartps
> > > 223: 0 0 0 0 GICv2 154 Level =
fd4c0000.dma
> > > 224: 3 0 0 0 dummy 1 Edge =
ath9k
> > > 225: 0 0 0 0 GICv2 97 Level =
xhci-hcd:usb1
> > >
> > > Regards,
> > > Bharat
> >
> > --
> > Kalle Valo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in t=
he body of
> a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 10/14] rtlwifi: Add BTC_TRACE_STRING to new btcoex
From: Kalle Valo @ 2016-12-09 8:48 UTC (permalink / raw)
To: Dan Carpenter; +Cc: devel, Ping-Ke Shih, linux-wireless, Larry Finger
In-Reply-To: <20161208115049.GR8176@mwanda>
Dan Carpenter <dan.carpenter@oracle.com> writes:
> I don't have a problem with the ath debug printks. Larry asked me for
> examples of better debug functions and the ath code is an example.
> Literally, any existing debug functions are better than the
> BTC_TRACE_STRING() stuff.
Sure, I agree with that. My point was just that sometimes it's ok to
have own logging wrappers and there's no hard rule for this.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 10/14] rtlwifi: Add BTC_TRACE_STRING to new btcoex
From: Kalle Valo @ 2016-12-09 8:50 UTC (permalink / raw)
To: Dan Carpenter; +Cc: devel, Ping-Ke Shih, linux-wireless, Larry Finger
In-Reply-To: <20161208115450.GK8244@mwanda>
Dan Carpenter <dan.carpenter@oracle.com> writes:
> On Thu, Dec 08, 2016 at 02:50:49PM +0300, Dan Carpenter wrote:
>> On Thu, Dec 08, 2016 at 01:43:42PM +0200, Kalle Valo wrote:
>> > But it would make me very happy if someone would add a similar grouping
>> > functionality to dyndbg to make it easy to enable a set of debug
>> > messages in a driver.
>>
>> Thats seems like a reasonable thing as well.
>
> I actually like the ath code... We could easily change it to be more
> generic and make it a top level function for everyone to use.
That would be great. And maybe add a sysfs file with a description
different levels, like module parameters have. Too bad that I can't work
on that, too much stuff on my plate right now.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] RFC: Universal scan proposal
From: Arend Van Spriel @ 2016-12-09 11:10 UTC (permalink / raw)
To: Dmitry Shmidt; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <CAH7ZN-wGseBVzV3Vuq+6=kgaSL7e0UnndGXPdu4PQKZw8H47YQ@mail.gmail.com>
On 8-12-2016 23:35, Dmitry Shmidt wrote:
> On Wed, Dec 7, 2016 at 12:51 PM, Arend Van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> On 7-12-2016 19:39, Dmitry Shmidt wrote:
>>> On Tue, Dec 6, 2016 at 10:44 PM, Johannes Berg
>>> <johannes@sipsolutions.net> wrote:
>>>>
>>>>> Indeed, results are results. I just want to take care of two things:
>>>>> 1) Memory consumption - we can clear stale scan results for
>>>>> connection, but not for location if we are using history scan.
>>>>
>>>> Well eventually we also have to clear for location if we run out of
>>>> memory, that usually means dumping them out to the host, no?
>>>
>>> Being out of memory and consuming more memory are different
>>> things, but I agree - maybe we don't need to worry about it.
So does location use all information from the scan history or is it
interested in some specific information, eg. rssi.
>>>>> 2) Use of insufficient results for connection - in case we had
>>>>> history or hotlist scan only for very limited amount of channels,
>>>>> then we may not have enough APs in our result for "sterling"
>>>>> connection decision.
>>>>
>>>> I'm not entirely sure about this case - surely noticing "we can do
>>>> better now" is still better than waiting for being able to make the
>>>> perfect decision?
>>>
>>> Maybe we can just keep flag saying that currently available results
>>> were not received by usual full scan.
>>>
>>>>>>> Report: none / batch / immediate
>>>>>>
>>>>>> Not sure I see much point in "none"??
>>>>>>
>>>>>> Can you define these more clearly? Do you think "batch" reporting
>>>>>> should be like the gscan buckets? Or actually have full
>>>>>> information?
>>>>>
>>>>> None - means that there is not need to report. It can be useful
>>>>> in case of roaming scan, scheduling or hotlist scan - you didn't find
>>>>> anything suitable - don't report that there is no scan results.
>>>>
>>>> But that seems more of a filtering thing, combined with "immediate" for
>>>> anything passing the filter?
>>>
>>> We can use this approach as well.
>>>
>>>>>>> Request may have priority and can be inserted into
>>>>>>> the head of the queue.
>>>>>>> Types of scans:
>>>>>>> - Normal scan
>>>>>>> - Scheduled scan
>>>>>>> - Hotlist (BSSID scan)
>>>>>>> - Roaming
>>>>>>> - AutoJoin
>>>>>>
>>>>>> I think somebody else said this but I didn't find it now - I think
>>>>>> this would make more sense to define in terms of expected behaviour
>>>>>> than use cases for each type of scan.
>>>>>
>>>>> I think Luca made this statement.
>>>>
>>>> Yeah - I just couldn't find it again on re-reading the thread :)
>>>>
>>>>> It is totally ok from SW point of
>>>>> view - especially due to the fact that scan is scan. However,
>>>>> I suspect it will be harder to handle from user experience. I mean
>>>>> at the end wireless framework / driver / FW will convert special
>>>>> scan type to usual scan with special params and response, but why
>>>>> to put this burden on user?
>>
>> I don't think this will put burden on the user although it depends
>> who/what you mean by this. If you mean the mere mortal end-user I would
>> say no as indeed there must be some software entity (in user-space) that
>> will have to initiate a nl80211 command with appropriate attributes
>> according to whatever user-space is trying to accomplish.
>>
>>>> I just think it's more flexible and open-ended. The actual definition
>>>> of the resulting parameters needs to be somewhere anyway - putting it
>>>> into driver/firmware (vs. wifi framework or so) seems to duplicate it
>>>> and certainly makes it harder to modify/extend in the future, no?
>>>
>>> So, let's summarize:
>>> Instead of creating new type of generic scan with special types,
>>> we want to go with additional expansion of scheduled scan options and
>>> parameters (in order not to "multiply entities"), including ability to send
>>> new scheduled scan request without stopping previous one.
>>>
>>> Is it Ok?
>>
>> Sounds ok. To me a generic scan command with type attribute is
>> equivalent to having seperate commands for each type so there seems to
>> be no gain. Now whether this all can be accomplished by extending the
>> scheduled scan depends on the problem that you are trying to solve.
>>
>> Main purpose seems to be offloading different scanning tasks which could
>> make scheduled scan a good candidate. Now I want to add gscan to this
>> mix as it seems some concepts for that are in play in this discussion as
>> well, eg. hotlist. gscan is like scheduled scan, but it supports
>> multiple schedules. However, it is still a single request from a single
>> user-space process. I think Luca mentioned supporting requests from
>> different user-space processes. Is that also what you mean by "ability
>> to send new scheduled scan request without stopping previous one" or is
>> that still from a single user-space process. Do we need a limit to the
>> amount of scheduled scan requests that can be handled simultaneously.
>
> Supporting requests (or more precisely requests and results) differentiated
> by user-space entity can be tricky. Right now we are not checking current
> caller pid, right? Maybe it is also good idea - or maybe we can just
> make result filtering per user-space caller?
There is already struct cfg80211_sched_scan_request::owner_nlportid
* @owner_nlportid: netlink portid of owner (if this should is a request
* owned by a particular socket)
It is set in nl80211_start_sched_scan():
if (info->attrs[NL80211_ATTR_SOCKET_OWNER])
sched_scan_req->owner_nlportid = info->snd_portid;
It basically links the life-time of the request to the socket connection
if requested to do so. It is just not very useful with tools like iw.
>> A maybe more important aspect of gscan is user-space control of result
>> reporting and thus the frequency of waking up host and/or user-space. I
>> suspect this would be needed in the scheduled scan extension as well, right?
>
> It will be always up to user-space caller to make system more or less
> power-efficient, right?
That depends on the API, right? If the API provides the knobs, than
user-space can indeed make the decision.
Regards,
Arend
>> Regards,
>> Arend
^ permalink raw reply
* [PATCH for-4.10 0/2] brcmfmac: small fixes for after merge window
From: Arend van Spriel @ 2016-12-09 11:34 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel
Two issues found during more testing. The first patch fixes a memory leak
in error path. The second one fixes a regression introduced by a change
that currently sits in wireless-drivers-next.
These patches have been applied on top of wireless-drivers-next/master branch
so it can apply on wireless-drivers/master after the merge window (fingers
crossed).
Arend van Spriel (2):
brcmfmac: fix memory leak in brcmf_cfg80211_attach()
brcmfmac: fix uninitialized field in scheduled scan ssid configuration
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 7 +++++--
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c | 1 +
2 files changed, 6 insertions(+), 2 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH for-4.10 1/2] brcmfmac: fix memory leak in brcmf_cfg80211_attach()
From: Arend van Spriel @ 2016-12-09 11:34 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1481283254-17883-1-git-send-email-arend.vanspriel@broadcom.com>
In brcmf_cfg80211_attach() there was one error path not properly
handled as it leaked memory allocated in brcmf_btcoex_attach().
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index ccae3bb..7ffc4ab 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -6868,7 +6868,7 @@ struct brcmf_cfg80211_info *brcmf_cfg80211_attach(struct brcmf_pub *drvr,
err = brcmf_p2p_attach(cfg, p2pdev_forced);
if (err) {
- brcmf_err("P2P initilisation failed (%d)\n", err);
+ brcmf_err("P2P initialisation failed (%d)\n", err);
goto wiphy_unreg_out;
}
err = brcmf_btcoex_attach(cfg);
@@ -6893,7 +6893,7 @@ struct brcmf_cfg80211_info *brcmf_cfg80211_attach(struct brcmf_pub *drvr,
err = brcmf_fweh_activate_events(ifp);
if (err) {
brcmf_err("FWEH activation failed (%d)\n", err);
- goto wiphy_unreg_out;
+ goto detach;
}
/* Fill in some of the advertised nl80211 supported features */
@@ -6908,6 +6908,9 @@ struct brcmf_cfg80211_info *brcmf_cfg80211_attach(struct brcmf_pub *drvr,
return cfg;
+detach:
+ brcmf_btcoex_detach(cfg);
+ brcmf_p2p_detach(&cfg->p2p);
wiphy_unreg_out:
wiphy_unregister(cfg->wiphy);
priv_out:
--
1.9.1
^ permalink raw reply related
* [PATCH for-4.10 2/2] brcmfmac: fix uninitialized field in scheduled scan ssid configuration
From: Arend van Spriel @ 2016-12-09 11:34 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1481283254-17883-1-git-send-email-arend.vanspriel@broadcom.com>
The scheduled scan ssid configuration in firmware has a flags field that
was not initialized resulting in unexpected behaviour.
Fixes: e3bdb7cc0300 ("brcmfmac: fix handling ssids in .sched_scan_start() callback")
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c
index f273cab..9a25e79 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c
@@ -137,6 +137,7 @@ static int brcmf_pno_add_ssid(struct brcmf_if *ifp, struct cfg80211_ssid *ssid,
pfn.wpa_auth = cpu_to_le32(BRCMF_PNO_WPA_AUTH_ANY);
pfn.wsec = cpu_to_le32(0);
pfn.infra = cpu_to_le32(1);
+ pfn.flags = 0;
if (active)
pfn.flags = cpu_to_le32(1 << BRCMF_PNO_HIDDEN_BIT);
pfn.ssid.SSID_len = cpu_to_le32(ssid->ssid_len);
--
1.9.1
^ permalink raw reply related
* pull-request: mac80211-next 2016-12-09
From: Johannes Berg @ 2016-12-09 12:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
Closing net-next caught me by surprise, so I had to rebase a bit,
but these three patches really should go in soon. I'm not sending
them for 4.9 this late though.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit f81a8a02bb3b3e882ba6aa580230c13b5be64849:
Merge branch 'mV88e6xxx-interrupt-fixes' (2016-11-20 21:16:14 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2016-12-09
for you to fetch changes up to e6f462df9acd2a3295e5d34eb29e2823220cf129:
cfg80211/mac80211: fix BSS leaks when abandoning assoc attempts (2016-12-09 12:57:49 +0100)
----------------------------------------------------------------
Three fixes:
* fix a logic bug introduced by a previous cleanup
* fix nl80211 attribute confusing (trying to use
a single attribute for two purposes)
* fix a long-standing BSS leak that happens when an
association attempt is abandoned
----------------------------------------------------------------
Johannes Berg (2):
nl80211: fix logic inversion in start_nan()
cfg80211/mac80211: fix BSS leaks when abandoning assoc attempts
Vamsi Krishna (1):
nl80211: Use different attrs for BSSID and random MAC addr in scan req
include/net/cfg80211.h | 11 +++++++++++
include/uapi/linux/nl80211.h | 7 ++++++-
net/mac80211/mlme.c | 21 ++++++++++++---------
net/wireless/core.h | 1 +
net/wireless/mlme.c | 12 ++++++++++++
net/wireless/nl80211.c | 18 ++++++++++++++++--
net/wireless/sme.c | 14 ++++++++++++++
7 files changed, 72 insertions(+), 12 deletions(-)
^ permalink raw reply
* Re: ATH9 driver issues on ARM64
From: Tobias Klausmann @ 2016-12-09 14:22 UTC (permalink / raw)
To: Kalle Valo, Bharat Kumar Gogada
Cc: Bjorn Helgaas, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, Marc Zyngier,
Janusz.Dziedzic@tieto.com, rmanohar@qti.qualcomm.com,
ath9k-devel@qca.qualcomm.com, linux-wireless
In-Reply-To: <874m2emif9.fsf@purkki.adurom.net>
Hello there,
as this is a thread about ath9k and ARM64, i'm not sure if i should
answer here or not, but i have similar "stalls" with ath9k on x86_64
(starting with 4.9rc), stack trace is posted down below where the
original ARM64 stall traces are.
Greetings,
Tobias
On 08.12.2016 18:36, Kalle Valo wrote:
> Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com> writes:
>
>> > [+cc Kalle, ath9k list]
> Thanks, but please also CC linux-wireless. Full thread below for the
> folks there.
>
>>> On Thu, Dec 08, 2016 at 01:49:42PM +0000, Bharat Kumar Gogada wrote:
>>>> Hi,
>>>>
>>>> Did anyone test Atheros ATH9 driver(drivers/net/wireless/ath/ath9k/)
>>>> on ARM64. The end point is TP link wifi card with which supports
>>>> only legacy interrupts.
>>> If it works on other arches and the arm64 PCI enumeration works, my
>>> first guess would be an INTx issue, e.g., maybe the driver is waiting
>>> for an interrupt that never arrives.
>> We are not sure for now.
>>>> We are trying to test it on ARM64 with
>>>> (drivers/pci/host/pcie-xilinx-nwl.c) as root port.
>>>>
>>>> EP is getting enumerated and able to link up.
>>>>
>>>> But when we start scan system gets hanged.
>>> When you say the system hangs when you start a scan, I assume you mean
>>> a wifi scan, not the PCI enumeration. A problem with a wifi scan
>>> might cause a *process* to hang, but it shouldn't hang the entire
>>> system.
>>>
>> Yes wifi scan.
>>>> When we took trace we see that after we start scan assert message is
>>>> sent but there is no de assert from end point.
>>> Are you talking about a trace from a PCIe analyzer? Do you see an
>>> Assert_INTx PCIe message on the link?
>>>
>> Yes lecroy trace, yes we do see Assert_INTx and Deassert_INTx happening when we do interface link up.
>> When we have less debug prints in Atheros driver, and do wifi scan we see Assert_INTx but never Deassert_INTx,
>>>> What might cause end point not sending de assert ?
>>> If the endpoint doesn't send a Deassert_INTx message, I expect that
>>> would mean the driver didn't service the interrupt and remove the
>>> condition that caused the device to assert the interrupt in the first
>>> place.
>>>
>>> If the driver didn't receive the interrupt, it couldn't service it, of
>>> course. You could add a printk in the ath9k interrupt service
>>> routine to see if you ever get there.
>>>
>> The interrupt behavior is changing w.r.t amount of debug prints we add. (I kept many prints to aid debug)
>> root@Xilinx-ZCU102-2016_3:~# iw dev wlan0 scan
>> [ 83.064675] ath9k: ath9k_iowrite32 ffffff800a400024
>> [ 83.069486] ath9k: ath9k_ioread32 ffffff800a400024
>> [ 83.074257] ath9k_hw_kill_interrupts 793
>> [ 83.078260] ath9k: ath9k_iowrite32 ffffff800a400024
>> [ 83.083107] ath9k: ath9k_ioread32 ffffff800a400024
>> [ 83.087882] ath9k_hw_kill_interrupts 793
>> [ 83.095450] ath9k_hw_enable_interrupts 821
>> [ 83.099557] ath9k_hw_enable_interrupts 825
>> [ 83.103721] ath9k_hw_enable_interrupts 832
>> [ 83.107887] ath9k: ath9k_iowrite32 ffffff800a400024
>> [ 83.112748] AR_SREV_9100 0
>> [ 83.115438] ath9k_hw_enable_interrupts 848
>> [ 83.119607] ath9k: ath9k_ioread32 ffffff800a400024
>> [ 83.124389] ath9k_hw_intrpend 762
>> [ 83.127761] (AR_SREV_9340(ah) val 0
>> [ 83.131234] ath9k_hw_intrpend 767
>> [ 83.134628] ath_isr 603
>> [ 83.137134] ath9k: ath9k_iowrite32 ffffff800a400024
>> [ 83.141995] ath9k: ath9k_ioread32 ffffff800a400024
>> [ 83.146771] ath9k_hw_kill_interrupts 793
>> [ 83.150864] ath9k_hw_enable_interrupts 821
>> [ 83.154971] ath9k_hw_enable_interrupts 825
>> [ 83.159135] ath9k_hw_enable_interrupts 832
>> [ 83.163300] ath9k: ath9k_iowrite32 ffffff800a400024
>> [ 83.168161] AR_SREV_9100 0
>> [ 83.170852] ath9k_hw_enable_interrupts 848
>> [ 83.170855] ath9k_hw_intrpend 762
>> [ 83.178398] (AR_SREV_9340(ah) val 0
>> [ 83.181873] ath9k_hw_intrpend 767
>> [ 83.185265] ath_isr 603
>> [ 83.187773] ath9k: ath9k_iowrite32 ffffff800a400024
>> [ 83.192635] ath9k: ath9k_ioread32 ffffff800a400024
>> [ 83.197411] ath9k_hw_kill_interrupts 793
>> [ 83.201414] ath9k: ath9k_ioread32 ffffff800a400024
>> [ 83.206258] ath9k_hw_enable_interrupts 821
>> [ 83.210368] ath9k_hw_enable_interrupts 825
>> [ 83.214531] ath9k_hw_enable_interrupts 832
>> [ 83.218698] ath9k: ath9k_iowrite32 ffffff800a400024
>> [ 83.223558] AR_SREV_9100 0
>> [ 83.226243] ath9k_hw_enable_interrupts 848
>> [ 83.226246] ath9k_hw_intrpend 762
>> [ 83.233794] (AR_SREV_9340(ah) val 0
>> [ 83.237268] ath9k_hw_intrpend 767
>> [ 83.240661] ath_isr 603
>> [ 83.243169] ath9k: ath9k_iowrite32 ffffff800a400024
>> [ 83.248030] ath9k: ath9k_ioread32 ffffff800a400024
>> [ 83.252806] ath9k_hw_kill_interrupts 793
>> [ 83.256811] ath9k: ath9k_ioread32 ffffff800a400024
>> [ 83.261651] ath9k_hw_enable_interrupts 821
>> [ 83.265753] ath9k_hw_enable_interrupts 825
>> [ 83.269919] ath9k_hw_enable_interrupts 832
>> [ 83.274083] ath9k: ath9k_iowrite32 ffffff800a400024
>> [ 83.278945] AR_SREV_9100 0
>> [ 83.281630] ath9k_hw_enable_interrupts 848
>> [ 83.281633] ath9k_hw_intrpend 762
>> [ 83.281634] (AR_SREV_9340(ah) val 0
>> [ 83.281637] ath9k_hw_intrpend 767
>> [ 83.281648] ath_isr 603
>> [ 83.281649] ath9k: ath9k_iowrite32 ffffff800a400024
>> [ 83.281651] ath9k: ath9k_ioread32 ffffff800a400024
>> [ 83.281654] ath9k_hw_kill_interrupts 793
>> [ 83.312192] ath9k: ath9k_ioread32 ffffff800a400024
>> [ 83.317030] ath9k_hw_enable_interrupts 821
>> [ 83.321132] ath9k_hw_enable_interrupts 825
>> [ 83.325297] ath9k_hw_enable_interrupts 832
>> [ 83.329463] ath9k: ath9k_iowrite32 ffffff800a400024
>> [ 83.334324] AR_SREV_9100 0
>> [ 83.337014] ath9k_hw_enable_interrupts 848
>> ..
>> ..
>> This log continues until I turn off board without obtaining scanning result.
>>
>> In between I get following cpu stall outputs :
>> 230.457179] INFO: rcu_sched self-detected stall on CPU
>> [ 230.457185] 2-...: (31314 ticks this GP) idle=2d1/140000000000001/0 softirq=1400/1400 fqs=36713
>> [ 230.457189] (t=36756 jiffies g=161 c=160 q=16169)
>> [ 230.457191] Task dump for CPU 2:
>> [ 230.457196] kworker/u8:4 R running task 0 1342 2 0x00000002
>> [ 230.457207] Workqueue: phy0 ieee80211_scan_work
>> [ 230.457208] Call trace:
>> [ 230.457214] [<ffffff8008089860>] dump_backtrace+0x0/0x198
>> [ 230.457219] [<ffffff8008089a0c>] show_stack+0x14/0x20
>> [ 230.457224] [<ffffff80080c0930>] sched_show_task+0x98/0xf8
>> [ 230.457228] [<ffffff80080c2628>] dump_cpu_task+0x40/0x50
>> [ 230.457233] [<ffffff80080e14a8>] rcu_dump_cpu_stacks+0xa0/0xf0
>> [ 230.457239] [<ffffff80080e4cd8>] rcu_check_callbacks+0x468/0x748
>> [ 230.457243] [<ffffff80080e7cfc>] update_process_times+0x3c/0x68
>> [ 230.457249] [<ffffff80080f6dfc>] tick_sched_handle.isra.5+0x3c/0x50
>> [ 230.457253] [<ffffff80080f6e54>] tick_sched_timer+0x44/0x90
>> [ 230.457257] [<ffffff80080e86b0>] __hrtimer_run_queues+0xf0/0x178
>> ** 10 printk messages dropped ** [ 230.457302] f8c0: 0000000000000000 0000000005f5e0ff 000000000001379a 3866666666666620
>> [ 230.457306] f8e0: ffffff800a1b4065 0000000000000006 ffffff800a129000 ffffffc87b8010a8
>> [ 230.457310] f900: ffffff808a1b4057 ffffff800a1c3000 ffffff800a1b3000 ffffff800a13b000
>> [ 230.457314] f920: 0000000000000140 0000000000000006 ffffff800a1b3b10 ffffff800a1c39e8
>> [ 230.457318] f940: 000000000000002f ffffff800a1b8a98 ffffff800a1b3ae8 ffffffc87b07f990
>> [ 230.457322] f960: ffffff80080d6230 ffffffc87b07f990 ffffff80080d6234 0000000060000145
>> ** 1 printk messages dropped ** [ 230.457329] [<ffffff8008085720>] el1_irq+0xa0/0x100
>> ** 9 printk messages dropped ** [ 230.457373] [<ffffff800885ad60>] ieee80211_hw_config+0x50/0x290
>> [ 230.457377] [<ffffff8008863690>] ieee80211_scan_work+0x1f8/0x480
>> [ 230.457383] [<ffffff80080b15d0>] process_one_work+0x120/0x378
>> [ 230.457386] [<ffffff80080b1870>] worker_thread+0x48/0x4b0
>> [ 230.457391] [<ffffff80080b7108>] kthread+0xd0/0xe8
>> [ 230.457395] [<ffffff8008085dd0>] ret_from_fork+0x10/0x40
>> [ 230.480389] ath9k_hw_intrpend 762
>>
>>
>> [ 545.487987] ath9k: ath9k_ioread32 ffffff800a400024
>> [ 545.526189] INFO: rcu_sched self-detected stall on CPU
>> [ 545.526195] 2-...: (97636 ticks this GP) idle=2d1/140000000000001/0 softirq=1400/1400 fqs=115374
>> [ 545.526199] (t=115523 jiffies g=161 c=160 q=51066)
>> [ 545.526201] Task dump for CPU 2:
>> [ 545.526206] kworker/u8:4 R running task 0 1342 2 0x00000002
>> ** 3 printk messages dropped ** [ 545.526231] [<ffffff8008089a0c>] show_stack+0x14/0x20
>> ** 9 printk messages dropped ** [ 545.526280] [<ffffff80086a71e8>] arch_timer_handler_phys+0x30/0x40
>> [ 545.526284] [<ffffff80080dbe18>] handle_percpu_devid_irq+0x78/0xa0
>> [ 545.526291] [<ffffff80080d760c>] generic_handle_irq+0x24/0x38
>> [ 545.526296] [<ffffff80080d7944>] __handle_domain_irq+0x5c/0xb8
>> [ 545.526299] [<ffffff80080824bc>] gic_handle_irq+0x64/0xc0
>> [ 545.526302] Exception stack(0xffffffc87b07f870 to 0xffffffc87b07f990)
>> [ 545.526306] f860: 0000000000009732 ffffff800a1eaaa8
>> ** 8 printk messages dropped ** [ 545.526341] f980: ffffff800a1c39e8 0000000000000036
>> [ 545.526345] [<ffffff8008085720>] el1_irq+0xa0/0x100
>> [ 545.526349] [<ffffff80080d6234>] console_unlock+0x384/0x5b0
>> [ 545.526353] [<ffffff80080d673c>] vprintk_emit+0x2dc/0x4b0
>> [ 545.526357] [<ffffff80080d6a50>] vprintk_default+0x38/0x40
>> [ 545.526362] [<ffffff8008129704>] printk+0x58/0x60
>> [ 545.526366] [<ffffff800859e3e4>] ath9k_iowrite32+0x9c/0xa8
>> [ 545.526372] [<ffffff80085c7ca8>] ath9k_hw_kill_interrupts+0x28/0xf0
>> [ 545.526376] [<ffffff80085a18ec>] ath_reset+0x24/0x68
>> ** 2 printk messages dropped ** [ 545.526391] [<ffffff800885ad60>] ieee80211_hw_config+0x50/0x290
>> ** 11 printk messages dropped ** [ 545.532834] ath9k_hw_kill_interrupts 793
>> [ 545.532890] ath9k_hw_enable_interrupts 821
[ 81.876902] INFO: rcu_preempt detected stalls on CPUs/tasks:
[ 81.876912] Tasks blocked on level-0 rcu_node (CPUs 0-7): P0
[ 81.876932] (detected by 4, t=60002 jiffies, g=1873, c=1872, q=4967)
[ 81.876936] swapper/4 R running task 0 0 1
0x00000000
[ 81.876941] 0000000000000001 ffffffff810725f6 ffff88017edbc240
ffffffff81a3dc40
[ 81.876945] ffffffff81101e46 ffff88025ef173c0 ffffffff81a3dc40
ffffffff81a3dc40
[ 81.876948] 00000000ffffffff ffffffff810a7333 ffff88017ecee698
ffff88017edbc240
[ 81.876951] Call Trace:
[ 81.876970] <IRQ>
[ 81.876979] [<ffffffff810725f6>] ? sched_show_task+0xd6/0x140
[ 81.876983] [<ffffffff81101e46>] ?
rcu_print_detail_task_stall_rnp+0x40/0x61
[ 81.876989] [<ffffffff810a7333>] ? rcu_check_callbacks+0x6b3/0x8c0
[ 81.876993] [<ffffffff810b8350>] ? tick_sched_handle.isra.14+0x40/0x40
[ 81.876996] [<ffffffff810aa4c3>] ? update_process_times+0x23/0x50
[ 81.876999] [<ffffffff810b8383>] ? tick_sched_timer+0x33/0x60
[ 81.877002] [<ffffffff810aaf09>] ? __hrtimer_run_queues+0xb9/0x150
[ 81.877004] [<ffffffff810ab198>] ? hrtimer_interrupt+0x98/0x1a0
[ 81.877008] [<ffffffff81031b1e>] ?
smp_trace_apic_timer_interrupt+0x5e/0x90
[ 81.877012] [<ffffffff815b31bf>] ? apic_timer_interrupt+0x7f/0x90
[ 81.877013] <EOI>
[ 81.877017] [<ffffffff8147f28d>] ? cpuidle_enter_state+0x13d/0x1f0
[ 81.877019] [<ffffffff8147f289>] ? cpuidle_enter_state+0x139/0x1f0
[ 81.877021] [<ffffffff81088c19>] ? cpu_startup_entry+0x139/0x210
[ 81.877027] [<ffffffff8102fc9e>] ? start_secondary+0x13e/0x170
[ 81.877029] swapper/4 R running task 0 0 1
0x00000000
[ 81.877032] 0000000000000001 ffffffff810725f6 ffff88017edbc240
ffffffff81a3dc40
[ 81.877035] ffffffff81101e46 ffff88025ef173c0 ffffffff81a3dc40
ffffffff81a3dc40
[ 81.877038] 00000000ffffffff ffffffff810a7368 ffff88017ecee698
ffff88017edbc240
[ 81.877041] Call Trace:
[ 81.877045] <IRQ>
[ 81.877049] [<ffffffff810725f6>] ? sched_show_task+0xd6/0x140
[ 81.877051] [<ffffffff81101e46>] ?
rcu_print_detail_task_stall_rnp+0x40/0x61
[ 81.877055] [<ffffffff810a7368>] ? rcu_check_callbacks+0x6e8/0x8c0
[ 81.877058] [<ffffffff810b8350>] ? tick_sched_handle.isra.14+0x40/0x40
[ 81.877060] [<ffffffff810aa4c3>] ? update_process_times+0x23/0x50
[ 81.877063] [<ffffffff810b8383>] ? tick_sched_timer+0x33/0x60
[ 81.877065] [<ffffffff810aaf09>] ? __hrtimer_run_queues+0xb9/0x150
[ 81.877068] [<ffffffff810ab198>] ? hrtimer_interrupt+0x98/0x1a0
[ 81.877070] [<ffffffff81031b1e>] ?
smp_trace_apic_timer_interrupt+0x5e/0x90
[ 81.877073] [<ffffffff815b31bf>] ? apic_timer_interrupt+0x7f/0x90
[ 81.877074] <EOI>
[ 81.877076] [<ffffffff8147f28d>] ? cpuidle_enter_state+0x13d/0x1f0
[ 81.877078] [<ffffffff8147f289>] ? cpuidle_enter_state+0x139/0x1f0
[ 81.877080] [<ffffffff81088c19>] ? cpu_startup_entry+0x139/0x210
[ 81.877084] [<ffffffff8102fc9e>] ? start_secondary+0x13e/0x170
[ 91.132787] INFO: rcu_preempt detected expedited stalls on
CPUs/tasks: { P0 } 63785 jiffies s: 505 root: 0x0/T
[ 91.132796] blocking rcu_node structures:
>>
>>
>> But if we have less debug prints it does not reach EP handler sometimes, due to following
>> Condition in "kernel/irq/chip.c" in function handle_simple_irq
>>
>> if (unlikely(!desc->action || irqd_irq_disabled(&desc->irq_data))) {
>> desc->istate |= IRQS_PENDING;
>> goto out_unlock;
>> }
>> Here irqd_irq_disabled is being set to 1.
>>
>> With lesser debug prints it stops after following prints:
>> root@Xilinx-ZCU102-2016_3:~# iw dev wlan0 scan
>> [ 54.781045] ath9k_hw_kill_interrupts 793
>> [ 54.785007] ath9k_hw_kill_interrupts 793
>> [ 54.792535] ath9k_hw_enable_interrupts 821
>> [ 54.796642] ath9k_hw_enable_interrupts 825
>> [ 54.800807] ath9k_hw_enable_interrupts 832
>> [ 54.804973] AR_SREV_9100 0
>> [ 54.807663] ath9k_hw_enable_interrupts 848
>> [ 54.811843] ath9k_hw_intrpend 762
>> [ 54.815211] (AR_SREV_9340(ah) val 0
>> [ 54.818684] ath9k_hw_intrpend 767
>> [ 54.822078] ath_isr 603
>> [ 54.824587] ath9k_hw_kill_interrupts 793
>> [ 54.828601] ath9k_hw_enable_interrupts 821
>> [ 54.832750] ath9k_hw_enable_interrupts 825
>> [ 54.836916] ath9k_hw_enable_interrupts 832
>> [ 54.841082] AR_SREV_9100 0
>> [ 54.843772] ath9k_hw_enable_interrupts 848
>> [ 54.843775] ath9k_hw_intrpend 762
>> [ 54.851319] (AR_SREV_9340(ah) val 0
>> [ 54.854793] ath9k_hw_intrpend 767
>> [ 54.858185] ath_isr 603
>> [ 54.860696] ath9k_hw_kill_interrupts 793
>> [ 54.864776] ath9k_hw_enable_interrupts 821
>> [ 54.867061] ath9k_hw_kill_interrupts 793
>> [ 54.872870] ath9k_hw_enable_interrupts 825
>> [ 54.877036] ath9k_hw_enable_interrupts 832
>> [ 54.881202] AR_SREV_9100 0
>> [ 54.883892] ath9k_hw_enable_interrupts 848
>> [ 75.963129] INFO: rcu_sched detected stalls on CPUs/tasks:
>> [ 75.968602] 0-...: (2 GPs behind) idle=9d5/140000000000001/0 softirq=1103/1109 fqs=519
>> [ 75.976675] (detected by 2, t=5274 jiffies, g=64, c=63, q=11)
>> [ 75.982485] Task dump for CPU 0:
>> [ 75.985696] ksoftirqd/0 R running task 0 3 2 0x00000002
>> [ 75.992726] Call trace:
>> [ 75.995165] [<ffffff8008086b3c>] __switch_to+0xc4/0xd0
>> [ 76.000281] [<ffffffc87b830500>] 0xffffffc87b830500
>> [ 139.059027] INFO: rcu_sched detected stalls on CPUs/tasks:
>> [ 139.064430] 0-...: (2 GPs behind) idle=9d5/140000000000001/0 softirq=1103/1109 fqs=2097
>> [ 139.072593] (detected by 2, t=21049 jiffies, g=64, c=63, q=11)
>> [ 139.078489] Task dump for CPU 0:
>> [ 139.081700] ksoftirqd/0 R running task 0 3 2 0x00000002
>> [ 139.088731] Call trace:
>> [ 139.091165] [<ffffff8008086b3c>] __switch_to+0xc4/0xd0
>> [ 139.096285] [<ffffffc87b830500>] 0xffffffc87b830500
>>
>>
>>>> We are not seeing any issues on 32-bit ARM platform and X86
>>>> platform.
>>> Can you collect a dmesg log (or, if the system hang means you can't
>>> collect that, a console log with "ignore_loglevel"), and "lspci -vv"
>>> output as root? That should have clues about whether the INTx got
>>> routed correctly. /proc/interrupts should also show whether we're
>>> receiving interrupts from the device.
>> Here is the lspci output:
>> 00:00.0 PCI bridge: Xilinx Corporation Device d022 (prog-if 00 [Normal decode])
>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>> Latency: 0
>> Interrupt: pin A routed to IRQ 224
>> Bus: primary=00, secondary=01, subordinate=0c, sec-latency=0
>> I/O behind bridge: 00000000-00000fff
>> Memory behind bridge: e0000000-e00fffff
>> Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
>> Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
>> BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
>> PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
>> Capabilities: [40] Power Management version 3
>> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
>> Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
>> Capabilities: [60] Express (v2) Root Port (Slot-), MSI 00
>> DevCap: MaxPayload 256 bytes, PhantFunc 0
>> ExtTag- RBE+
>> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
>> MaxPayload 128 bytes, MaxReadReq 512 bytes
>> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend+
>> LnkCap: Port #0, Speed 5GT/s, Width x2, ASPM not supported, Exit Latency L0s unlimited, L1 unlimited
>> ClockPM- Surprise- LLActRep- BwNot+ ASPMOptComp+
>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
>> RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible+
>> RootCap: CRSVisible+
>> RootSta: PME ReqID 0000, PMEStatus- PMEPending-
>> DevCap2: Completion Timeout: Range B, TimeoutDis+, LTR-, OBFF Not Supported ARIFwd-
>> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd-
>> LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
>> Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
>> Compliance De-emphasis: -6dB
>> LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1-
>> EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
>> Capabilities: [100 v1] Device Serial Number 00-00-00-00-00-00-00-00
>> Capabilities: [10c v1] Virtual Channel
>> Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
>> Arb: Fixed- WRR32- WRR64- WRR128-
>> Ctrl: ArbSelect=Fixed
>> Status: InProgress-
>> VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
>> Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
>> Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
>> Status: NegoPending- InProgress-
>> Capabilities: [128 v1] Vendor Specific Information: ID=1234 Rev=1 Len=018 <?>
>>
>> 01:00.0 Network controller: Qualcomm Atheros AR93xx Wireless Network Adapter (rev 01)
>> Subsystem: Qualcomm Atheros Device 3112
>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>> Latency: 0, Cache Line Size: 128 bytes
>> Interrupt: pin A routed to IRQ 224
>> Region 0: Memory at e0000000 (64-bit, non-prefetchable) [size=128K]
>> [virtual] Expansion ROM at e0020000 [disabled] [size=64K]
>> Capabilities: [40] Power Management version 3
>> Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA PME(D0+,D1+,D2-,D3hot+,D3cold-)
>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>> Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
>> Address: 0000000000000000 Data: 0000
>> Masking: 00000000 Pending: 00000000
>> Capabilities: [70] Express (v2) Endpoint, MSI 00
>> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <1us, L1 <8us
>> ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W
>> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
>> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
>> MaxPayload 128 bytes, MaxReadReq 512 bytes
>> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
>> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <2us, L1 <64us
>> ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
>> DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-, OBFF Not Supported
>> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
>> LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
>> Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
>> Compliance De-emphasis: -6dB
>> LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
>> EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
>> Capabilities: [100 v1] Advanced Error Reporting
>> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>> UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
>> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
>> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
>> AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
>> Capabilities: [140 v1] Virtual Channel
>> Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
>> Arb: Fixed- WRR32- WRR64- WRR128-
>> Ctrl: ArbSelect=Fixed
>> Status: InProgress-
>> VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
>> Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
>> Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
>> Status: NegoPending- InProgress-
>> Capabilities: [300 v1] Device Serial Number 00-00-00-00-00-00-00-00
>> Kernel driver in use: ath9k
>>
>> Here is the cat /proc/interrupts (after we do interface up):
>>
>> root@:~# ifconfig wlan0 up
>> [ 1548.926601] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
>> root@Xilinx-ZCU102-2016_3:~# cat /proc/interrupts
>> CPU0 CPU1 CPU2 CPU3
>> 1: 0 0 0 0 GICv2 29 Edge arch_timer
>> 2: 19873 20058 19089 17435 GICv2 30 Edge arch_timer
>> 12: 0 0 0 0 GICv2 156 Level zynqmp-dma
>> 13: 0 0 0 0 GICv2 157 Level zynqmp-dma
>> 14: 0 0 0 0 GICv2 158 Level zynqmp-dma
>> 15: 0 0 0 0 GICv2 159 Level zynqmp-dma
>> 16: 0 0 0 0 GICv2 160 Level zynqmp-dma
>> 17: 0 0 0 0 GICv2 161 Level zynqmp-dma
>> 18: 0 0 0 0 GICv2 162 Level zynqmp-dma
>> 19: 0 0 0 0 GICv2 163 Level zynqmp-dma
>> 20: 0 0 0 0 GICv2 164 Level Mali_GP_MMU, Mali_GP, Mali_PP0_MMU, Mali_PP0, Mali_PP1_MMU, Mali_PP1
>> 30: 0 0 0 0 GICv2 95 Level eth0, eth0
>> 206: 314 0 0 0 GICv2 49 Level cdns-i2c
>> 207: 40 0 0 0 GICv2 50 Level cdns-i2c
>> 209: 0 0 0 0 GICv2 150 Level nwl_pcie:misc
>> 214: 12 0 0 0 GICv2 47 Level ff0f0000.spi
>> 215: 0 0 0 0 GICv2 58 Level ffa60000.rtc
>> 216: 0 0 0 0 GICv2 59 Level ffa60000.rtc
>> 217: 0 0 0 0 GICv2 165 Level ahci-ceva[fd0c0000.ahci]
>> 218: 61 0 0 0 GICv2 81 Level mmc0
>> 219: 0 0 0 0 GICv2 187 Level arm-smmu global fault
>> 220: 471 0 0 0 GICv2 53 Level xuartps
>> 223: 0 0 0 0 GICv2 154 Level fd4c0000.dma
>> 224: 3 0 0 0 dummy 1 Edge ath9k
>> 225: 0 0 0 0 GICv2 97 Level xhci-hcd:usb1
>>
>> Regards,
>> Bharat
^ permalink raw reply
* RE: ATH9 driver issues on ARM64
From: Bharat Kumar Gogada @ 2016-12-09 14:35 UTC (permalink / raw)
To: Tobias Klausmann, Kalle Valo
Cc: Bjorn Helgaas, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, Marc Zyngier,
Janusz.Dziedzic@tieto.com, rmanohar@qti.qualcomm.com,
ath9k-devel@qca.qualcomm.com, linux-wireless@vger.kernel.org,
Kalle Valo, rmanohar@qca.qualcomm.com
In-Reply-To: <8b348550-d909-cd98-4c04-dcf37b41f1ee@mni.thm.de>
Correcting Manohar Mail ID.
> Hello there,
>=20
> as this is a thread about ath9k and ARM64, i'm not sure if i should
> answer here or not, but i have similar "stalls" with ath9k on x86_64
> (starting with 4.9rc), stack trace is posted down below where the
> original ARM64 stall traces are.
>=20
> Greetings,
>=20
> Tobias
>=20
>=20
> On 08.12.2016 18:36, Kalle Valo wrote:
> > Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com> writes:
> >
> >> > [+cc Kalle, ath9k list]
> > Thanks, but please also CC linux-wireless. Full thread below for the
> > folks there.
> >
> >>> On Thu, Dec 08, 2016 at 01:49:42PM +0000, Bharat Kumar Gogada wrote:
> >>>> Hi,
> >>>>
> >>>> Did anyone test Atheros ATH9 driver(drivers/net/wireless/ath/ath9k/)
> >>>> on ARM64. The end point is TP link wifi card with which supports
> >>>> only legacy interrupts.
> >>> If it works on other arches and the arm64 PCI enumeration works, my
> >>> first guess would be an INTx issue, e.g., maybe the driver is waiting
> >>> for an interrupt that never arrives.
> >> We are not sure for now.
> >>>> We are trying to test it on ARM64 with
> >>>> (drivers/pci/host/pcie-xilinx-nwl.c) as root port.
> >>>>
> >>>> EP is getting enumerated and able to link up.
> >>>>
> >>>> But when we start scan system gets hanged.
> >>> When you say the system hangs when you start a scan, I assume you mea=
n
> >>> a wifi scan, not the PCI enumeration. A problem with a wifi scan
> >>> might cause a *process* to hang, but it shouldn't hang the entire
> >>> system.
> >>>
> >> Yes wifi scan.
> >>>> When we took trace we see that after we start scan assert message is
> >>>> sent but there is no de assert from end point.
> >>> Are you talking about a trace from a PCIe analyzer? Do you see an
> >>> Assert_INTx PCIe message on the link?
> >>>
> >> Yes lecroy trace, yes we do see Assert_INTx and Deassert_INTx happenin=
g
> when we do interface link up.
> >> When we have less debug prints in Atheros driver, and do wifi scan we =
see
> Assert_INTx but never Deassert_INTx,
> >>>> What might cause end point not sending de assert ?
> >>> If the endpoint doesn't send a Deassert_INTx message, I expect that
> >>> would mean the driver didn't service the interrupt and remove the
> >>> condition that caused the device to assert the interrupt in the first
> >>> place.
> >>>
> >>> If the driver didn't receive the interrupt, it couldn't service it, o=
f
> >>> course. You could add a printk in the ath9k interrupt service
> >>> routine to see if you ever get there.
> >>>
> >> The interrupt behavior is changing w.r.t amount of debug prints we add=
. (I
> kept many prints to aid debug)
> >> root@Xilinx-ZCU102-2016_3:~# iw dev wlan0 scan
> >> [ 83.064675] ath9k: ath9k_iowrite32 ffffff800a400024
> >> [ 83.069486] ath9k: ath9k_ioread32 ffffff800a400024
> >> [ 83.074257] ath9k_hw_kill_interrupts 793
> >> [ 83.078260] ath9k: ath9k_iowrite32 ffffff800a400024
> >> [ 83.083107] ath9k: ath9k_ioread32 ffffff800a400024
> >> [ 83.087882] ath9k_hw_kill_interrupts 793
> >> [ 83.095450] ath9k_hw_enable_interrupts 821
> >> [ 83.099557] ath9k_hw_enable_interrupts 825
> >> [ 83.103721] ath9k_hw_enable_interrupts 832
> >> [ 83.107887] ath9k: ath9k_iowrite32 ffffff800a400024
> >> [ 83.112748] AR_SREV_9100 0
> >> [ 83.115438] ath9k_hw_enable_interrupts 848
> >> [ 83.119607] ath9k: ath9k_ioread32 ffffff800a400024
> >> [ 83.124389] ath9k_hw_intrpend 762
> >> [ 83.127761] (AR_SREV_9340(ah) val 0
> >> [ 83.131234] ath9k_hw_intrpend 767
> >> [ 83.134628] ath_isr 603
> >> [ 83.137134] ath9k: ath9k_iowrite32 ffffff800a400024
> >> [ 83.141995] ath9k: ath9k_ioread32 ffffff800a400024
> >> [ 83.146771] ath9k_hw_kill_interrupts 793
> >> [ 83.150864] ath9k_hw_enable_interrupts 821
> >> [ 83.154971] ath9k_hw_enable_interrupts 825
> >> [ 83.159135] ath9k_hw_enable_interrupts 832
> >> [ 83.163300] ath9k: ath9k_iowrite32 ffffff800a400024
> >> [ 83.168161] AR_SREV_9100 0
> >> [ 83.170852] ath9k_hw_enable_interrupts 848
> >> [ 83.170855] ath9k_hw_intrpend 762
> >> [ 83.178398] (AR_SREV_9340(ah) val 0
> >> [ 83.181873] ath9k_hw_intrpend 767
> >> [ 83.185265] ath_isr 603
> >> [ 83.187773] ath9k: ath9k_iowrite32 ffffff800a400024
> >> [ 83.192635] ath9k: ath9k_ioread32 ffffff800a400024
> >> [ 83.197411] ath9k_hw_kill_interrupts 793
> >> [ 83.201414] ath9k: ath9k_ioread32 ffffff800a400024
> >> [ 83.206258] ath9k_hw_enable_interrupts 821
> >> [ 83.210368] ath9k_hw_enable_interrupts 825
> >> [ 83.214531] ath9k_hw_enable_interrupts 832
> >> [ 83.218698] ath9k: ath9k_iowrite32 ffffff800a400024
> >> [ 83.223558] AR_SREV_9100 0
> >> [ 83.226243] ath9k_hw_enable_interrupts 848
> >> [ 83.226246] ath9k_hw_intrpend 762
> >> [ 83.233794] (AR_SREV_9340(ah) val 0
> >> [ 83.237268] ath9k_hw_intrpend 767
> >> [ 83.240661] ath_isr 603
> >> [ 83.243169] ath9k: ath9k_iowrite32 ffffff800a400024
> >> [ 83.248030] ath9k: ath9k_ioread32 ffffff800a400024
> >> [ 83.252806] ath9k_hw_kill_interrupts 793
> >> [ 83.256811] ath9k: ath9k_ioread32 ffffff800a400024
> >> [ 83.261651] ath9k_hw_enable_interrupts 821
> >> [ 83.265753] ath9k_hw_enable_interrupts 825
> >> [ 83.269919] ath9k_hw_enable_interrupts 832
> >> [ 83.274083] ath9k: ath9k_iowrite32 ffffff800a400024
> >> [ 83.278945] AR_SREV_9100 0
> >> [ 83.281630] ath9k_hw_enable_interrupts 848
> >> [ 83.281633] ath9k_hw_intrpend 762
> >> [ 83.281634] (AR_SREV_9340(ah) val 0
> >> [ 83.281637] ath9k_hw_intrpend 767
> >> [ 83.281648] ath_isr 603
> >> [ 83.281649] ath9k: ath9k_iowrite32 ffffff800a400024
> >> [ 83.281651] ath9k: ath9k_ioread32 ffffff800a400024
> >> [ 83.281654] ath9k_hw_kill_interrupts 793
> >> [ 83.312192] ath9k: ath9k_ioread32 ffffff800a400024
> >> [ 83.317030] ath9k_hw_enable_interrupts 821
> >> [ 83.321132] ath9k_hw_enable_interrupts 825
> >> [ 83.325297] ath9k_hw_enable_interrupts 832
> >> [ 83.329463] ath9k: ath9k_iowrite32 ffffff800a400024
> >> [ 83.334324] AR_SREV_9100 0
> >> [ 83.337014] ath9k_hw_enable_interrupts 848
> >> ..
> >> ..
> >> This log continues until I turn off board without obtaining scanning r=
esult.
> >>
> >> In between I get following cpu stall outputs :
> >> 230.457179] INFO: rcu_sched self-detected stall on CPU
> >> [ 230.457185] 2-...: (31314 ticks this GP)
> idle=3D2d1/140000000000001/0 softirq=3D1400/1400 fqs=3D36713
> >> [ 230.457189] (t=3D36756 jiffies g=3D161 c=3D160 q=3D16169)
> >> [ 230.457191] Task dump for CPU 2:
> >> [ 230.457196] kworker/u8:4 R running task 0 1342 2 0=
x00000002
> >> [ 230.457207] Workqueue: phy0 ieee80211_scan_work
> >> [ 230.457208] Call trace:
> >> [ 230.457214] [<ffffff8008089860>] dump_backtrace+0x0/0x198
> >> [ 230.457219] [<ffffff8008089a0c>] show_stack+0x14/0x20
> >> [ 230.457224] [<ffffff80080c0930>] sched_show_task+0x98/0xf8
> >> [ 230.457228] [<ffffff80080c2628>] dump_cpu_task+0x40/0x50
> >> [ 230.457233] [<ffffff80080e14a8>] rcu_dump_cpu_stacks+0xa0/0xf0
> >> [ 230.457239] [<ffffff80080e4cd8>] rcu_check_callbacks+0x468/0x748
> >> [ 230.457243] [<ffffff80080e7cfc>] update_process_times+0x3c/0x68
> >> [ 230.457249] [<ffffff80080f6dfc>] tick_sched_handle.isra.5+0x3c/0x50
> >> [ 230.457253] [<ffffff80080f6e54>] tick_sched_timer+0x44/0x90
> >> [ 230.457257] [<ffffff80080e86b0>] __hrtimer_run_queues+0xf0/0x178
> >> ** 10 printk messages dropped ** [ 230.457302] f8c0: 0000000000000000
> 0000000005f5e0ff 000000000001379a 3866666666666620
> >> [ 230.457306] f8e0: ffffff800a1b4065 0000000000000006 ffffff800a12900=
0
> ffffffc87b8010a8
> >> [ 230.457310] f900: ffffff808a1b4057 ffffff800a1c3000 ffffff800a1b300=
0
> ffffff800a13b000
> >> [ 230.457314] f920: 0000000000000140 0000000000000006
> ffffff800a1b3b10 ffffff800a1c39e8
> >> [ 230.457318] f940: 000000000000002f ffffff800a1b8a98 ffffff800a1b3ae=
8
> ffffffc87b07f990
> >> [ 230.457322] f960: ffffff80080d6230 ffffffc87b07f990 ffffff80080d623=
4
> 0000000060000145
> >> ** 1 printk messages dropped ** [ 230.457329] [<ffffff8008085720>]
> el1_irq+0xa0/0x100
> >> ** 9 printk messages dropped ** [ 230.457373] [<ffffff800885ad60>]
> ieee80211_hw_config+0x50/0x290
> >> [ 230.457377] [<ffffff8008863690>] ieee80211_scan_work+0x1f8/0x480
> >> [ 230.457383] [<ffffff80080b15d0>] process_one_work+0x120/0x378
> >> [ 230.457386] [<ffffff80080b1870>] worker_thread+0x48/0x4b0
> >> [ 230.457391] [<ffffff80080b7108>] kthread+0xd0/0xe8
> >> [ 230.457395] [<ffffff8008085dd0>] ret_from_fork+0x10/0x40
> >> [ 230.480389] ath9k_hw_intrpend 762
> >>
> >>
> >> [ 545.487987] ath9k: ath9k_ioread32 ffffff800a400024
> >> [ 545.526189] INFO: rcu_sched self-detected stall on CPU
> >> [ 545.526195] 2-...: (97636 ticks this GP)
> idle=3D2d1/140000000000001/0 softirq=3D1400/1400 fqs=3D115374
> >> [ 545.526199] (t=3D115523 jiffies g=3D161 c=3D160 q=3D51066)
> >> [ 545.526201] Task dump for CPU 2:
> >> [ 545.526206] kworker/u8:4 R running task 0 1342 2 0=
x00000002
> >> ** 3 printk messages dropped ** [ 545.526231] [<ffffff8008089a0c>]
> show_stack+0x14/0x20
> >> ** 9 printk messages dropped ** [ 545.526280] [<ffffff80086a71e8>]
> arch_timer_handler_phys+0x30/0x40
> >> [ 545.526284] [<ffffff80080dbe18>] handle_percpu_devid_irq+0x78/0xa0
> >> [ 545.526291] [<ffffff80080d760c>] generic_handle_irq+0x24/0x38
> >> [ 545.526296] [<ffffff80080d7944>] __handle_domain_irq+0x5c/0xb8
> >> [ 545.526299] [<ffffff80080824bc>] gic_handle_irq+0x64/0xc0
> >> [ 545.526302] Exception stack(0xffffffc87b07f870 to 0xffffffc87b07f99=
0)
> >> [ 545.526306] f860: 000000000000973=
2 ffffff800a1eaaa8
> >> ** 8 printk messages dropped ** [ 545.526341] f980: ffffff800a1c39e8
> 0000000000000036
> >> [ 545.526345] [<ffffff8008085720>] el1_irq+0xa0/0x100
> >> [ 545.526349] [<ffffff80080d6234>] console_unlock+0x384/0x5b0
> >> [ 545.526353] [<ffffff80080d673c>] vprintk_emit+0x2dc/0x4b0
> >> [ 545.526357] [<ffffff80080d6a50>] vprintk_default+0x38/0x40
> >> [ 545.526362] [<ffffff8008129704>] printk+0x58/0x60
> >> [ 545.526366] [<ffffff800859e3e4>] ath9k_iowrite32+0x9c/0xa8
> >> [ 545.526372] [<ffffff80085c7ca8>] ath9k_hw_kill_interrupts+0x28/0xf0
> >> [ 545.526376] [<ffffff80085a18ec>] ath_reset+0x24/0x68
> >> ** 2 printk messages dropped ** [ 545.526391] [<ffffff800885ad60>]
> ieee80211_hw_config+0x50/0x290
> >> ** 11 printk messages dropped ** [ 545.532834] ath9k_hw_kill_interrup=
ts
> 793
> >> [ 545.532890] ath9k_hw_enable_interrupts 821
>=20
> [ 81.876902] INFO: rcu_preempt detected stalls on CPUs/tasks:
> [ 81.876912] Tasks blocked on level-0 rcu_node (CPUs 0-7): P0
> [ 81.876932] (detected by 4, t=3D60002 jiffies, g=3D1873, c=3D1872,=
q=3D4967)
> [ 81.876936] swapper/4 R running task 0 0 1
> 0x00000000
> [ 81.876941] 0000000000000001 ffffffff810725f6 ffff88017edbc240
> ffffffff81a3dc40
> [ 81.876945] ffffffff81101e46 ffff88025ef173c0 ffffffff81a3dc40
> ffffffff81a3dc40
> [ 81.876948] 00000000ffffffff ffffffff810a7333 ffff88017ecee698
> ffff88017edbc240
> [ 81.876951] Call Trace:
> [ 81.876970] <IRQ>
> [ 81.876979] [<ffffffff810725f6>] ? sched_show_task+0xd6/0x140
> [ 81.876983] [<ffffffff81101e46>] ?
> rcu_print_detail_task_stall_rnp+0x40/0x61
> [ 81.876989] [<ffffffff810a7333>] ? rcu_check_callbacks+0x6b3/0x8c0
> [ 81.876993] [<ffffffff810b8350>] ? tick_sched_handle.isra.14+0x40/0x4=
0
> [ 81.876996] [<ffffffff810aa4c3>] ? update_process_times+0x23/0x50
> [ 81.876999] [<ffffffff810b8383>] ? tick_sched_timer+0x33/0x60
> [ 81.877002] [<ffffffff810aaf09>] ? __hrtimer_run_queues+0xb9/0x150
> [ 81.877004] [<ffffffff810ab198>] ? hrtimer_interrupt+0x98/0x1a0
> [ 81.877008] [<ffffffff81031b1e>] ?
> smp_trace_apic_timer_interrupt+0x5e/0x90
> [ 81.877012] [<ffffffff815b31bf>] ? apic_timer_interrupt+0x7f/0x90
> [ 81.877013] <EOI>
> [ 81.877017] [<ffffffff8147f28d>] ? cpuidle_enter_state+0x13d/0x1f0
> [ 81.877019] [<ffffffff8147f289>] ? cpuidle_enter_state+0x139/0x1f0
> [ 81.877021] [<ffffffff81088c19>] ? cpu_startup_entry+0x139/0x210
> [ 81.877027] [<ffffffff8102fc9e>] ? start_secondary+0x13e/0x170
> [ 81.877029] swapper/4 R running task 0 0 1
> 0x00000000
> [ 81.877032] 0000000000000001 ffffffff810725f6 ffff88017edbc240
> ffffffff81a3dc40
> [ 81.877035] ffffffff81101e46 ffff88025ef173c0 ffffffff81a3dc40
> ffffffff81a3dc40
> [ 81.877038] 00000000ffffffff ffffffff810a7368 ffff88017ecee698
> ffff88017edbc240
> [ 81.877041] Call Trace:
> [ 81.877045] <IRQ>
> [ 81.877049] [<ffffffff810725f6>] ? sched_show_task+0xd6/0x140
> [ 81.877051] [<ffffffff81101e46>] ?
> rcu_print_detail_task_stall_rnp+0x40/0x61
> [ 81.877055] [<ffffffff810a7368>] ? rcu_check_callbacks+0x6e8/0x8c0
> [ 81.877058] [<ffffffff810b8350>] ? tick_sched_handle.isra.14+0x40/0x4=
0
> [ 81.877060] [<ffffffff810aa4c3>] ? update_process_times+0x23/0x50
> [ 81.877063] [<ffffffff810b8383>] ? tick_sched_timer+0x33/0x60
> [ 81.877065] [<ffffffff810aaf09>] ? __hrtimer_run_queues+0xb9/0x150
> [ 81.877068] [<ffffffff810ab198>] ? hrtimer_interrupt+0x98/0x1a0
> [ 81.877070] [<ffffffff81031b1e>] ?
> smp_trace_apic_timer_interrupt+0x5e/0x90
> [ 81.877073] [<ffffffff815b31bf>] ? apic_timer_interrupt+0x7f/0x90
> [ 81.877074] <EOI>
> [ 81.877076] [<ffffffff8147f28d>] ? cpuidle_enter_state+0x13d/0x1f0
> [ 81.877078] [<ffffffff8147f289>] ? cpuidle_enter_state+0x139/0x1f0
> [ 81.877080] [<ffffffff81088c19>] ? cpu_startup_entry+0x139/0x210
> [ 81.877084] [<ffffffff8102fc9e>] ? start_secondary+0x13e/0x170
> [ 91.132787] INFO: rcu_preempt detected expedited stalls on
> CPUs/tasks: { P0 } 63785 jiffies s: 505 root: 0x0/T
> [ 91.132796] blocking rcu_node structures:
>=20
> >>
> >>
> >> But if we have less debug prints it does not reach EP handler sometime=
s, due
> to following
> >> Condition in "kernel/irq/chip.c" in function handle_simple_irq
> >>
> >> if (unlikely(!desc->action || irqd_irq_disabled(&desc->irq_data))) {
> >> desc->istate |=3D IRQS_PENDING;
> >> goto out_unlock;
> >> }
> >> Here irqd_irq_disabled is being set to 1.
> >>
> >> With lesser debug prints it stops after following prints:
> >> root@Xilinx-ZCU102-2016_3:~# iw dev wlan0 scan
> >> [ 54.781045] ath9k_hw_kill_interrupts 793
> >> [ 54.785007] ath9k_hw_kill_interrupts 793
> >> [ 54.792535] ath9k_hw_enable_interrupts 821
> >> [ 54.796642] ath9k_hw_enable_interrupts 825
> >> [ 54.800807] ath9k_hw_enable_interrupts 832
> >> [ 54.804973] AR_SREV_9100 0
> >> [ 54.807663] ath9k_hw_enable_interrupts 848
> >> [ 54.811843] ath9k_hw_intrpend 762
> >> [ 54.815211] (AR_SREV_9340(ah) val 0
> >> [ 54.818684] ath9k_hw_intrpend 767
> >> [ 54.822078] ath_isr 603
> >> [ 54.824587] ath9k_hw_kill_interrupts 793
> >> [ 54.828601] ath9k_hw_enable_interrupts 821
> >> [ 54.832750] ath9k_hw_enable_interrupts 825
> >> [ 54.836916] ath9k_hw_enable_interrupts 832
> >> [ 54.841082] AR_SREV_9100 0
> >> [ 54.843772] ath9k_hw_enable_interrupts 848
> >> [ 54.843775] ath9k_hw_intrpend 762
> >> [ 54.851319] (AR_SREV_9340(ah) val 0
> >> [ 54.854793] ath9k_hw_intrpend 767
> >> [ 54.858185] ath_isr 603
> >> [ 54.860696] ath9k_hw_kill_interrupts 793
> >> [ 54.864776] ath9k_hw_enable_interrupts 821
> >> [ 54.867061] ath9k_hw_kill_interrupts 793
> >> [ 54.872870] ath9k_hw_enable_interrupts 825
> >> [ 54.877036] ath9k_hw_enable_interrupts 832
> >> [ 54.881202] AR_SREV_9100 0
> >> [ 54.883892] ath9k_hw_enable_interrupts 848
> >> [ 75.963129] INFO: rcu_sched detected stalls on CPUs/tasks:
> >> [ 75.968602] 0-...: (2 GPs behind) idle=3D9d5/140000000000001/0
> softirq=3D1103/1109 fqs=3D519
> >> [ 75.976675] (detected by 2, t=3D5274 jiffies, g=3D64, c=3D63, q=3D=
11)
> >> [ 75.982485] Task dump for CPU 0:
> >> [ 75.985696] ksoftirqd/0 R running task 0 3 2 0=
x00000002
> >> [ 75.992726] Call trace:
> >> [ 75.995165] [<ffffff8008086b3c>] __switch_to+0xc4/0xd0
> >> [ 76.000281] [<ffffffc87b830500>] 0xffffffc87b830500
> >> [ 139.059027] INFO: rcu_sched detected stalls on CPUs/tasks:
> >> [ 139.064430] 0-...: (2 GPs behind) idle=3D9d5/140000000000001/0
> softirq=3D1103/1109 fqs=3D2097
> >> [ 139.072593] (detected by 2, t=3D21049 jiffies, g=3D64, c=3D63, q=
=3D11)
> >> [ 139.078489] Task dump for CPU 0:
> >> [ 139.081700] ksoftirqd/0 R running task 0 3 2 0=
x00000002
> >> [ 139.088731] Call trace:
> >> [ 139.091165] [<ffffff8008086b3c>] __switch_to+0xc4/0xd0
> >> [ 139.096285] [<ffffffc87b830500>] 0xffffffc87b830500
> >>
> >>
> >>>> We are not seeing any issues on 32-bit ARM platform and X86
> >>>> platform.
> >>> Can you collect a dmesg log (or, if the system hang means you can't
> >>> collect that, a console log with "ignore_loglevel"), and "lspci -vv"
> >>> output as root? That should have clues about whether the INTx got
> >>> routed correctly. /proc/interrupts should also show whether we're
> >>> receiving interrupts from the device.
> >> Here is the lspci output:
> >> 00:00.0 PCI bridge: Xilinx Corporation Device d022 (prog-if 00 [Normal
> decode])
> >> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx-
> >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> >> Latency: 0
> >> Interrupt: pin A routed to IRQ 224
> >> Bus: primary=3D00, secondary=3D01, subordinate=3D0c, sec-latency=3D0
> >> I/O behind bridge: 00000000-00000fff
> >> Memory behind bridge: e0000000-e00fffff
> >> Prefetchable memory behind bridge: 00000000fff00000-
> 00000000000fffff
> >> Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=3Dfast >TAbort-
> <TAbort- <MAbort- <SERR- <PERR-
> >> BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
> >> PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
> >> Capabilities: [40] Power Management version 3
> >> Flags: PMEClk- DSI- D1- D2- AuxCurrent=3D0mA
> PME(D0+,D1+,D2+,D3hot+,D3cold-)
> >> Status: D0 NoSoftRst+ PME-Enable- DSel=3D0 DScale=3D0 PME-
> >> Capabilities: [60] Express (v2) Root Port (Slot-), MSI 00
> >> DevCap: MaxPayload 256 bytes, PhantFunc 0
> >> ExtTag- RBE+
> >> DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> Unsupported-
> >> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
> >> MaxPayload 128 bytes, MaxReadReq 512 bytes
> >> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr-
> TransPend+
> >> LnkCap: Port #0, Speed 5GT/s, Width x2, ASPM not supported,
> Exit Latency L0s unlimited, L1 unlimited
> >> ClockPM- Surprise- LLActRep- BwNot+ ASPMOptComp+
> >> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
> >> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> >> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
> DLActive- BWMgmt- ABWMgmt-
> >> RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna-
> CRSVisible+
> >> RootCap: CRSVisible+
> >> RootSta: PME ReqID 0000, PMEStatus- PMEPending-
> >> DevCap2: Completion Timeout: Range B, TimeoutDis+, LTR-,
> OBFF Not Supported ARIFwd-
> >> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-,
> OBFF Disabled ARIFwd-
> >> LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
> >> Transmit Margin: Normal Operating Range,
> EnterModifiedCompliance- ComplianceSOS-
> >> Compliance De-emphasis: -6dB
> >> LnkSta2: Current De-emphasis Level: -3.5dB,
> EqualizationComplete-, EqualizationPhase1-
> >> EqualizationPhase2-, EqualizationPhase3-,
> LinkEqualizationRequest-
> >> Capabilities: [100 v1] Device Serial Number 00-00-00-00-00-00-00-00
> >> Capabilities: [10c v1] Virtual Channel
> >> Caps: LPEVC=3D0 RefClk=3D100ns PATEntryBits=3D1
> >> Arb: Fixed- WRR32- WRR64- WRR128-
> >> Ctrl: ArbSelect=3DFixed
> >> Status: InProgress-
> >> VC0: Caps: PATOffset=3D00 MaxTimeSlots=3D1 RejSnoopTrans-
> >> Arb: Fixed- WRR32- WRR64- WRR128- TWRR128-
> WRR256-
> >> Ctrl: Enable+ ID=3D0 ArbSelect=3DFixed TC/VC=3Dff
> >> Status: NegoPending- InProgress-
> >> Capabilities: [128 v1] Vendor Specific Information: ID=3D1234 Rev=3D1
> Len=3D018 <?>
> >>
> >> 01:00.0 Network controller: Qualcomm Atheros AR93xx Wireless Network
> Adapter (rev 01)
> >> Subsystem: Qualcomm Atheros Device 3112
> >> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx-
> >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> >> Latency: 0, Cache Line Size: 128 bytes
> >> Interrupt: pin A routed to IRQ 224
> >> Region 0: Memory at e0000000 (64-bit, non-prefetchable) [size=3D128K]
> >> [virtual] Expansion ROM at e0020000 [disabled] [size=3D64K]
> >> Capabilities: [40] Power Management version 3
> >> Flags: PMEClk- DSI- D1+ D2- AuxCurrent=3D375mA
> PME(D0+,D1+,D2-,D3hot+,D3cold-)
> >> Status: D0 NoSoftRst- PME-Enable- DSel=3D0 DScale=3D0 PME-
> >> Capabilities: [50] MSI: Enable- Count=3D1/4 Maskable+ 64bit+
> >> Address: 0000000000000000 Data: 0000
> >> Masking: 00000000 Pending: 00000000
> >> Capabilities: [70] Express (v2) Endpoint, MSI 00
> >> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency
> L0s <1us, L1 <8us
> >> ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
> SlotPowerLimit 0.000W
> >> DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> Unsupported-
> >> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
> >> MaxPayload 128 bytes, MaxReadReq 512 bytes
> >> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr-
> TransPend-
> >> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit
> Latency L0s <2us, L1 <64us
> >> ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
> >> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
> >> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> >> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
> DLActive- BWMgmt- ABWMgmt-
> >> DevCap2: Completion Timeout: Not Supported, TimeoutDis+,
> LTR-, OBFF Not Supported
> >> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-,
> OBFF Disabled
> >> LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance-
> SpeedDis-
> >> Transmit Margin: Normal Operating Range,
> EnterModifiedCompliance- ComplianceSOS-
> >> Compliance De-emphasis: -6dB
> >> LnkSta2: Current De-emphasis Level: -6dB,
> EqualizationComplete-, EqualizationPhase1-
> >> EqualizationPhase2-, EqualizationPhase3-,
> LinkEqualizationRequest-
> >> Capabilities: [100 v1] Advanced Error Reporting
> >> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> >> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> >> UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt-
> RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
> >> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
> NonFatalErr-
> >> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
> NonFatalErr+
> >> AERCap: First Error Pointer: 00, GenCap- CGenEn-
> ChkCap- ChkEn-
> >> Capabilities: [140 v1] Virtual Channel
> >> Caps: LPEVC=3D0 RefClk=3D100ns PATEntryBits=3D1
> >> Arb: Fixed- WRR32- WRR64- WRR128-
> >> Ctrl: ArbSelect=3DFixed
> >> Status: InProgress-
> >> VC0: Caps: PATOffset=3D00 MaxTimeSlots=3D1 RejSnoopTrans-
> >> Arb: Fixed- WRR32- WRR64- WRR128- TWRR128-
> WRR256-
> >> Ctrl: Enable+ ID=3D0 ArbSelect=3DFixed TC/VC=3Dff
> >> Status: NegoPending- InProgress-
> >> Capabilities: [300 v1] Device Serial Number 00-00-00-00-00-00-00-00
> >> Kernel driver in use: ath9k
> >>
> >> Here is the cat /proc/interrupts (after we do interface up):
> >>
> >> root@:~# ifconfig wlan0 up
> >> [ 1548.926601] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> >> root@Xilinx-ZCU102-2016_3:~# cat /proc/interrupts
> >> CPU0 CPU1 CPU2 CPU3
> >> 1: 0 0 0 0 GICv2 29 Edge =
arch_timer
> >> 2: 19873 20058 19089 17435 GICv2 30 Edge =
arch_timer
> >> 12: 0 0 0 0 GICv2 156 Level =
zynqmp-dma
> >> 13: 0 0 0 0 GICv2 157 Level =
zynqmp-dma
> >> 14: 0 0 0 0 GICv2 158 Level =
zynqmp-dma
> >> 15: 0 0 0 0 GICv2 159 Level =
zynqmp-dma
> >> 16: 0 0 0 0 GICv2 160 Level =
zynqmp-dma
> >> 17: 0 0 0 0 GICv2 161 Level =
zynqmp-dma
> >> 18: 0 0 0 0 GICv2 162 Level =
zynqmp-dma
> >> 19: 0 0 0 0 GICv2 163 Level =
zynqmp-dma
> >> 20: 0 0 0 0 GICv2 164 Level =
Mali_GP_MMU,
> Mali_GP, Mali_PP0_MMU, Mali_PP0, Mali_PP1_MMU, Mali_PP1
> >> 30: 0 0 0 0 GICv2 95 Level =
eth0, eth0
> >> 206: 314 0 0 0 GICv2 49 Level =
cdns-i2c
> >> 207: 40 0 0 0 GICv2 50 Level =
cdns-i2c
> >> 209: 0 0 0 0 GICv2 150 Level =
nwl_pcie:misc
> >> 214: 12 0 0 0 GICv2 47 Level =
ff0f0000.spi
> >> 215: 0 0 0 0 GICv2 58 Level =
ffa60000.rtc
> >> 216: 0 0 0 0 GICv2 59 Level =
ffa60000.rtc
> >> 217: 0 0 0 0 GICv2 165 Level =
ahci-
> ceva[fd0c0000.ahci]
> >> 218: 61 0 0 0 GICv2 81 Level =
mmc0
> >> 219: 0 0 0 0 GICv2 187 Level =
arm-smmu global fault
> >> 220: 471 0 0 0 GICv2 53 Level =
xuartps
> >> 223: 0 0 0 0 GICv2 154 Level =
fd4c0000.dma
> >> 224: 3 0 0 0 dummy 1 Edge =
ath9k
> >> 225: 0 0 0 0 GICv2 97 Level =
xhci-hcd:usb1
> >>
> >> Regards,
> >> Bharat
^ permalink raw reply
* Re: [PATCH 10/14] rtlwifi: Add BTC_TRACE_STRING to new btcoex
From: Markus Böhme @ 2016-12-09 23:56 UTC (permalink / raw)
To: Kalle Valo, Dan Carpenter
Cc: devel, Ping-Ke Shih, linux-wireless, Larry Finger
In-Reply-To: <87vaut32qd.fsf@kamboji.qca.qualcomm.com>
On 12/09/2016 09:50 AM, Kalle Valo wrote:
> Dan Carpenter <dan.carpenter@oracle.com> writes:
>
>> On Thu, Dec 08, 2016 at 02:50:49PM +0300, Dan Carpenter wrote:
>>> On Thu, Dec 08, 2016 at 01:43:42PM +0200, Kalle Valo wrote:
>>>> But it would make me very happy if someone would add a similar grouping
>>>> functionality to dyndbg to make it easy to enable a set of debug
>>>> messages in a driver.
>>>
>>> Thats seems like a reasonable thing as well.
>>
>> I actually like the ath code... We could easily change it to be more
>> generic and make it a top level function for everyone to use.
>
> That would be great. And maybe add a sysfs file with a description
> different levels, like module parameters have. Too bad that I can't work
> on that, too much stuff on my plate right now.
>
In this case I would like to step in and try to implement grouping of
messages in the dynamic debug code. This seems to be an interesting
learning opportunity.
Regards,
Markus
^ permalink raw reply
* Re: pull-request: mac80211-next 2016-12-09
From: David Miller @ 2016-12-10 3:59 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20161209120014.20292-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Fri, 9 Dec 2016 13:00:13 +0100
> Closing net-next caught me by surprise, so I had to rebase a bit,
> but these three patches really should go in soon. I'm not sending
> them for 4.9 this late though.
>
> Please pull and let me know if there's any problem.
Pulled, thanks Johannes.
^ permalink raw reply
* Re: [PATCH 10/14] rtlwifi: Add BTC_TRACE_STRING to new btcoex
From: Joe Perches @ 2016-12-10 6:39 UTC (permalink / raw)
To: Markus Böhme, Kalle Valo, Dan Carpenter
Cc: devel, Ping-Ke Shih, linux-wireless, Larry Finger
In-Reply-To: <77555ffb-de05-2837-2e13-aaf4ec710fc3@mailbox.org>
On Sat, 2016-12-10 at 00:56 +0100, Markus Böhme wrote:
> On 12/09/2016 09:50 AM, Kalle Valo wrote:
> > Dan Carpenter <dan.carpenter@oracle.com> writes:
> >
> > > On Thu, Dec 08, 2016 at 02:50:49PM +0300, Dan Carpenter wrote:
> > > > On Thu, Dec 08, 2016 at 01:43:42PM +0200, Kalle Valo wrote:
> > > > > But it would make me very happy if someone would add a similar grouping
> > > > > functionality to dyndbg to make it easy to enable a set of debug
> > > > > messages in a driver.
> > > >
> > > > Thats seems like a reasonable thing as well.
> > >
> > > I actually like the ath code... We could easily change it to be more
> > > generic and make it a top level function for everyone to use.
> >
> > That would be great. And maybe add a sysfs file with a description
> > different levels, like module parameters have. Too bad that I can't work
> > on that, too much stuff on my plate right now.
> >
>
> In this case I would like to step in and try to implement grouping of
> messages in the dynamic debug code. This seems to be an interesting
> learning opportunity.
Use bitmaps and levels.
^ permalink raw reply
* [PATCH 1/2] ath10k: htc: Removal of unused struct members
From: Erik Stromdahl @ 2016-12-10 12:58 UTC (permalink / raw)
To: kvalo, linux-wireless, ath10k; +Cc: Erik Stromdahl
Removed tx_credits_per_max_message and tx_credit_size
from struct ath10k_htc_ep since they are not used
anywhere in the code.
They are just written, never read.
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
---
drivers/net/wireless/ath/ath10k/htc.c | 6 ------
drivers/net/wireless/ath/ath10k/htc.h | 2 --
2 files changed, 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htc.c b/drivers/net/wireless/ath/ath10k/htc.c
index 175aae3..f2e0659 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -726,12 +726,6 @@ int ath10k_htc_connect_service(struct ath10k_htc *htc,
ep->max_tx_queue_depth = conn_req->max_send_queue_depth;
ep->max_ep_message_len = __le16_to_cpu(resp_msg->max_msg_size);
ep->tx_credits = tx_alloc;
- ep->tx_credit_size = htc->target_credit_size;
- ep->tx_credits_per_max_message = ep->max_ep_message_len /
- htc->target_credit_size;
-
- if (ep->max_ep_message_len % htc->target_credit_size)
- ep->tx_credits_per_max_message++;
/* copy all the callbacks */
ep->ep_ops = conn_req->ep_ops;
diff --git a/drivers/net/wireless/ath/ath10k/htc.h b/drivers/net/wireless/ath/ath10k/htc.h
index 0c55cd9..ca150c9 100644
--- a/drivers/net/wireless/ath/ath10k/htc.h
+++ b/drivers/net/wireless/ath/ath10k/htc.h
@@ -314,8 +314,6 @@ struct ath10k_htc_ep {
u8 seq_no; /* for debugging */
int tx_credits;
- int tx_credit_size;
- int tx_credits_per_max_message;
bool tx_credit_flow_enabled;
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] ath10k: htc: Simplified credit distribution.
From: Erik Stromdahl @ 2016-12-10 12:58 UTC (permalink / raw)
To: kvalo, linux-wireless, ath10k; +Cc: Erik Stromdahl
In-Reply-To: <1481374721-16354-1-git-send-email-erik.stromdahl@gmail.com>
Simplified transmit credit distribution code somewhat.
Since the WMI control service will get assigned all credits
there is no need for having a credit_allocation array in
struct ath10k_htc.
Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
---
drivers/net/wireless/ath/ath10k/htc.c | 29 +++++------------------------
drivers/net/wireless/ath/ath10k/htc.h | 1 -
2 files changed, 5 insertions(+), 25 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htc.c b/drivers/net/wireless/ath/ath10k/htc.c
index f2e0659..9f6a915 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -474,33 +474,16 @@ static void ath10k_htc_reset_endpoint_states(struct ath10k_htc *htc)
}
}
-static void ath10k_htc_setup_target_buffer_assignments(struct ath10k_htc *htc)
-{
- struct ath10k_htc_svc_tx_credits *entry;
-
- entry = &htc->service_tx_alloc[0];
-
- /*
- * for PCIE allocate all credists/HTC buffers to WMI.
- * no buffers are used/required for data. data always
- * remains on host.
- */
- entry++;
- entry->service_id = ATH10K_HTC_SVC_ID_WMI_CONTROL;
- entry->credit_allocation = htc->total_transmit_credits;
-}
-
static u8 ath10k_htc_get_credit_allocation(struct ath10k_htc *htc,
u16 service_id)
{
u8 allocation = 0;
- int i;
- for (i = 0; i < ATH10K_HTC_EP_COUNT; i++) {
- if (htc->service_tx_alloc[i].service_id == service_id)
- allocation =
- htc->service_tx_alloc[i].credit_allocation;
- }
+ /* The WMI control service is the only service with flow control.
+ * Let it have all transmit credits.
+ */
+ if (service_id == ATH10K_HTC_SVC_ID_WMI_CONTROL)
+ allocation = htc->total_transmit_credits;
return allocation;
}
@@ -574,8 +557,6 @@ int ath10k_htc_wait_target(struct ath10k_htc *htc)
return -ECOMM;
}
- ath10k_htc_setup_target_buffer_assignments(htc);
-
/* setup our pseudo HTC control endpoint connection */
memset(&conn_req, 0, sizeof(conn_req));
memset(&conn_resp, 0, sizeof(conn_resp));
diff --git a/drivers/net/wireless/ath/ath10k/htc.h b/drivers/net/wireless/ath/ath10k/htc.h
index ca150c9..6ababa3 100644
--- a/drivers/net/wireless/ath/ath10k/htc.h
+++ b/drivers/net/wireless/ath/ath10k/htc.h
@@ -337,7 +337,6 @@ struct ath10k_htc {
struct completion ctl_resp;
int total_transmit_credits;
- struct ath10k_htc_svc_tx_credits service_tx_alloc[ATH10K_HTC_EP_COUNT];
int target_credit_size;
};
--
1.7.9.5
^ permalink raw reply related
* RE: ATH9 driver issues on ARM64
From: Bharat Kumar Gogada @ 2016-12-10 14:40 UTC (permalink / raw)
To: Tobias Klausmann, Kalle Valo
Cc: Bjorn Helgaas, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, Marc Zyngier,
Janusz.Dziedzic@tieto.com, rmanohar@qti.qualcomm.com,
ath9k-devel@qca.qualcomm.com, linux-wireless@vger.kernel.org
In-Reply-To: <8b348550-d909-cd98-4c04-dcf37b41f1ee@mni.thm.de>
Hi,
After taking some more lecroy traces, we see that after 2nd ASSERT from EP =
on ARM64 we see continuous data movement of 32 dwords or 12 dwords and neve=
r sign of DEASSERT.
Comparatively on working traces (x86) after 2nd assert there are only BAR r=
egister reads and writes and then DEASSERT, for almost most of the interrup=
ts and we haven't seen 12 or 32 dwords data movement on this trace.
I did not work on EP wifi/network drivers, any help why EP needs those many=
number of data at scan time ?
Regards,
Bharat
=20
> Hello there,
>=20
> as this is a thread about ath9k and ARM64, i'm not sure if i should answe=
r here
> or not, but i have similar "stalls" with ath9k on x86_64 (starting with 4=
.9rc), stack
> trace is posted down below where the original ARM64 stall traces are.
>=20
> Greetings,
>=20
> Tobias
>=20
>=20
> On 08.12.2016 18:36, Kalle Valo wrote:
> > Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com> writes:
> >
> >> > [+cc Kalle, ath9k list]
> > Thanks, but please also CC linux-wireless. Full thread below for the
> > folks there.
> >
> >>> On Thu, Dec 08, 2016 at 01:49:42PM +0000, Bharat Kumar Gogada wrote:
> >>>> Hi,
> >>>>
> >>>> Did anyone test Atheros ATH9
> >>>> driver(drivers/net/wireless/ath/ath9k/)
> >>>> on ARM64. The end point is TP link wifi card with which supports
> >>>> only legacy interrupts.
> >>> If it works on other arches and the arm64 PCI enumeration works, my
> >>> first guess would be an INTx issue, e.g., maybe the driver is
> >>> waiting for an interrupt that never arrives.
> >> We are not sure for now.
> >>>> We are trying to test it on ARM64 with
> >>>> (drivers/pci/host/pcie-xilinx-nwl.c) as root port.
> >>>>
> >>>> EP is getting enumerated and able to link up.
> >>>>
> >>>> But when we start scan system gets hanged.
> >>> When you say the system hangs when you start a scan, I assume you
> >>> mean a wifi scan, not the PCI enumeration. A problem with a wifi
> >>> scan might cause a *process* to hang, but it shouldn't hang the
> >>> entire system.
> >>>
> >> Yes wifi scan.
> >>>> When we took trace we see that after we start scan assert message
> >>>> is sent but there is no de assert from end point.
> >>> Are you talking about a trace from a PCIe analyzer? Do you see an
> >>> Assert_INTx PCIe message on the link?
> >>>
> >> Yes lecroy trace, yes we do see Assert_INTx and Deassert_INTx happenin=
g
> when we do interface link up.
> >> When we have less debug prints in Atheros driver, and do wifi scan we
> >> see Assert_INTx but never Deassert_INTx,
> >>>> What might cause end point not sending de assert ?
> >>> If the endpoint doesn't send a Deassert_INTx message, I expect that
> >>> would mean the driver didn't service the interrupt and remove the
> >>> condition that caused the device to assert the interrupt in the
> >>> first place.
> >>>
> >>> If the driver didn't receive the interrupt, it couldn't service it,
> >>> of course. You could add a printk in the ath9k interrupt service
> >>> routine to see if you ever get there.
> >>>
> >> The interrupt behavior is changing w.r.t amount of debug prints we
> >> add. (I kept many prints to aid debug) root@Xilinx-ZCU102-2016_3:~# iw=
dev
> wlan0 scan
> >> [ 83.064675] ath9k: ath9k_iowrite32 ffffff800a400024
> >> [ 83.069486] ath9k: ath9k_ioread32 ffffff800a400024
> >> [ 83.074257] ath9k_hw_kill_interrupts 793
> >> [ 83.078260] ath9k: ath9k_iowrite32 ffffff800a400024
> >> [ 83.083107] ath9k: ath9k_ioread32 ffffff800a400024
> >> [ 83.087882] ath9k_hw_kill_interrupts 793
> >> [ 83.095450] ath9k_hw_enable_interrupts 821
> >> [ 83.099557] ath9k_hw_enable_interrupts 825
> >> [ 83.103721] ath9k_hw_enable_interrupts 832
> >> [ 83.107887] ath9k: ath9k_iowrite32 ffffff800a400024
> >> [ 83.112748] AR_SREV_9100 0
> >> [ 83.115438] ath9k_hw_enable_interrupts 848
> >> [ 83.119607] ath9k: ath9k_ioread32 ffffff800a400024
> >> [ 83.124389] ath9k_hw_intrpend 762
> >> [ 83.127761] (AR_SREV_9340(ah) val 0
> >> [ 83.131234] ath9k_hw_intrpend 767
> >> [ 83.134628] ath_isr 603
> >> [ 83.137134] ath9k: ath9k_iowrite32 ffffff800a400024
> >> [ 83.141995] ath9k: ath9k_ioread32 ffffff800a400024
> >> [ 83.146771] ath9k_hw_kill_interrupts 793
> >> [ 83.150864] ath9k_hw_enable_interrupts 821
> >> [ 83.154971] ath9k_hw_enable_interrupts 825
> >> [ 83.159135] ath9k_hw_enable_interrupts 832
> >> [ 83.163300] ath9k: ath9k_iowrite32 ffffff800a400024
> >> [ 83.168161] AR_SREV_9100 0
> >> [ 83.170852] ath9k_hw_enable_interrupts 848
> >> [ 83.170855] ath9k_hw_intrpend 762
> >> [ 83.178398] (AR_SREV_9340(ah) val 0
> >> [ 83.181873] ath9k_hw_intrpend 767
> >> [ 83.185265] ath_isr 603
> >> [ 83.187773] ath9k: ath9k_iowrite32 ffffff800a400024
> >> [ 83.192635] ath9k: ath9k_ioread32 ffffff800a400024
> >> [ 83.197411] ath9k_hw_kill_interrupts 793
> >> [ 83.201414] ath9k: ath9k_ioread32 ffffff800a400024
> >> [ 83.206258] ath9k_hw_enable_interrupts 821
> >> [ 83.210368] ath9k_hw_enable_interrupts 825
> >> [ 83.214531] ath9k_hw_enable_interrupts 832
> >> [ 83.218698] ath9k: ath9k_iowrite32 ffffff800a400024
> >> [ 83.223558] AR_SREV_9100 0
> >> [ 83.226243] ath9k_hw_enable_interrupts 848
> >> [ 83.226246] ath9k_hw_intrpend 762
> >> [ 83.233794] (AR_SREV_9340(ah) val 0
> >> [ 83.237268] ath9k_hw_intrpend 767
> >> [ 83.240661] ath_isr 603
> >> [ 83.243169] ath9k: ath9k_iowrite32 ffffff800a400024
> >> [ 83.248030] ath9k: ath9k_ioread32 ffffff800a400024
> >> [ 83.252806] ath9k_hw_kill_interrupts 793
> >> [ 83.256811] ath9k: ath9k_ioread32 ffffff800a400024
> >> [ 83.261651] ath9k_hw_enable_interrupts 821
> >> [ 83.265753] ath9k_hw_enable_interrupts 825
> >> [ 83.269919] ath9k_hw_enable_interrupts 832
> >> [ 83.274083] ath9k: ath9k_iowrite32 ffffff800a400024
> >> [ 83.278945] AR_SREV_9100 0
> >> [ 83.281630] ath9k_hw_enable_interrupts 848
> >> [ 83.281633] ath9k_hw_intrpend 762
> >> [ 83.281634] (AR_SREV_9340(ah) val 0
> >> [ 83.281637] ath9k_hw_intrpend 767
> >> [ 83.281648] ath_isr 603
> >> [ 83.281649] ath9k: ath9k_iowrite32 ffffff800a400024
> >> [ 83.281651] ath9k: ath9k_ioread32 ffffff800a400024
> >> [ 83.281654] ath9k_hw_kill_interrupts 793
> >> [ 83.312192] ath9k: ath9k_ioread32 ffffff800a400024
> >> [ 83.317030] ath9k_hw_enable_interrupts 821
> >> [ 83.321132] ath9k_hw_enable_interrupts 825
> >> [ 83.325297] ath9k_hw_enable_interrupts 832
> >> [ 83.329463] ath9k: ath9k_iowrite32 ffffff800a400024
> >> [ 83.334324] AR_SREV_9100 0
> >> [ 83.337014] ath9k_hw_enable_interrupts 848
> >> ..
> >> ..
> >> This log continues until I turn off board without obtaining scanning r=
esult.
> >>
> >> In between I get following cpu stall outputs :
> >> 230.457179] INFO: rcu_sched self-detected stall on CPU
> >> [ 230.457185] 2-...: (31314 ticks this GP)
> idle=3D2d1/140000000000001/0 softirq=3D1400/1400 fqs=3D36713
> >> [ 230.457189] (t=3D36756 jiffies g=3D161 c=3D160 q=3D16169)
> >> [ 230.457191] Task dump for CPU 2:
> >> [ 230.457196] kworker/u8:4 R running task 0 1342 2 0=
x00000002
> >> [ 230.457207] Workqueue: phy0 ieee80211_scan_work [ 230.457208]
> >> Call trace:
> >> [ 230.457214] [<ffffff8008089860>] dump_backtrace+0x0/0x198 [
> >> 230.457219] [<ffffff8008089a0c>] show_stack+0x14/0x20 [ 230.457224]
> >> [<ffffff80080c0930>] sched_show_task+0x98/0xf8 [ 230.457228]
> >> [<ffffff80080c2628>] dump_cpu_task+0x40/0x50 [ 230.457233]
> >> [<ffffff80080e14a8>] rcu_dump_cpu_stacks+0xa0/0xf0 [ 230.457239]
> >> [<ffffff80080e4cd8>] rcu_check_callbacks+0x468/0x748 [ 230.457243]
> >> [<ffffff80080e7cfc>] update_process_times+0x3c/0x68 [ 230.457249]
> >> [<ffffff80080f6dfc>] tick_sched_handle.isra.5+0x3c/0x50
> >> [ 230.457253] [<ffffff80080f6e54>] tick_sched_timer+0x44/0x90 [
> >> 230.457257] [<ffffff80080e86b0>] __hrtimer_run_queues+0xf0/0x178
> >> ** 10 printk messages dropped ** [ 230.457302] f8c0:
> >> 0000000000000000 0000000005f5e0ff 000000000001379a
> 3866666666666620 [
> >> 230.457306] f8e0: ffffff800a1b4065 0000000000000006 ffffff800a129000
> >> ffffffc87b8010a8 [ 230.457310] f900: ffffff808a1b4057
> >> ffffff800a1c3000 ffffff800a1b3000 ffffff800a13b000 [ 230.457314]
> >> f920: 0000000000000140 0000000000000006 ffffff800a1b3b10
> >> ffffff800a1c39e8 [ 230.457318] f940: 000000000000002f
> >> ffffff800a1b8a98 ffffff800a1b3ae8 ffffffc87b07f990 [ 230.457322]
> >> f960: ffffff80080d6230 ffffffc87b07f990 ffffff80080d6234
> >> 0000000060000145
> >> ** 1 printk messages dropped ** [ 230.457329] [<ffffff8008085720>]
> >> el1_irq+0xa0/0x100
> >> ** 9 printk messages dropped ** [ 230.457373] [<ffffff800885ad60>]
> >> ieee80211_hw_config+0x50/0x290 [ 230.457377] [<ffffff8008863690>]
> >> ieee80211_scan_work+0x1f8/0x480 [ 230.457383] [<ffffff80080b15d0>]
> >> process_one_work+0x120/0x378 [ 230.457386] [<ffffff80080b1870>]
> >> worker_thread+0x48/0x4b0 [ 230.457391] [<ffffff80080b7108>]
> >> kthread+0xd0/0xe8 [ 230.457395] [<ffffff8008085dd0>]
> ret_from_fork+0x10/0x40
> >> [ 230.480389] ath9k_hw_intrpend 762
> >>
> >>
> >> [ 545.487987] ath9k: ath9k_ioread32 ffffff800a400024 [ 545.526189]
> >> INFO: rcu_sched self-detected stall on CPU
> >> [ 545.526195] 2-...: (97636 ticks this GP)
> idle=3D2d1/140000000000001/0 softirq=3D1400/1400 fqs=3D115374
> >> [ 545.526199] (t=3D115523 jiffies g=3D161 c=3D160 q=3D51066)
> >> [ 545.526201] Task dump for CPU 2:
> >> [ 545.526206] kworker/u8:4 R running task 0 1342 2 0=
x00000002
> >> ** 3 printk messages dropped ** [ 545.526231] [<ffffff8008089a0c>]
> >> show_stack+0x14/0x20
> >> ** 9 printk messages dropped ** [ 545.526280] [<ffffff80086a71e8>]
> >> arch_timer_handler_phys+0x30/0x40 [ 545.526284] [<ffffff80080dbe18>]
> >> handle_percpu_devid_irq+0x78/0xa0 [ 545.526291] [<ffffff80080d760c>]
> >> generic_handle_irq+0x24/0x38 [ 545.526296] [<ffffff80080d7944>]
> >> __handle_domain_irq+0x5c/0xb8 [ 545.526299] [<ffffff80080824bc>]
> >> gic_handle_irq+0x64/0xc0 [ 545.526302] Exception stack(0xffffffc87b07=
f870
> to 0xffffffc87b07f990)
> >> [ 545.526306] f860: 000000000000973=
2 ffffff800a1eaaa8
> >> ** 8 printk messages dropped ** [ 545.526341] f980: ffffff800a1c39e8
> >> 0000000000000036 [ 545.526345] [<ffffff8008085720>]
> >> el1_irq+0xa0/0x100 [ 545.526349] [<ffffff80080d6234>]
> >> console_unlock+0x384/0x5b0 [ 545.526353] [<ffffff80080d673c>]
> >> vprintk_emit+0x2dc/0x4b0 [ 545.526357] [<ffffff80080d6a50>]
> >> vprintk_default+0x38/0x40 [ 545.526362] [<ffffff8008129704>]
> >> printk+0x58/0x60 [ 545.526366] [<ffffff800859e3e4>]
> >> ath9k_iowrite32+0x9c/0xa8 [ 545.526372] [<ffffff80085c7ca8>]
> >> ath9k_hw_kill_interrupts+0x28/0xf0
> >> [ 545.526376] [<ffffff80085a18ec>] ath_reset+0x24/0x68
> >> ** 2 printk messages dropped ** [ 545.526391] [<ffffff800885ad60>]
> ieee80211_hw_config+0x50/0x290
> >> ** 11 printk messages dropped ** [ 545.532834] ath9k_hw_kill_interrup=
ts
> 793
> >> [ 545.532890] ath9k_hw_enable_interrupts 821
>=20
> [ 81.876902] INFO: rcu_preempt detected stalls on CPUs/tasks:
> [ 81.876912] Tasks blocked on level-0 rcu_node (CPUs 0-7): P0
> [ 81.876932] (detected by 4, t=3D60002 jiffies, g=3D1873, c=3D1872,=
q=3D4967)
> [ 81.876936] swapper/4 R running task 0 0 1
> 0x00000000
> [ 81.876941] 0000000000000001 ffffffff810725f6 ffff88017edbc240
> ffffffff81a3dc40
> [ 81.876945] ffffffff81101e46 ffff88025ef173c0 ffffffff81a3dc40
> ffffffff81a3dc40
> [ 81.876948] 00000000ffffffff ffffffff810a7333 ffff88017ecee698
> ffff88017edbc240
> [ 81.876951] Call Trace:
> [ 81.876970] <IRQ>
> [ 81.876979] [<ffffffff810725f6>] ? sched_show_task+0xd6/0x140
> [ 81.876983] [<ffffffff81101e46>] ?
> rcu_print_detail_task_stall_rnp+0x40/0x61
> [ 81.876989] [<ffffffff810a7333>] ? rcu_check_callbacks+0x6b3/0x8c0
> [ 81.876993] [<ffffffff810b8350>] ? tick_sched_handle.isra.14+0x40/0x4=
0
> [ 81.876996] [<ffffffff810aa4c3>] ? update_process_times+0x23/0x50
> [ 81.876999] [<ffffffff810b8383>] ? tick_sched_timer+0x33/0x60
> [ 81.877002] [<ffffffff810aaf09>] ? __hrtimer_run_queues+0xb9/0x150
> [ 81.877004] [<ffffffff810ab198>] ? hrtimer_interrupt+0x98/0x1a0
> [ 81.877008] [<ffffffff81031b1e>] ?
> smp_trace_apic_timer_interrupt+0x5e/0x90
> [ 81.877012] [<ffffffff815b31bf>] ? apic_timer_interrupt+0x7f/0x90
> [ 81.877013] <EOI>
> [ 81.877017] [<ffffffff8147f28d>] ? cpuidle_enter_state+0x13d/0x1f0
> [ 81.877019] [<ffffffff8147f289>] ? cpuidle_enter_state+0x139/0x1f0
> [ 81.877021] [<ffffffff81088c19>] ? cpu_startup_entry+0x139/0x210
> [ 81.877027] [<ffffffff8102fc9e>] ? start_secondary+0x13e/0x170
> [ 81.877029] swapper/4 R running task 0 0 1
> 0x00000000
> [ 81.877032] 0000000000000001 ffffffff810725f6 ffff88017edbc240
> ffffffff81a3dc40
> [ 81.877035] ffffffff81101e46 ffff88025ef173c0 ffffffff81a3dc40
> ffffffff81a3dc40
> [ 81.877038] 00000000ffffffff ffffffff810a7368 ffff88017ecee698
> ffff88017edbc240
> [ 81.877041] Call Trace:
> [ 81.877045] <IRQ>
> [ 81.877049] [<ffffffff810725f6>] ? sched_show_task+0xd6/0x140
> [ 81.877051] [<ffffffff81101e46>] ?
> rcu_print_detail_task_stall_rnp+0x40/0x61
> [ 81.877055] [<ffffffff810a7368>] ? rcu_check_callbacks+0x6e8/0x8c0
> [ 81.877058] [<ffffffff810b8350>] ? tick_sched_handle.isra.14+0x40/0x4=
0
> [ 81.877060] [<ffffffff810aa4c3>] ? update_process_times+0x23/0x50
> [ 81.877063] [<ffffffff810b8383>] ? tick_sched_timer+0x33/0x60
> [ 81.877065] [<ffffffff810aaf09>] ? __hrtimer_run_queues+0xb9/0x150
> [ 81.877068] [<ffffffff810ab198>] ? hrtimer_interrupt+0x98/0x1a0
> [ 81.877070] [<ffffffff81031b1e>] ?
> smp_trace_apic_timer_interrupt+0x5e/0x90
> [ 81.877073] [<ffffffff815b31bf>] ? apic_timer_interrupt+0x7f/0x90
> [ 81.877074] <EOI>
> [ 81.877076] [<ffffffff8147f28d>] ? cpuidle_enter_state+0x13d/0x1f0
> [ 81.877078] [<ffffffff8147f289>] ? cpuidle_enter_state+0x139/0x1f0
> [ 81.877080] [<ffffffff81088c19>] ? cpu_startup_entry+0x139/0x210
> [ 81.877084] [<ffffffff8102fc9e>] ? start_secondary+0x13e/0x170
> [ 91.132787] INFO: rcu_preempt detected expedited stalls on
> CPUs/tasks: { P0 } 63785 jiffies s: 505 root: 0x0/T
> [ 91.132796] blocking rcu_node structures:
>=20
> >>
> >>
> >> But if we have less debug prints it does not reach EP handler
> >> sometimes, due to following Condition in "kernel/irq/chip.c" in
> >> function handle_simple_irq
> >>
> >> if (unlikely(!desc->action || irqd_irq_disabled(&desc->irq_data))) {
> >> desc->istate |=3D IRQS_PENDING;
> >> goto out_unlock;
> >> }
> >> Here irqd_irq_disabled is being set to 1.
> >>
> >> With lesser debug prints it stops after following prints:
> >> root@Xilinx-ZCU102-2016_3:~# iw dev wlan0 scan
> >> [ 54.781045] ath9k_hw_kill_interrupts 793
> >> [ 54.785007] ath9k_hw_kill_interrupts 793
> >> [ 54.792535] ath9k_hw_enable_interrupts 821
> >> [ 54.796642] ath9k_hw_enable_interrupts 825
> >> [ 54.800807] ath9k_hw_enable_interrupts 832
> >> [ 54.804973] AR_SREV_9100 0
> >> [ 54.807663] ath9k_hw_enable_interrupts 848
> >> [ 54.811843] ath9k_hw_intrpend 762
> >> [ 54.815211] (AR_SREV_9340(ah) val 0
> >> [ 54.818684] ath9k_hw_intrpend 767
> >> [ 54.822078] ath_isr 603
> >> [ 54.824587] ath9k_hw_kill_interrupts 793
> >> [ 54.828601] ath9k_hw_enable_interrupts 821
> >> [ 54.832750] ath9k_hw_enable_interrupts 825
> >> [ 54.836916] ath9k_hw_enable_interrupts 832
> >> [ 54.841082] AR_SREV_9100 0
> >> [ 54.843772] ath9k_hw_enable_interrupts 848
> >> [ 54.843775] ath9k_hw_intrpend 762
> >> [ 54.851319] (AR_SREV_9340(ah) val 0
> >> [ 54.854793] ath9k_hw_intrpend 767
> >> [ 54.858185] ath_isr 603
> >> [ 54.860696] ath9k_hw_kill_interrupts 793
> >> [ 54.864776] ath9k_hw_enable_interrupts 821
> >> [ 54.867061] ath9k_hw_kill_interrupts 793
> >> [ 54.872870] ath9k_hw_enable_interrupts 825
> >> [ 54.877036] ath9k_hw_enable_interrupts 832
> >> [ 54.881202] AR_SREV_9100 0
> >> [ 54.883892] ath9k_hw_enable_interrupts 848
> >> [ 75.963129] INFO: rcu_sched detected stalls on CPUs/tasks:
> >> [ 75.968602] 0-...: (2 GPs behind) idle=3D9d5/140000000000001/0
> softirq=3D1103/1109 fqs=3D519
> >> [ 75.976675] (detected by 2, t=3D5274 jiffies, g=3D64, c=3D63, q=3D=
11)
> >> [ 75.982485] Task dump for CPU 0:
> >> [ 75.985696] ksoftirqd/0 R running task 0 3 2 0=
x00000002
> >> [ 75.992726] Call trace:
> >> [ 75.995165] [<ffffff8008086b3c>] __switch_to+0xc4/0xd0
> >> [ 76.000281] [<ffffffc87b830500>] 0xffffffc87b830500
> >> [ 139.059027] INFO: rcu_sched detected stalls on CPUs/tasks:
> >> [ 139.064430] 0-...: (2 GPs behind) idle=3D9d5/140000000000001/0
> softirq=3D1103/1109 fqs=3D2097
> >> [ 139.072593] (detected by 2, t=3D21049 jiffies, g=3D64, c=3D63, q=
=3D11)
> >> [ 139.078489] Task dump for CPU 0:
> >> [ 139.081700] ksoftirqd/0 R running task 0 3 2 0=
x00000002
> >> [ 139.088731] Call trace:
> >> [ 139.091165] [<ffffff8008086b3c>] __switch_to+0xc4/0xd0 [
> >> 139.096285] [<ffffffc87b830500>] 0xffffffc87b830500
> >>
> >>
> >>>> We are not seeing any issues on 32-bit ARM platform and X86
> >>>> platform.
> >>> Can you collect a dmesg log (or, if the system hang means you can't
> >>> collect that, a console log with "ignore_loglevel"), and "lspci -vv"
> >>> output as root? That should have clues about whether the INTx got
> >>> routed correctly. /proc/interrupts should also show whether we're
> >>> receiving interrupts from the device.
> >> Here is the lspci output:
> >> 00:00.0 PCI bridge: Xilinx Corporation Device d022 (prog-if 00 [Normal
> decode])
> >> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx-
> >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> >> Latency: 0
> >> Interrupt: pin A routed to IRQ 224
> >> Bus: primary=3D00, secondary=3D01, subordinate=3D0c, sec-latency=3D0
> >> I/O behind bridge: 00000000-00000fff
> >> Memory behind bridge: e0000000-e00fffff
> >> Prefetchable memory behind bridge: 00000000fff00000-
> 00000000000fffff
> >> Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=3Dfast >TAbort-
> <TAbort- <MAbort- <SERR- <PERR-
> >> BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
> >> PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
> >> Capabilities: [40] Power Management version 3
> >> Flags: PMEClk- DSI- D1- D2- AuxCurrent=3D0mA
> PME(D0+,D1+,D2+,D3hot+,D3cold-)
> >> Status: D0 NoSoftRst+ PME-Enable- DSel=3D0 DScale=3D0 PME-
> >> Capabilities: [60] Express (v2) Root Port (Slot-), MSI 00
> >> DevCap: MaxPayload 256 bytes, PhantFunc 0
> >> ExtTag- RBE+
> >> DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> Unsupported-
> >> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
> >> MaxPayload 128 bytes, MaxReadReq 512 bytes
> >> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr-
> TransPend+
> >> LnkCap: Port #0, Speed 5GT/s, Width x2, ASPM not supported,
> Exit Latency L0s unlimited, L1 unlimited
> >> ClockPM- Surprise- LLActRep- BwNot+ ASPMOptComp+
> >> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
> >> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> >> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
> DLActive- BWMgmt- ABWMgmt-
> >> RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna-
> CRSVisible+
> >> RootCap: CRSVisible+
> >> RootSta: PME ReqID 0000, PMEStatus- PMEPending-
> >> DevCap2: Completion Timeout: Range B, TimeoutDis+, LTR-,
> OBFF Not Supported ARIFwd-
> >> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-,
> OBFF Disabled ARIFwd-
> >> LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
> >> Transmit Margin: Normal Operating Range,
> EnterModifiedCompliance- ComplianceSOS-
> >> Compliance De-emphasis: -6dB
> >> LnkSta2: Current De-emphasis Level: -3.5dB,
> EqualizationComplete-, EqualizationPhase1-
> >> EqualizationPhase2-, EqualizationPhase3-,
> LinkEqualizationRequest-
> >> Capabilities: [100 v1] Device Serial Number 00-00-00-00-00-00-00-00
> >> Capabilities: [10c v1] Virtual Channel
> >> Caps: LPEVC=3D0 RefClk=3D100ns PATEntryBits=3D1
> >> Arb: Fixed- WRR32- WRR64- WRR128-
> >> Ctrl: ArbSelect=3DFixed
> >> Status: InProgress-
> >> VC0: Caps: PATOffset=3D00 MaxTimeSlots=3D1 RejSnoopTrans-
> >> Arb: Fixed- WRR32- WRR64- WRR128- TWRR128-
> WRR256-
> >> Ctrl: Enable+ ID=3D0 ArbSelect=3DFixed TC/VC=3Dff
> >> Status: NegoPending- InProgress-
> >> Capabilities: [128 v1] Vendor Specific Information: ID=3D1234 Rev=3D1
> >> Len=3D018 <?>
> >>
> >> 01:00.0 Network controller: Qualcomm Atheros AR93xx Wireless Network
> Adapter (rev 01)
> >> Subsystem: Qualcomm Atheros Device 3112
> >> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx-
> >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> >> Latency: 0, Cache Line Size: 128 bytes
> >> Interrupt: pin A routed to IRQ 224
> >> Region 0: Memory at e0000000 (64-bit, non-prefetchable) [size=3D128K]
> >> [virtual] Expansion ROM at e0020000 [disabled] [size=3D64K]
> >> Capabilities: [40] Power Management version 3
> >> Flags: PMEClk- DSI- D1+ D2- AuxCurrent=3D375mA
> PME(D0+,D1+,D2-,D3hot+,D3cold-)
> >> Status: D0 NoSoftRst- PME-Enable- DSel=3D0 DScale=3D0 PME-
> >> Capabilities: [50] MSI: Enable- Count=3D1/4 Maskable+ 64bit+
> >> Address: 0000000000000000 Data: 0000
> >> Masking: 00000000 Pending: 00000000
> >> Capabilities: [70] Express (v2) Endpoint, MSI 00
> >> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency
> L0s <1us, L1 <8us
> >> ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
> SlotPowerLimit 0.000W
> >> DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> Unsupported-
> >> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
> >> MaxPayload 128 bytes, MaxReadReq 512 bytes
> >> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr-
> TransPend-
> >> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit
> Latency L0s <2us, L1 <64us
> >> ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
> >> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
> >> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> >> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
> DLActive- BWMgmt- ABWMgmt-
> >> DevCap2: Completion Timeout: Not Supported, TimeoutDis+,
> LTR-, OBFF Not Supported
> >> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-,
> OBFF Disabled
> >> LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance-
> SpeedDis-
> >> Transmit Margin: Normal Operating Range,
> EnterModifiedCompliance- ComplianceSOS-
> >> Compliance De-emphasis: -6dB
> >> LnkSta2: Current De-emphasis Level: -6dB,
> EqualizationComplete-, EqualizationPhase1-
> >> EqualizationPhase2-, EqualizationPhase3-,
> LinkEqualizationRequest-
> >> Capabilities: [100 v1] Advanced Error Reporting
> >> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> >> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> >> UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt-
> RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
> >> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
> NonFatalErr-
> >> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
> NonFatalErr+
> >> AERCap: First Error Pointer: 00, GenCap- CGenEn-
> ChkCap- ChkEn-
> >> Capabilities: [140 v1] Virtual Channel
> >> Caps: LPEVC=3D0 RefClk=3D100ns PATEntryBits=3D1
> >> Arb: Fixed- WRR32- WRR64- WRR128-
> >> Ctrl: ArbSelect=3DFixed
> >> Status: InProgress-
> >> VC0: Caps: PATOffset=3D00 MaxTimeSlots=3D1 RejSnoopTrans-
> >> Arb: Fixed- WRR32- WRR64- WRR128- TWRR128-
> WRR256-
> >> Ctrl: Enable+ ID=3D0 ArbSelect=3DFixed TC/VC=3Dff
> >> Status: NegoPending- InProgress-
> >> Capabilities: [300 v1] Device Serial Number 00-00-00-00-00-00-00-00
> >> Kernel driver in use: ath9k
> >>
> >> Here is the cat /proc/interrupts (after we do interface up):
> >>
> >> root@:~# ifconfig wlan0 up
> >> [ 1548.926601] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> >> root@Xilinx-ZCU102-2016_3:~# cat /proc/interrupts
> >> CPU0 CPU1 CPU2 CPU3
> >> 1: 0 0 0 0 GICv2 29 Edge =
arch_timer
> >> 2: 19873 20058 19089 17435 GICv2 30 Edge =
arch_timer
> >> 12: 0 0 0 0 GICv2 156 Level =
zynqmp-dma
> >> 13: 0 0 0 0 GICv2 157 Level =
zynqmp-dma
> >> 14: 0 0 0 0 GICv2 158 Level =
zynqmp-dma
> >> 15: 0 0 0 0 GICv2 159 Level =
zynqmp-dma
> >> 16: 0 0 0 0 GICv2 160 Level =
zynqmp-dma
> >> 17: 0 0 0 0 GICv2 161 Level =
zynqmp-dma
> >> 18: 0 0 0 0 GICv2 162 Level =
zynqmp-dma
> >> 19: 0 0 0 0 GICv2 163 Level =
zynqmp-dma
> >> 20: 0 0 0 0 GICv2 164 Level =
Mali_GP_MMU,
> Mali_GP, Mali_PP0_MMU, Mali_PP0, Mali_PP1_MMU, Mali_PP1
> >> 30: 0 0 0 0 GICv2 95 Level =
eth0, eth0
> >> 206: 314 0 0 0 GICv2 49 Level =
cdns-i2c
> >> 207: 40 0 0 0 GICv2 50 Level =
cdns-i2c
> >> 209: 0 0 0 0 GICv2 150 Level =
nwl_pcie:misc
> >> 214: 12 0 0 0 GICv2 47 Level =
ff0f0000.spi
> >> 215: 0 0 0 0 GICv2 58 Level =
ffa60000.rtc
> >> 216: 0 0 0 0 GICv2 59 Level =
ffa60000.rtc
> >> 217: 0 0 0 0 GICv2 165 Level =
ahci-
> ceva[fd0c0000.ahci]
> >> 218: 61 0 0 0 GICv2 81 Level =
mmc0
> >> 219: 0 0 0 0 GICv2 187 Level =
arm-smmu global fault
> >> 220: 471 0 0 0 GICv2 53 Level =
xuartps
> >> 223: 0 0 0 0 GICv2 154 Level =
fd4c0000.dma
> >> 224: 3 0 0 0 dummy 1 Edge =
ath9k
> >> 225: 0 0 0 0 GICv2 97 Level =
xhci-hcd:usb1
> >>
> >> Regards,
> >> Bharat
^ permalink raw reply
* Could we have request_firmware_nowait with FW_OPT_NO_WARN?
From: Rafał Miłecki @ 2016-12-10 15:54 UTC (permalink / raw)
To: Ming Lei, Luis R. Rodriguez, Linux Kernel Mailing List
Cc: linux-wireless@vger.kernel.org, brcm80211 development
Hi,
In brcmfmac we use request_firmware_nowait and if fetching firmware
with NVRAM variables fails then we try to fallback to the platform one
(see brcmf_fw_request_code_done & brcmf_fw_request_nvram_done).
Some problem for us is that on devices with platform NVRAM we get this erro=
r:
Direct firmware load for brcm/brcmfmac43602-pcie.txt failed with error -2
(which is harmless if getting platform NVRAM succeeds). This error is
quite confusing for users. They think something went wrong, they
expect problems & they report it back to us. Obviously I don't want
ugly hacks like:
pr_info("Got platform NVRAM, ignore above error\n");
So it would be nice to have version of request_firmware_nowait with
FW_OPT_NO_WARN. If requesting firmware NVRAM fails *and* getting
platform NVRAM fails, then I could to print error on my own.
Does it make sense? Can you see a point of my request?
Do you have any suggestion for this? If and how I could proceed with
implementation?
request_firmware_nowait already has "bool uevent" argument, I don't
want it to have argument per every available option. I was thinking
about moving FW_OPT_* defines to the include/linux/firmware.h but I'm
not sure if it's OK as they depend on:
CONFIG_FW_LOADER_USER_HELPER
and
CONFIG_FW_LOADER_USER_HELPER_FALLBACK
With defines placed in firmware.h I could replace "bool uevent" with
"unsigned int opt_flags".
Does it sound like a good plan? Or do you have any better idea?
--=20
Rafa=C5=82
^ permalink raw reply
* [PATCH 00/14] rtlwifi: Start reworking of debug system
From: Larry Finger @ 2016-12-11 5:44 UTC (permalink / raw)
To: kvalo; +Cc: devel, linux-wireless, Larry Finger, Ping-Ke Shih
Following the discussion regarding the patch entitled "rtlwifi: Add
BTC_TRACE_STRING to new btcoex", we are reworking the entire debug
system. This set of patches does the following:
1. Replaces every invocation of RT_ASSERT with WARN_ON. With this
change, triggering these conditions with now give a stack dump.
Note that the logical condition between RT_ASSERT and WARN_ON
is inverted. In making these changes, 6 logic errors were found.
2. Replaces every call of RT_TRACE with the level set to DBG_EMERG
with the equivalent pr_err() call.
3. Removes some redundant logged conditions. For example, when the
failure of firmware to start is logged, it is not necessary to
log that the firmware did start.
The previous two patch sequences "[PATCH 00/14] rtlwifi: Various updates"
and "[PATCH 0/7] rtlwifi: btcoexist: Rewrite BT coexistence routines"
should be discarded. That material will be resubmitted later.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Ping-Ke Shih <pkshih@realtek.com>
Larry Finger (14):
rtlwifi: Replace local debug macro RT_ASSERT
rtlwifi_new: Remove RT_TRACE messages that use DBG_EMERG
rtlwifi_new: rtl8821ae: Remove all instances of DBG_EMERG
rtlwifi_new: rtl8723be: Remove all instances of DBG_EMERG
rtlwifi_new: rtl8723ae: Remove all instances of DBG_EMERG
rtlwifi_new: rtl8192ee: Remove all instances of DBG_EMERG
rtlwifi_new: rtl8723-common: Remove all instances of DBG_EMERG
rtlwifi_new: rtl8192se: Remove all instances of DBG_EMERG
rtlwifi_new: rtl8192de: Remove all instances of DBG_EMERG
rtlwifi_new: rtl8192cu: Remove all instances of DBG_EMERG
rtlwifi_new: rtl8192ce: Remove all instances of DBG_EMERG
rtlwifi_new: rtl8192c-common: Remove all instances of DBG_EMERG
rtlwifi_new: rtl8188ee: Remove all instances of DBG_EMERG
rtlwifi: Remove some redundant code
drivers/net/wireless/realtek/rtlwifi/base.c | 15 +++----
drivers/net/wireless/realtek/rtlwifi/cam.c | 14 +++---
drivers/net/wireless/realtek/rtlwifi/core.c | 29 +++++-------
drivers/net/wireless/realtek/rtlwifi/debug.c | 9 ++--
drivers/net/wireless/realtek/rtlwifi/debug.h | 18 +-------
drivers/net/wireless/realtek/rtlwifi/efuse.c | 3 +-
drivers/net/wireless/realtek/rtlwifi/pci.c | 48 ++++++++------------
drivers/net/wireless/realtek/rtlwifi/ps.c | 3 +-
drivers/net/wireless/realtek/rtlwifi/rc.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/fw.c | 43 +++++-------------
.../net/wireless/realtek/rtlwifi/rtl8188ee/hw.c | 32 +++++---------
.../net/wireless/realtek/rtlwifi/rtl8188ee/phy.c | 32 ++++++--------
.../net/wireless/realtek/rtlwifi/rtl8188ee/rf.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/sw.c | 8 ++--
.../net/wireless/realtek/rtlwifi/rtl8188ee/trx.c | 8 ++--
.../wireless/realtek/rtlwifi/rtl8192c/fw_common.c | 45 ++++++-------------
.../wireless/realtek/rtlwifi/rtl8192c/phy_common.c | 27 ++++++------
.../net/wireless/realtek/rtlwifi/rtl8192ce/hw.c | 38 ++++++----------
.../net/wireless/realtek/rtlwifi/rtl8192ce/led.c | 6 +--
.../net/wireless/realtek/rtlwifi/rtl8192ce/phy.c | 13 +++---
.../net/wireless/realtek/rtlwifi/rtl8192ce/rf.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/sw.c | 8 ++--
.../net/wireless/realtek/rtlwifi/rtl8192ce/trx.c | 8 ++--
.../net/wireless/realtek/rtlwifi/rtl8192cu/hw.c | 35 +++++----------
.../net/wireless/realtek/rtlwifi/rtl8192cu/led.c | 6 +--
.../net/wireless/realtek/rtlwifi/rtl8192cu/mac.c | 12 ++---
.../net/wireless/realtek/rtlwifi/rtl8192cu/phy.c | 12 ++---
.../net/wireless/realtek/rtlwifi/rtl8192cu/rf.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192cu/sw.c | 5 +--
.../net/wireless/realtek/rtlwifi/rtl8192cu/trx.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/fw.c | 31 ++++---------
.../net/wireless/realtek/rtlwifi/rtl8192de/hw.c | 34 +++++----------
.../net/wireless/realtek/rtlwifi/rtl8192de/led.c | 6 +--
.../net/wireless/realtek/rtlwifi/rtl8192de/phy.c | 41 ++++++++---------
.../net/wireless/realtek/rtlwifi/rtl8192de/rf.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/sw.c | 10 ++---
.../net/wireless/realtek/rtlwifi/rtl8192de/trx.c | 8 ++--
.../net/wireless/realtek/rtlwifi/rtl8192ee/fw.c | 40 +++++------------
.../net/wireless/realtek/rtlwifi/rtl8192ee/hw.c | 13 +++---
.../net/wireless/realtek/rtlwifi/rtl8192ee/phy.c | 36 +++++++--------
.../net/wireless/realtek/rtlwifi/rtl8192ee/rf.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/sw.c | 8 ++--
.../net/wireless/realtek/rtlwifi/rtl8192ee/trx.c | 15 ++++---
.../net/wireless/realtek/rtlwifi/rtl8192se/fw.c | 46 ++++++++-----------
.../net/wireless/realtek/rtlwifi/rtl8192se/hw.c | 42 +++++++-----------
.../net/wireless/realtek/rtlwifi/rtl8192se/led.c | 6 +--
.../net/wireless/realtek/rtlwifi/rtl8192se/phy.c | 42 +++++++-----------
.../net/wireless/realtek/rtlwifi/rtl8192se/rf.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/sw.c | 8 ++--
.../net/wireless/realtek/rtlwifi/rtl8192se/trx.c | 8 ++--
.../net/wireless/realtek/rtlwifi/rtl8723ae/fw.c | 13 +++---
.../net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 21 ++++-----
.../net/wireless/realtek/rtlwifi/rtl8723ae/led.c | 6 +--
.../net/wireless/realtek/rtlwifi/rtl8723ae/phy.c | 28 +++++-------
.../net/wireless/realtek/rtlwifi/rtl8723ae/rf.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/sw.c | 8 ++--
.../net/wireless/realtek/rtlwifi/rtl8723ae/trx.c | 8 ++--
.../net/wireless/realtek/rtlwifi/rtl8723be/fw.c | 13 +++---
.../net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 18 +++-----
.../net/wireless/realtek/rtlwifi/rtl8723be/led.c | 6 +--
.../net/wireless/realtek/rtlwifi/rtl8723be/phy.c | 30 ++++++-------
.../net/wireless/realtek/rtlwifi/rtl8723be/rf.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/sw.c | 8 ++--
.../net/wireless/realtek/rtlwifi/rtl8723be/trx.c | 14 +++---
.../realtek/rtlwifi/rtl8723com/fw_common.c | 25 +++--------
.../realtek/rtlwifi/rtl8723com/phy_common.c | 6 +--
.../net/wireless/realtek/rtlwifi/rtl8821ae/dm.c | 3 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/fw.c | 28 ++++--------
.../net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 31 ++++++-------
.../net/wireless/realtek/rtlwifi/rtl8821ae/phy.c | 51 +++++++++-------------
.../net/wireless/realtek/rtlwifi/rtl8821ae/rf.c | 5 +--
.../net/wireless/realtek/rtlwifi/rtl8821ae/sw.c | 14 +++---
.../net/wireless/realtek/rtlwifi/rtl8821ae/trx.c | 20 +++++----
drivers/net/wireless/realtek/rtlwifi/usb.c | 48 +++++++-------------
74 files changed, 488 insertions(+), 816 deletions(-)
--
2.10.2
^ 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