[PATCH v5] ath10k: add atomic protection for device recovery
When it has more than one restart_work queued meanwhile, the 2nd
restart_work is very easy to break the 1st restart work and lead
recovery fail.
Add a flag to allow only one restart work running untill
device successfully recovered.
Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00049
Signed-off-by: Wen Gong
---
v5: change ref count to BIT dev flag, change all
queue_work(ar->workqueue, >restart_work) to ath10k_core_start_recovery
v4: add atomic_dec(>restart_count) if state is not on
v3: change atomic_inc_and_test to atomic_add_return, remove check of
ATH10K_STATE_ON
v2: add "add refcount for ath10k_core_restart" and remove ar_sdio->can_recovery
drivers/net/wireless/ath/ath10k/core.c | 11 +++
drivers/net/wireless/ath/ath10k/core.h | 4
drivers/net/wireless/ath/ath10k/debug.c | 6 +++---
drivers/net/wireless/ath/ath10k/mac.c | 1 +
drivers/net/wireless/ath/ath10k/pci.c | 2 +-
drivers/net/wireless/ath/ath10k/sdio.c | 6 +++---
drivers/net/wireless/ath/ath10k/snoc.c | 2 +-
drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
8 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index cfffd20df0cc..a9c3cbb400be 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -2277,6 +2277,17 @@ static int ath10k_init_hw_params(struct ath10k *ar)
return 0;
}
+void ath10k_core_start_recovery(struct ath10k *ar)
+{
+ if (test_and_set_bit(ATH10K_FLAG_RESTARTING, >dev_flags)) {
+ ath10k_warn(ar, "already restarting\n");
+ return;
+ }
+
+ queue_work(ar->workqueue, >restart_work);
+}
+EXPORT_SYMBOL(ath10k_core_start_recovery);
+
static void ath10k_core_restart(struct work_struct *work)
{
struct ath10k *ar = container_of(work, struct ath10k, restart_work);
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 5c18f6c20462..347137ab7c09 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -837,6 +837,9 @@ enum ath10k_dev_flags {
/* Per Station statistics service */
ATH10K_FLAG_PEER_STATS,
+
+ /* Indicates that ath10k device is during recovery process and not
complete */
+ ATH10K_FLAG_RESTARTING,
};
enum ath10k_cal_mode {
@@ -1291,6 +1294,7 @@ int ath10k_core_start(struct ath10k *ar, enum
ath10k_firmware_mode mode,
const struct ath10k_fw_components *fw_components);
int ath10k_wait_for_suspend(struct ath10k *ar, u32 suspend_opt);
void ath10k_core_stop(struct ath10k *ar);
+void ath10k_core_start_recovery(struct ath10k *ar);
int ath10k_core_register(struct ath10k *ar,
const struct ath10k_bus_params *bus_params);
void ath10k_core_unregister(struct ath10k *ar);
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index e8250a665433..6b6dde513bab 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -583,7 +583,7 @@ static ssize_t ath10k_write_simulate_fw_crash(struct file
*file,
ret = ath10k_debug_fw_assert(ar);
} else if (!strcmp(buf, "hw-restart")) {
ath10k_info(ar, "user requested hw restart\n");
- queue_work(ar->workqueue, >restart_work);
+ ath10k_core_start_recovery(ar);
ret = 0;
} else {
ret = -EINVAL;
@@ -2005,7 +2005,7 @@ static ssize_t ath10k_write_btcoex(struct file *file,
}
} else {
ath10k_info(ar, "restarting firmware due to btcoex change");
- queue_work(ar->workqueue, >restart_work);
+ ath10k_core_start_recovery(ar);
}
if (val)
@@ -2136,7 +2136,7 @@ static ssize_t ath10k_write_peer_stats(struct file *file,
ath10k_info(ar, "restarting firmware due to Peer stats change");
- queue_work(ar->workqueue, >restart_work);
+ ath10k_core_start_recovery(ar);
ret = count;
exit:
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 82b4bf5ba612..9980011feea8 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7268,6 +7268,7 @@ static void ath10k_reconfig_complete(struct ieee80211_hw
*hw,
ath10k_info(ar, "device successfully recovered\n");
ar->state = ATH10K_STATE_ON;
ieee80211_wake_queues(ar->hw);
+ clear_bit(ATH10K_FLAG_RESTARTING, >dev_flags);
}
mutex_unlock(>conf_mutex);
diff --git a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
index 36426efdb2ea..a21b44ea04ab 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1774,7 +1774,7 @@ static void
Re: [RFC] ath10k: change to do napi_enable and napi_disable when insmod and rmmod for sdio
On 2020-08-21 04:59, Ben Greear wrote: On 8/20/20 1:15 PM, Krishna Chaitanya wrote: On Thu, Aug 20, 2020 at 11:23 PM Ben Greear wrote: On 8/20/20 10:42 AM, Krishna Chaitanya wrote: On Thu, Aug 20, 2020 at 11:11 PM Krishna Chaitanya wrote: On Thu, Aug 20, 2020 at 10:38 PM Ben Greear wrote: On 8/20/20 10:00 AM, Krishna Chaitanya wrote: On Thu, Aug 20, 2020 at 10:02 PM Ben Greear wrote: On 8/20/20 9:08 AM, Krishna Chaitanya wrote: On Thu, Aug 20, 2020 at 8:07 PM Wen Gong wrote: On 2020-08-20 18:52, Krishna Chaitanya wrote: On Thu, Aug 20, 2020 at 3:45 PM Wen Gong wrote: On 2020-08-20 17:19, Krishna Chaitanya wrote: ... I'm not really convinced that this is the right fix, but I'm no NAPI expert. Can anyone else help? Calling napi_disable() twice can lead to hangs, but moving NAPI from start/stop to the probe isn't the right approach as the datapath is tied to start/stop. Maybe check the state of NAPI before disable? if (test_bit(NAPI_STATE_SCHED, >napi.napi.state)) napi_disable(>napi) or maintain napi_state like this https://patchwork.kernel.org/patch/10249365/ it is better to use above link's patch. napi.state is controlled by napi API, it is better ath10k not know it. Sure, but IMHO just canceling the async rx work should solve the issue. Oh no, canceling the async rx work will not solve this issue, rx worker ath10k_rx_indication_async_work call napi_schedule, after napi_complete, the NAPI_STATE_SCHED will clear. The issue of this patch is because 2 thread called to hif_stop and NAPI_STATE_SCHED not clear. That fix is still valid and good to have. ndev_stop being called twice is typical scenarios (stop vs rmmod), so just checking the netdev_flags for IFF_UP and returning from hif_Stop should suffice, no? My approach to fix this problem was to add a boolean in ath10k as to whether it had napi enabled or not, and then check that before trying to enable/disable it again. Seems to work fine, and cleaner in my mind than checking internal napi flags. A much simpler approach is just to check for IFF_UP and skip NAPI (and others) in the hif_stop no? (provided proper RTNL locking is done if hif_stop is being called internally as well). I'm not sure, but I think the driver should be internally consistent and not spend a lot of time trying to guess about interactions with objects higher in the stack. Fair enough, the network interface state is a basic thing controlled by the driver, so, should be okay to use. Anyways, the in-driver approach has more control. Here is my original patch to fix this, it is not complex. https://patchwork.kernel.org/patch/10249363/ Sure, I have shared your patch above :). Sent a bit early, any idea why this wasn't upstreamed earlier? No, one comment from Michal indicated maybe there were more problems lurking in this area, but he seemed to be OK with the patch over all. After that, it was just ignored. Now might be a good time to push for it :) It is generally a waste of time in my experience. Kalle is the maintainer and should be seeing any of this he cares to see. If he likes the patch, he can apply it or something similar. If you have a reproducible test case, see if the patch fixes things, that might help it be accepted. I have 2 cmd, each one can reproduce the hang. echo soft > /sys/kernel/debug/ieee80211/phy0/ath10k/simulate_fw_crash;sleep 0.05;ifconfig wlan0 down echo soft > /sys/kernel/debug/ieee80211/phy0/ath10k/simulate_fw_crash;rmmod ath10k_sdio and with the my patch, it fix the hang. Change of my patch is similar with your patch(https://patchwork.kernel.org/patch/10249365/), so it should also fix the hang with your patch. Thanks, Ben ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [RFC] ath10k: change to do napi_enable and napi_disable when insmod and rmmod for sdio
On 8/20/20 1:15 PM, Krishna Chaitanya wrote: On Thu, Aug 20, 2020 at 11:23 PM Ben Greear wrote: On 8/20/20 10:42 AM, Krishna Chaitanya wrote: On Thu, Aug 20, 2020 at 11:11 PM Krishna Chaitanya wrote: On Thu, Aug 20, 2020 at 10:38 PM Ben Greear wrote: On 8/20/20 10:00 AM, Krishna Chaitanya wrote: On Thu, Aug 20, 2020 at 10:02 PM Ben Greear wrote: On 8/20/20 9:08 AM, Krishna Chaitanya wrote: On Thu, Aug 20, 2020 at 8:07 PM Wen Gong wrote: On 2020-08-20 18:52, Krishna Chaitanya wrote: On Thu, Aug 20, 2020 at 3:45 PM Wen Gong wrote: On 2020-08-20 17:19, Krishna Chaitanya wrote: ... I'm not really convinced that this is the right fix, but I'm no NAPI expert. Can anyone else help? Calling napi_disable() twice can lead to hangs, but moving NAPI from start/stop to the probe isn't the right approach as the datapath is tied to start/stop. Maybe check the state of NAPI before disable? if (test_bit(NAPI_STATE_SCHED, >napi.napi.state)) napi_disable(>napi) or maintain napi_state like this https://patchwork.kernel.org/patch/10249365/ it is better to use above link's patch. napi.state is controlled by napi API, it is better ath10k not know it. Sure, but IMHO just canceling the async rx work should solve the issue. Oh no, canceling the async rx work will not solve this issue, rx worker ath10k_rx_indication_async_work call napi_schedule, after napi_complete, the NAPI_STATE_SCHED will clear. The issue of this patch is because 2 thread called to hif_stop and NAPI_STATE_SCHED not clear. That fix is still valid and good to have. ndev_stop being called twice is typical scenarios (stop vs rmmod), so just checking the netdev_flags for IFF_UP and returning from hif_Stop should suffice, no? My approach to fix this problem was to add a boolean in ath10k as to whether it had napi enabled or not, and then check that before trying to enable/disable it again. Seems to work fine, and cleaner in my mind than checking internal napi flags. A much simpler approach is just to check for IFF_UP and skip NAPI (and others) in the hif_stop no? (provided proper RTNL locking is done if hif_stop is being called internally as well). I'm not sure, but I think the driver should be internally consistent and not spend a lot of time trying to guess about interactions with objects higher in the stack. Fair enough, the network interface state is a basic thing controlled by the driver, so, should be okay to use. Anyways, the in-driver approach has more control. Here is my original patch to fix this, it is not complex. https://patchwork.kernel.org/patch/10249363/ Sure, I have shared your patch above :). Sent a bit early, any idea why this wasn't upstreamed earlier? No, one comment from Michal indicated maybe there were more problems lurking in this area, but he seemed to be OK with the patch over all. After that, it was just ignored. Now might be a good time to push for it :) It is generally a waste of time in my experience. Kalle is the maintainer and should be seeing any of this he cares to see. If he likes the patch, he can apply it or something similar. If you have a reproducible test case, see if the patch fixes things, that might help it be accepted. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [RFC] ath10k: change to do napi_enable and napi_disable when insmod and rmmod for sdio
On Thu, Aug 20, 2020 at 11:23 PM Ben Greear wrote: > > On 8/20/20 10:42 AM, Krishna Chaitanya wrote: > > On Thu, Aug 20, 2020 at 11:11 PM Krishna Chaitanya > > wrote: > >> > >> On Thu, Aug 20, 2020 at 10:38 PM Ben Greear > >> wrote: > >>> > >>> On 8/20/20 10:00 AM, Krishna Chaitanya wrote: > On Thu, Aug 20, 2020 at 10:02 PM Ben Greear > wrote: > > > > On 8/20/20 9:08 AM, Krishna Chaitanya wrote: > >> On Thu, Aug 20, 2020 at 8:07 PM Wen Gong wrote: > >>> > >>> On 2020-08-20 18:52, Krishna Chaitanya wrote: > On Thu, Aug 20, 2020 at 3:45 PM Wen Gong > wrote: > > > > On 2020-08-20 17:19, Krishna Chaitanya wrote: > >>> ... > >>> I'm not really convinced that this is the right fix, but I'm no > >>> NAPI > >>> expert. Can anyone else help? > >> Calling napi_disable() twice can lead to hangs, but moving NAPI > >> from > >> start/stop to > >> the probe isn't the right approach as the datapath is tied to > >> start/stop. > >> > >> Maybe check the state of NAPI before disable? > >> > >> if (test_bit(NAPI_STATE_SCHED, >napi.napi.state)) > >> napi_disable(>napi) > >> or maintain napi_state like this > >> https://patchwork.kernel.org/patch/10249365/ > > it is better to use above link's patch. > > napi.state is controlled by napi API, it is better ath10k not know > > it. > Sure, but IMHO just canceling the async rx work should solve the > issue. > >>> Oh no, canceling the async rx work will not solve this issue, rx > >>> worker > >>> ath10k_rx_indication_async_work call napi_schedule, after > >>> napi_complete, > >>> the NAPI_STATE_SCHED will clear. > >>> The issue of this patch is because 2 thread called to hif_stop and > >>> NAPI_STATE_SCHED not clear. > >> That fix is still valid and good to have. > >> > >> ndev_stop being called twice is typical scenarios (stop vs rmmod), so > >> just checking the netdev_flags for IFF_UP and returning from > >> hif_Stop > >> should suffice, no? > > > > My approach to fix this problem was to add a boolean in ath10k as to > > whether > > it had napi enabled or not, and then check that before trying to > > enable/disable > > it again. Seems to work fine, and cleaner in my mind than checking > > internal > > napi flags. > A much simpler approach is just to check for IFF_UP and skip NAPI (and > others) > in the hif_stop no? (provided proper RTNL locking is done if hif_stop > is being called > internally as well). > > >>> > >>> I'm not sure, but I think the driver should be internally consistent and > >>> not > >>> spend a lot of time trying to guess about interactions with objects higher > >>> in the stack. > >> Fair enough, the network interface state is a basic thing controlled > >> by the driver, > >> so, should be okay to use. Anyways, the in-driver approach has more > >> control. > >>> > >>> Here is my original patch to fix this, it is not complex. > >>> > >>> https://patchwork.kernel.org/patch/10249363/ > >> Sure, I have shared your patch above :). > > Sent a bit early, any idea why this wasn't upstreamed earlier? > > No, one comment from Michal indicated maybe there were more problems lurking > in this area, but he seemed to be OK with the patch over all. After that, > it was just ignored. > Now might be a good time to push for it :) ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [RFC] ath10k: change to do napi_enable and napi_disable when insmod and rmmod for sdio
On 8/20/20 10:42 AM, Krishna Chaitanya wrote: On Thu, Aug 20, 2020 at 11:11 PM Krishna Chaitanya wrote: On Thu, Aug 20, 2020 at 10:38 PM Ben Greear wrote: On 8/20/20 10:00 AM, Krishna Chaitanya wrote: On Thu, Aug 20, 2020 at 10:02 PM Ben Greear wrote: On 8/20/20 9:08 AM, Krishna Chaitanya wrote: On Thu, Aug 20, 2020 at 8:07 PM Wen Gong wrote: On 2020-08-20 18:52, Krishna Chaitanya wrote: On Thu, Aug 20, 2020 at 3:45 PM Wen Gong wrote: On 2020-08-20 17:19, Krishna Chaitanya wrote: ... I'm not really convinced that this is the right fix, but I'm no NAPI expert. Can anyone else help? Calling napi_disable() twice can lead to hangs, but moving NAPI from start/stop to the probe isn't the right approach as the datapath is tied to start/stop. Maybe check the state of NAPI before disable? if (test_bit(NAPI_STATE_SCHED, >napi.napi.state)) napi_disable(>napi) or maintain napi_state like this https://patchwork.kernel.org/patch/10249365/ it is better to use above link's patch. napi.state is controlled by napi API, it is better ath10k not know it. Sure, but IMHO just canceling the async rx work should solve the issue. Oh no, canceling the async rx work will not solve this issue, rx worker ath10k_rx_indication_async_work call napi_schedule, after napi_complete, the NAPI_STATE_SCHED will clear. The issue of this patch is because 2 thread called to hif_stop and NAPI_STATE_SCHED not clear. That fix is still valid and good to have. ndev_stop being called twice is typical scenarios (stop vs rmmod), so just checking the netdev_flags for IFF_UP and returning from hif_Stop should suffice, no? My approach to fix this problem was to add a boolean in ath10k as to whether it had napi enabled or not, and then check that before trying to enable/disable it again. Seems to work fine, and cleaner in my mind than checking internal napi flags. A much simpler approach is just to check for IFF_UP and skip NAPI (and others) in the hif_stop no? (provided proper RTNL locking is done if hif_stop is being called internally as well). I'm not sure, but I think the driver should be internally consistent and not spend a lot of time trying to guess about interactions with objects higher in the stack. Fair enough, the network interface state is a basic thing controlled by the driver, so, should be okay to use. Anyways, the in-driver approach has more control. Here is my original patch to fix this, it is not complex. https://patchwork.kernel.org/patch/10249363/ Sure, I have shared your patch above :). Sent a bit early, any idea why this wasn't upstreamed earlier? No, one comment from Michal indicated maybe there were more problems lurking in this area, but he seemed to be OK with the patch over all. After that, it was just ignored. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [RFC] ath10k: change to do napi_enable and napi_disable when insmod and rmmod for sdio
On Thu, Aug 20, 2020 at 11:11 PM Krishna Chaitanya wrote: > > On Thu, Aug 20, 2020 at 10:38 PM Ben Greear wrote: > > > > On 8/20/20 10:00 AM, Krishna Chaitanya wrote: > > > On Thu, Aug 20, 2020 at 10:02 PM Ben Greear > > > wrote: > > >> > > >> On 8/20/20 9:08 AM, Krishna Chaitanya wrote: > > >>> On Thu, Aug 20, 2020 at 8:07 PM Wen Gong wrote: > > > > On 2020-08-20 18:52, Krishna Chaitanya wrote: > > > On Thu, Aug 20, 2020 at 3:45 PM Wen Gong wrote: > > >> > > >> On 2020-08-20 17:19, Krishna Chaitanya wrote: > > ... > > I'm not really convinced that this is the right fix, but I'm no > > NAPI > > expert. Can anyone else help? > > >>> Calling napi_disable() twice can lead to hangs, but moving NAPI from > > >>> start/stop to > > >>> the probe isn't the right approach as the datapath is tied to > > >>> start/stop. > > >>> > > >>> Maybe check the state of NAPI before disable? > > >>> > > >>>if (test_bit(NAPI_STATE_SCHED, >napi.napi.state)) > > >>> napi_disable(>napi) > > >>> or maintain napi_state like this > > >>> https://patchwork.kernel.org/patch/10249365/ > > >> it is better to use above link's patch. > > >> napi.state is controlled by napi API, it is better ath10k not know > > >> it. > > > Sure, but IMHO just canceling the async rx work should solve the > > > issue. > > Oh no, canceling the async rx work will not solve this issue, rx worker > > ath10k_rx_indication_async_work call napi_schedule, after > > napi_complete, > > the NAPI_STATE_SCHED will clear. > > The issue of this patch is because 2 thread called to hif_stop and > > NAPI_STATE_SCHED not clear. > > >>> That fix is still valid and good to have. > > >>> > > >>> ndev_stop being called twice is typical scenarios (stop vs rmmod), so > > >>>just checking the netdev_flags for IFF_UP and returning from hif_Stop > > >>> should suffice, no? > > >> > > >> My approach to fix this problem was to add a boolean in ath10k as to > > >> whether > > >> it had napi enabled or not, and then check that before trying to > > >> enable/disable > > >> it again. Seems to work fine, and cleaner in my mind than checking > > >> internal > > >> napi flags. > > > A much simpler approach is just to check for IFF_UP and skip NAPI (and > > > others) > > > in the hif_stop no? (provided proper RTNL locking is done if hif_stop > > > is being called > > > internally as well). > > > > > > > I'm not sure, but I think the driver should be internally consistent and not > > spend a lot of time trying to guess about interactions with objects higher > > in the stack. > Fair enough, the network interface state is a basic thing controlled > by the driver, > so, should be okay to use. Anyways, the in-driver approach has more control. > > > > Here is my original patch to fix this, it is not complex. > > > > https://patchwork.kernel.org/patch/10249363/ > Sure, I have shared your patch above :). Sent a bit early, any idea why this wasn't upstreamed earlier? ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [RFC] ath10k: change to do napi_enable and napi_disable when insmod and rmmod for sdio
On Thu, Aug 20, 2020 at 10:38 PM Ben Greear wrote: > > On 8/20/20 10:00 AM, Krishna Chaitanya wrote: > > On Thu, Aug 20, 2020 at 10:02 PM Ben Greear wrote: > >> > >> On 8/20/20 9:08 AM, Krishna Chaitanya wrote: > >>> On Thu, Aug 20, 2020 at 8:07 PM Wen Gong wrote: > > On 2020-08-20 18:52, Krishna Chaitanya wrote: > > On Thu, Aug 20, 2020 at 3:45 PM Wen Gong wrote: > >> > >> On 2020-08-20 17:19, Krishna Chaitanya wrote: > ... > I'm not really convinced that this is the right fix, but I'm no NAPI > expert. Can anyone else help? > >>> Calling napi_disable() twice can lead to hangs, but moving NAPI from > >>> start/stop to > >>> the probe isn't the right approach as the datapath is tied to > >>> start/stop. > >>> > >>> Maybe check the state of NAPI before disable? > >>> > >>>if (test_bit(NAPI_STATE_SCHED, >napi.napi.state)) > >>> napi_disable(>napi) > >>> or maintain napi_state like this > >>> https://patchwork.kernel.org/patch/10249365/ > >> it is better to use above link's patch. > >> napi.state is controlled by napi API, it is better ath10k not know it. > > Sure, but IMHO just canceling the async rx work should solve the issue. > Oh no, canceling the async rx work will not solve this issue, rx worker > ath10k_rx_indication_async_work call napi_schedule, after napi_complete, > the NAPI_STATE_SCHED will clear. > The issue of this patch is because 2 thread called to hif_stop and > NAPI_STATE_SCHED not clear. > >>> That fix is still valid and good to have. > >>> > >>> ndev_stop being called twice is typical scenarios (stop vs rmmod), so > >>>just checking the netdev_flags for IFF_UP and returning from hif_Stop > >>> should suffice, no? > >> > >> My approach to fix this problem was to add a boolean in ath10k as to > >> whether > >> it had napi enabled or not, and then check that before trying to > >> enable/disable > >> it again. Seems to work fine, and cleaner in my mind than checking > >> internal > >> napi flags. > > A much simpler approach is just to check for IFF_UP and skip NAPI (and > > others) > > in the hif_stop no? (provided proper RTNL locking is done if hif_stop > > is being called > > internally as well). > > > > I'm not sure, but I think the driver should be internally consistent and not > spend a lot of time trying to guess about interactions with objects higher > in the stack. Fair enough, the network interface state is a basic thing controlled by the driver, so, should be okay to use. Anyways, the in-driver approach has more control. > > Here is my original patch to fix this, it is not complex. > > https://patchwork.kernel.org/patch/10249363/ Sure, I have shared your patch above :). ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [RFC] ath10k: change to do napi_enable and napi_disable when insmod and rmmod for sdio
On 8/20/20 10:00 AM, Krishna Chaitanya wrote: On Thu, Aug 20, 2020 at 10:02 PM Ben Greear wrote: On 8/20/20 9:08 AM, Krishna Chaitanya wrote: On Thu, Aug 20, 2020 at 8:07 PM Wen Gong wrote: On 2020-08-20 18:52, Krishna Chaitanya wrote: On Thu, Aug 20, 2020 at 3:45 PM Wen Gong wrote: On 2020-08-20 17:19, Krishna Chaitanya wrote: ... I'm not really convinced that this is the right fix, but I'm no NAPI expert. Can anyone else help? Calling napi_disable() twice can lead to hangs, but moving NAPI from start/stop to the probe isn't the right approach as the datapath is tied to start/stop. Maybe check the state of NAPI before disable? if (test_bit(NAPI_STATE_SCHED, >napi.napi.state)) napi_disable(>napi) or maintain napi_state like this https://patchwork.kernel.org/patch/10249365/ it is better to use above link's patch. napi.state is controlled by napi API, it is better ath10k not know it. Sure, but IMHO just canceling the async rx work should solve the issue. Oh no, canceling the async rx work will not solve this issue, rx worker ath10k_rx_indication_async_work call napi_schedule, after napi_complete, the NAPI_STATE_SCHED will clear. The issue of this patch is because 2 thread called to hif_stop and NAPI_STATE_SCHED not clear. That fix is still valid and good to have. ndev_stop being called twice is typical scenarios (stop vs rmmod), so just checking the netdev_flags for IFF_UP and returning from hif_Stop should suffice, no? My approach to fix this problem was to add a boolean in ath10k as to whether it had napi enabled or not, and then check that before trying to enable/disable it again. Seems to work fine, and cleaner in my mind than checking internal napi flags. A much simpler approach is just to check for IFF_UP and skip NAPI (and others) in the hif_stop no? (provided proper RTNL locking is done if hif_stop is being called internally as well). I'm not sure, but I think the driver should be internally consistent and not spend a lot of time trying to guess about interactions with objects higher in the stack. Here is my original patch to fix this, it is not complex. https://patchwork.kernel.org/patch/10249363/ Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [RFC] ath10k: change to do napi_enable and napi_disable when insmod and rmmod for sdio
On Thu, Aug 20, 2020 at 10:02 PM Ben Greear wrote: > > On 8/20/20 9:08 AM, Krishna Chaitanya wrote: > > On Thu, Aug 20, 2020 at 8:07 PM Wen Gong wrote: > >> > >> On 2020-08-20 18:52, Krishna Chaitanya wrote: > >>> On Thu, Aug 20, 2020 at 3:45 PM Wen Gong wrote: > > On 2020-08-20 17:19, Krishna Chaitanya wrote: > >> ... > >> I'm not really convinced that this is the right fix, but I'm no NAPI > >> expert. Can anyone else help? > > Calling napi_disable() twice can lead to hangs, but moving NAPI from > > start/stop to > > the probe isn't the right approach as the datapath is tied to > > start/stop. > > > > Maybe check the state of NAPI before disable? > > > > if (test_bit(NAPI_STATE_SCHED, >napi.napi.state)) > >napi_disable(>napi) > > or maintain napi_state like this > > https://patchwork.kernel.org/patch/10249365/ > it is better to use above link's patch. > napi.state is controlled by napi API, it is better ath10k not know it. > >>> Sure, but IMHO just canceling the async rx work should solve the issue. > >> Oh no, canceling the async rx work will not solve this issue, rx worker > >> ath10k_rx_indication_async_work call napi_schedule, after napi_complete, > >> the NAPI_STATE_SCHED will clear. > >> The issue of this patch is because 2 thread called to hif_stop and > >> NAPI_STATE_SCHED not clear. > > That fix is still valid and good to have. > > > > ndev_stop being called twice is typical scenarios (stop vs rmmod), so > > just checking the netdev_flags for IFF_UP and returning from hif_Stop > > should suffice, no? > > My approach to fix this problem was to add a boolean in ath10k as to whether > it had napi enabled or not, and then check that before trying to > enable/disable > it again. Seems to work fine, and cleaner in my mind than checking internal > napi flags. A much simpler approach is just to check for IFF_UP and skip NAPI (and others) in the hif_stop no? (provided proper RTNL locking is done if hif_stop is being called internally as well). ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [RFC] ath10k: change to do napi_enable and napi_disable when insmod and rmmod for sdio
On 8/20/20 9:08 AM, Krishna Chaitanya wrote: On Thu, Aug 20, 2020 at 8:07 PM Wen Gong wrote: On 2020-08-20 18:52, Krishna Chaitanya wrote: On Thu, Aug 20, 2020 at 3:45 PM Wen Gong wrote: On 2020-08-20 17:19, Krishna Chaitanya wrote: ... I'm not really convinced that this is the right fix, but I'm no NAPI expert. Can anyone else help? Calling napi_disable() twice can lead to hangs, but moving NAPI from start/stop to the probe isn't the right approach as the datapath is tied to start/stop. Maybe check the state of NAPI before disable? if (test_bit(NAPI_STATE_SCHED, >napi.napi.state)) napi_disable(>napi) or maintain napi_state like this https://patchwork.kernel.org/patch/10249365/ it is better to use above link's patch. napi.state is controlled by napi API, it is better ath10k not know it. Sure, but IMHO just canceling the async rx work should solve the issue. Oh no, canceling the async rx work will not solve this issue, rx worker ath10k_rx_indication_async_work call napi_schedule, after napi_complete, the NAPI_STATE_SCHED will clear. The issue of this patch is because 2 thread called to hif_stop and NAPI_STATE_SCHED not clear. That fix is still valid and good to have. ndev_stop being called twice is typical scenarios (stop vs rmmod), so just checking the netdev_flags for IFF_UP and returning from hif_Stop should suffice, no? My approach to fix this problem was to add a boolean in ath10k as to whether it had napi enabled or not, and then check that before trying to enable/disable it again. Seems to work fine, and cleaner in my mind than checking internal napi flags. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [RFC] ath10k: change to do napi_enable and napi_disable when insmod and rmmod for sdio
On Thu, Aug 20, 2020 at 8:07 PM Wen Gong wrote: > > On 2020-08-20 18:52, Krishna Chaitanya wrote: > > On Thu, Aug 20, 2020 at 3:45 PM Wen Gong wrote: > >> > >> On 2020-08-20 17:19, Krishna Chaitanya wrote: > ... > >> >> I'm not really convinced that this is the right fix, but I'm no NAPI > >> >> expert. Can anyone else help? > >> > Calling napi_disable() twice can lead to hangs, but moving NAPI from > >> > start/stop to > >> > the probe isn't the right approach as the datapath is tied to > >> > start/stop. > >> > > >> > Maybe check the state of NAPI before disable? > >> > > >> > if (test_bit(NAPI_STATE_SCHED, >napi.napi.state)) > >> > napi_disable(>napi) > >> > or maintain napi_state like this > >> > https://patchwork.kernel.org/patch/10249365/ > >> it is better to use above link's patch. > >> napi.state is controlled by napi API, it is better ath10k not know it. > > Sure, but IMHO just canceling the async rx work should solve the issue. > Oh no, canceling the async rx work will not solve this issue, rx worker > ath10k_rx_indication_async_work call napi_schedule, after napi_complete, > the NAPI_STATE_SCHED will clear. > The issue of this patch is because 2 thread called to hif_stop and > NAPI_STATE_SCHED not clear. That fix is still valid and good to have. ndev_stop being called twice is typical scenarios (stop vs rmmod), so just checking the netdev_flags for IFF_UP and returning from hif_Stop should suffice, no? ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [RFC] ath10k: change to do napi_enable and napi_disable when insmod and rmmod for sdio
On 2020-08-20 18:52, Krishna Chaitanya wrote: On Thu, Aug 20, 2020 at 3:45 PM Wen Gong wrote: On 2020-08-20 17:19, Krishna Chaitanya wrote: ... >> I'm not really convinced that this is the right fix, but I'm no NAPI >> expert. Can anyone else help? > Calling napi_disable() twice can lead to hangs, but moving NAPI from > start/stop to > the probe isn't the right approach as the datapath is tied to > start/stop. > > Maybe check the state of NAPI before disable? > > if (test_bit(NAPI_STATE_SCHED, >napi.napi.state)) > napi_disable(>napi) > or maintain napi_state like this > https://patchwork.kernel.org/patch/10249365/ it is better to use above link's patch. napi.state is controlled by napi API, it is better ath10k not know it. Sure, but IMHO just canceling the async rx work should solve the issue. Oh no, canceling the async rx work will not solve this issue, rx worker ath10k_rx_indication_async_work call napi_schedule, after napi_complete, the NAPI_STATE_SCHED will clear. The issue of this patch is because 2 thread called to hif_stop and NAPI_STATE_SCHED not clear. ... ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [RFC] ath10k: change to do napi_enable and napi_disable when insmod and rmmod for sdio
On Thu, Aug 20, 2020 at 3:45 PM Wen Gong wrote: > > On 2020-08-20 17:19, Krishna Chaitanya wrote: > ... > >> > diff --git a/drivers/net/wireless/ath/ath10k/sdio.c > >> > b/drivers/net/wireless/ath/ath10k/sdio.c > >> > index 7b894dcaad2e..b71499b171c6 100644 > >> > --- a/drivers/net/wireless/ath/ath10k/sdio.c > >> > +++ b/drivers/net/wireless/ath/ath10k/sdio.c > >> > @@ -1756,8 +1756,6 @@ static int ath10k_sdio_hif_start(struct ath10k *ar) > >> > struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar); > >> > int ret; > >> > > >> > - napi_enable(>napi); > >> > - > >> > /* Sleep 20 ms before HIF interrupts are disabled. > >> >* This will give target plenty of time to process the BMI done > >> >* request before interrupts are disabled. > >> > @@ -1884,7 +1882,6 @@ static void ath10k_sdio_hif_stop(struct ath10k *ar) > >> > spin_unlock_bh(_sdio->wr_async_lock); > >> > > >> > napi_synchronize(>napi); > >> > - napi_disable(>napi); > >> > } > >> > > >> > #ifdef CONFIG_PM > >> > @@ -2121,6 +2118,7 @@ static int ath10k_sdio_probe(struct sdio_func > >> > *func, > >> > > >> > netif_napi_add(>napi_dev, >napi, ath10k_sdio_napi_poll, > >> > ATH10K_NAPI_BUDGET); > >> > + napi_enable(>napi); > >> > > >> > ath10k_dbg(ar, ATH10K_DBG_BOOT, > >> > "sdio new func %d vendor 0x%x device 0x%x block > >> > 0x%x/0x%x\n", > >> > @@ -2235,6 +2233,7 @@ static void ath10k_sdio_remove(struct sdio_func > >> > *func) > >> > > >> > ath10k_core_unregister(ar); > >> > > >> > + napi_disable(>napi); > >> > netif_napi_del(>napi); > >> > > >> > ath10k_core_destroy(ar); > >> > >> I'm not really convinced that this is the right fix, but I'm no NAPI > >> expert. Can anyone else help? > > Calling napi_disable() twice can lead to hangs, but moving NAPI from > > start/stop to > > the probe isn't the right approach as the datapath is tied to > > start/stop. > > > > Maybe check the state of NAPI before disable? > > > > if (test_bit(NAPI_STATE_SCHED, >napi.napi.state)) > > napi_disable(>napi) > > or maintain napi_state like this > > https://patchwork.kernel.org/patch/10249365/ > it is better to use above link's patch. > napi.state is controlled by napi API, it is better ath10k not know it. Sure, but IMHO just canceling the async rx work should solve the issue. > > Also, the most common cause for such issues (1st > > napi_synchronize/napi_disable hang) > > is that napi_poll is being scheduled, so, you might want to check that > > napi_schedule isn't > > called after stop. > > > > cd ath10k; git log --grep=napi shows plenty of such issues. the one > > that matches closest is > > c2cac2f74ab4bcf0db0dcf3a612f1e5b52d145c8, so, it could just be a > > regression. > This above commit's scene is not same with this patch. > It is hang for only do 1 simulate crash of the commit, this patch is > doing simulate crash and rmmod meanwhile. yes, it is the closest one I could find. ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [RFC] ath10k: change to do napi_enable and napi_disable when insmod and rmmod for sdio
On 2020-08-20 17:26, Krishna Chaitanya wrote: On Thu, Aug 20, 2020 at 2:49 PM Krishna Chaitanya wrote: On Thu, Aug 20, 2020 at 2:03 PM Kalle Valo wrote: > > Wen Gong writes: > ... > I'm not really convinced that this is the right fix, but I'm no NAPI > expert. Can anyone else help? Calling napi_disable() twice can lead to hangs, but moving NAPI from start/stop to the probe isn't the right approach as the datapath is tied to start/stop. Maybe check the state of NAPI before disable? if (test_bit(NAPI_STATE_SCHED, >napi.napi.state)) napi_disable(>napi) or maintain napi_state like this https://patchwork.kernel.org/patch/10249365/ Also, the most common cause for such issues (1st napi_synchronize/napi_disable hang) is that napi_poll is being scheduled, so, you might want to check that napi_schedule isn't called after stop. cd ath10k; git log --grep=napi shows plenty of such issues. the one that matches closest is c2cac2f74ab4bcf0db0dcf3a612f1e5b52d145c8, so, it could just be a regression. Also, I see that napi_schedule() is being called from work_queue async_work_rx so we should cancel that work in hif_stop before calling napi_synchronize. Yes, I will do that in a new patch. ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [RFC] ath10k: change to do napi_enable and napi_disable when insmod and rmmod for sdio
On 2020-08-20 17:19, Krishna Chaitanya wrote: ... > diff --git a/drivers/net/wireless/ath/ath10k/sdio.c b/drivers/net/wireless/ath/ath10k/sdio.c > index 7b894dcaad2e..b71499b171c6 100644 > --- a/drivers/net/wireless/ath/ath10k/sdio.c > +++ b/drivers/net/wireless/ath/ath10k/sdio.c > @@ -1756,8 +1756,6 @@ static int ath10k_sdio_hif_start(struct ath10k *ar) > struct ath10k_sdio *ar_sdio = ath10k_sdio_priv(ar); > int ret; > > - napi_enable(>napi); > - > /* Sleep 20 ms before HIF interrupts are disabled. >* This will give target plenty of time to process the BMI done >* request before interrupts are disabled. > @@ -1884,7 +1882,6 @@ static void ath10k_sdio_hif_stop(struct ath10k *ar) > spin_unlock_bh(_sdio->wr_async_lock); > > napi_synchronize(>napi); > - napi_disable(>napi); > } > > #ifdef CONFIG_PM > @@ -2121,6 +2118,7 @@ static int ath10k_sdio_probe(struct sdio_func *func, > > netif_napi_add(>napi_dev, >napi, ath10k_sdio_napi_poll, > ATH10K_NAPI_BUDGET); > + napi_enable(>napi); > > ath10k_dbg(ar, ATH10K_DBG_BOOT, > "sdio new func %d vendor 0x%x device 0x%x block 0x%x/0x%x\n", > @@ -2235,6 +2233,7 @@ static void ath10k_sdio_remove(struct sdio_func *func) > > ath10k_core_unregister(ar); > > + napi_disable(>napi); > netif_napi_del(>napi); > > ath10k_core_destroy(ar); I'm not really convinced that this is the right fix, but I'm no NAPI expert. Can anyone else help? Calling napi_disable() twice can lead to hangs, but moving NAPI from start/stop to the probe isn't the right approach as the datapath is tied to start/stop. Maybe check the state of NAPI before disable? if (test_bit(NAPI_STATE_SCHED, >napi.napi.state)) napi_disable(>napi) or maintain napi_state like this https://patchwork.kernel.org/patch/10249365/ it is better to use above link's patch. napi.state is controlled by napi API, it is better ath10k not know it. Also, the most common cause for such issues (1st napi_synchronize/napi_disable hang) is that napi_poll is being scheduled, so, you might want to check that napi_schedule isn't called after stop. cd ath10k; git log --grep=napi shows plenty of such issues. the one that matches closest is c2cac2f74ab4bcf0db0dcf3a612f1e5b52d145c8, so, it could just be a regression. This above commit's scene is not same with this patch. It is hang for only do 1 simulate crash of the commit, this patch is doing simulate crash and rmmod meanwhile. ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [RFC] ath10k: change to do napi_enable and napi_disable when insmod and rmmod for sdio
On Thu, Aug 20, 2020 at 2:49 PM Krishna Chaitanya
wrote:
>
> On Thu, Aug 20, 2020 at 2:03 PM Kalle Valo wrote:
> >
> > Wen Gong writes:
> >
> > > It happened "Kernel panic - not syncing: hung_task: blocked tasks" when
> > > test simulate crash and ifconfig down/rmmod meanwhile.
> > >
> > > Test steps:
> > >
> > > 1.Test commands
> > > echo soft >
> > > /sys/kernel/debug/ieee80211/phy0/ath10k/simulate_fw_crash;sleep
> > > 0.05;ifconfig wlan0 down
> > > echo soft >
> > > /sys/kernel/debug/ieee80211/phy0/ath10k/simulate_fw_crash;rmmod
> > > ath10k_sdio
> > >
> > > 2. dmesg:
> > > [ 5622.548630] ath10k_sdio mmc1:0001:1: simulating soft firmware crash
> > > [ 5622.655995] ieee80211 phy0: Hardware restart was requested
> > > [ 5776.355164] INFO: task shill:1572 blocked for more than 122 seconds.
> > > [ 5776.355687] INFO: task kworker/1:2:24437 blocked for more than 122
> > > seconds.
> > > [ 5776.359812] Kernel panic - not syncing: hung_task: blocked tasks
> > > [ 5776.359836] CPU: 1 PID: 55 Comm: khungtaskd Tainted: GW
> > > 4.19.86 #137
> > > [ 5776.359846] Hardware name: MediaTek krane sku176 board (DT)
> > > [ 5776.359855] Call trace:
> > > [ 5776.359868] dump_backtrace+0x0/0x170
> > > [ 5776.359881] show_stack+0x20/0x2c
> > > [ 5776.359896] dump_stack+0xd4/0x10c
> > > [ 5776.359916] panic+0x12c/0x29c
> > > [ 5776.359937] hung_task_panic+0x0/0x50
> > > [ 5776.359953] kthread+0x120/0x130
> > > [ 5776.359965] ret_from_fork+0x10/0x18
> > > [ 5776.359986] SMP: stopping secondary CPUs
> > > [ 5776.360012] Kernel Offset: 0x141ea0 from 0xff800800
> > > [ 5776.360026] CPU features: 0x0,2188200c
> > > [ 5776.360035] Memory Limit: none
> > >
> > > command "ifconfig wlan0 down" or "rmmod ath10k_sdio" will be blocked
> > > callstack of ifconfig:
> > > [<0>] __switch_to+0x120/0x13c
> > > [<0>] msleep+0x28/0x38
> > > [<0>] ath10k_sdio_hif_stop+0x24c/0x294 [ath10k_sdio]
> > > [<0>] ath10k_core_stop+0x50/0x78 [ath10k_core]
> > > [<0>] ath10k_halt+0x120/0x178 [ath10k_core]
> > > [<0>] ath10k_stop+0x4c/0x8c [ath10k_core]
> > > [<0>] drv_stop+0xe0/0x1e4 [mac80211]
> > > [<0>] ieee80211_stop_device+0x48/0x54 [mac80211]
> > > [<0>] ieee80211_do_stop+0x678/0x6f8 [mac80211]
> > > [<0>] ieee80211_stop+0x20/0x30 [mac80211]
> > > [<0>] __dev_close_many+0xb8/0x11c
> > > [<0>] __dev_change_flags+0xe0/0x1d0
> > > [<0>] dev_change_flags+0x30/0x6c
> > > [<0>] devinet_ioctl+0x370/0x564
> > > [<0>] inet_ioctl+0xdc/0x304
> > > [<0>] sock_do_ioctl+0x50/0x288
> > > [<0>] compat_sock_ioctl+0x1b4/0x1aac
> > > [<0>] __se_compat_sys_ioctl+0x100/0x26fc
> > > [<0>] __arm64_compat_sys_ioctl+0x20/0x2c
> > > [<0>] el0_svc_common+0xa4/0x154
> > > [<0>] el0_svc_compat_handler+0x2c/0x38
> > > [<0>] el0_svc_compat+0x8/0x18
> > > [<0>] 0x
> > >
> > > callstack of rmmod:
> > > [<0>] __switch_to+0x120/0x13c
> > > [<0>] msleep+0x28/0x38
> > > [<0>] ath10k_sdio_hif_stop+0x294/0x31c [ath10k_sdio]
> > > [<0>] ath10k_core_stop+0x50/0x78 [ath10k_core]
> > > [<0>] ath10k_halt+0x120/0x178 [ath10k_core]
> > > [<0>] ath10k_stop+0x4c/0x8c [ath10k_core]
> > > [<0>] drv_stop+0xe0/0x1e4 [mac80211]
> > > [<0>] ieee80211_stop_device+0x48/0x54 [mac80211]
> > > [<0>] ieee80211_do_stop+0x678/0x6f8 [mac80211]
> > > [<0>] ieee80211_stop+0x20/0x30 [mac80211]
> > > [<0>] __dev_close_many+0xb8/0x11c
> > > [<0>] dev_close_many+0x70/0x100
> > > [<0>] dev_close+0x4c/0x80
> > > [<0>] cfg80211_shutdown_all_interfaces+0x50/0xcc [cfg80211]
> > > [<0>] ieee80211_remove_interfaces+0x58/0x1a0 [mac80211]
> > > [<0>] ieee80211_unregister_hw+0x40/0x100 [mac80211]
> > > [<0>] ath10k_mac_unregister+0x1c/0x44 [ath10k_core]
> > > [<0>] ath10k_core_unregister+0x38/0x7c [ath10k_core]
> > > [<0>] ath10k_sdio_remove+0x8c/0xd0 [ath10k_sdio]
> > > [<0>] sdio_bus_remove+0x48/0x108
> > > [<0>] device_release_driver_internal+0x138/0x1ec
> > > [<0>] driver_detach+0x6c/0xa8
> > > [<0>] bus_remove_driver+0x78/0xa8
> > > [<0>] driver_unregister+0x30/0x50
> > > [<0>] sdio_unregister_driver+0x28/0x34
> > > [<0>] cleanup_module+0x14/0x6bc [ath10k_sdio]
> > > [<0>] __arm64_sys_delete_module+0x1e0/0x22c
> > > [<0>] el0_svc_common+0xa4/0x154
> > > [<0>] el0_svc_compat_handler+0x2c/0x38
> > > [<0>] el0_svc_compat+0x8/0x18
> > > [<0>] 0x
> > >
> > > The test command run simulate_fw_crash firstly and it call into
> > > ath10k_sdio_hif_stop from ath10k_core_restart, then napi_disable
> > > is called and bit NAPI_STATE_SCHED is set. After that, function
> > > ath10k_sdio_hif_stop is called again from ath10k_stop by command
> > > "ifconfig wlan0 down" or "rmmod ath10k_sdio", then command blocked.
> > >
> > > It is blocked by napi_synchronize, napi_disable will set bit with
> > > NAPI_STATE_SCHED, and then napi_synchronize will enter dead loop
> > > becuase bit NAPI_STATE_SCHED is set by napi_disable.
> > >
> > > function of napi_synchronize
> > > static inline void napi_synchronize(const struct napi_struct *n)
> > > {
> > > if
Re: [PATCH v4 1/2] ath10k: add refcount for ath10k_core_restart
On 2020-08-15 01:19, Kalle Valo wrote:
...
I have been thinking a different approach for this. I think another
option is to have a function like this:
ath10k_core_firmware_crashed()
{
queue_work(ar->workqueue, >restart_work);
}
In patch 1 we would convert all existing callers to call that
function instead of queue_work() directly.
In patch 2 we would add a new flag to enum ath10k_dev_flags, or maybe
should actually use existing ATH10K_FLAG_CRASH_FLUSH? Don't know yet
which one is better. Now the function would do:
I thinks we can use test_and_set_bit for atomic operation athough it is
same with restart_count.
and add a new flag, ATH10K_FLAG_CRASH_FLUSH is used for flush,
if still use ATH10K_FLAG_CRASH_FLUSH, it should change clear_bit of it
from
ath10k_core_start to ath10k_reconfig_complete,because
ieee80211_reconfig(called by
ieee80211_restart_work)
of mac80211 do many things and drv_start is 1st thing and
drv_reconfig_complete is last thing, drv_reconfig_complete done means
the restart
finished.
I will send patch v5 with above changes if not other advise.
ath10k_core_firmware_crashed()
{
if (test_bit(flag))
return
set_bit(flag)
queue_work(ar->workqueue, >restart_work);
}
That way restart_work queue would be called only one time.
Though I'm not sure how ATH10K_STATE_WEDGED would behave after this
change, it might get broken. Ah, actually I think even this patch
breaks
the WEDGED state. This firmware restart is tricky, difficult to say
what
is the best approach. Michal, are you reading? :) Any ideas?
And after looking more about this patch I don't see the need for the
new
ar->restart_count atomic variable. Checking for ATH10K_FLAG_CRASH_FLUSH
would do the same thing AFAICS.
And related to this, (in a separate patch) I think we should utilise
ATH10K_FLAG_CRASH_FLUSH more. For example in ath10k_wmi_cmd_send() to
not even try to send a WMI command if the flag is set. Basically all
hardware access should be disabled except what is needed to restart the
firmware.
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
Re: [RFC] ath10k: change to do napi_enable and napi_disable when insmod and rmmod for sdio
On Thu, Aug 20, 2020 at 2:03 PM Kalle Valo wrote:
>
> Wen Gong writes:
>
> > It happened "Kernel panic - not syncing: hung_task: blocked tasks" when
> > test simulate crash and ifconfig down/rmmod meanwhile.
> >
> > Test steps:
> >
> > 1.Test commands
> > echo soft > /sys/kernel/debug/ieee80211/phy0/ath10k/simulate_fw_crash;sleep
> > 0.05;ifconfig wlan0 down
> > echo soft > /sys/kernel/debug/ieee80211/phy0/ath10k/simulate_fw_crash;rmmod
> > ath10k_sdio
> >
> > 2. dmesg:
> > [ 5622.548630] ath10k_sdio mmc1:0001:1: simulating soft firmware crash
> > [ 5622.655995] ieee80211 phy0: Hardware restart was requested
> > [ 5776.355164] INFO: task shill:1572 blocked for more than 122 seconds.
> > [ 5776.355687] INFO: task kworker/1:2:24437 blocked for more than 122
> > seconds.
> > [ 5776.359812] Kernel panic - not syncing: hung_task: blocked tasks
> > [ 5776.359836] CPU: 1 PID: 55 Comm: khungtaskd Tainted: GW
> > 4.19.86 #137
> > [ 5776.359846] Hardware name: MediaTek krane sku176 board (DT)
> > [ 5776.359855] Call trace:
> > [ 5776.359868] dump_backtrace+0x0/0x170
> > [ 5776.359881] show_stack+0x20/0x2c
> > [ 5776.359896] dump_stack+0xd4/0x10c
> > [ 5776.359916] panic+0x12c/0x29c
> > [ 5776.359937] hung_task_panic+0x0/0x50
> > [ 5776.359953] kthread+0x120/0x130
> > [ 5776.359965] ret_from_fork+0x10/0x18
> > [ 5776.359986] SMP: stopping secondary CPUs
> > [ 5776.360012] Kernel Offset: 0x141ea0 from 0xff800800
> > [ 5776.360026] CPU features: 0x0,2188200c
> > [ 5776.360035] Memory Limit: none
> >
> > command "ifconfig wlan0 down" or "rmmod ath10k_sdio" will be blocked
> > callstack of ifconfig:
> > [<0>] __switch_to+0x120/0x13c
> > [<0>] msleep+0x28/0x38
> > [<0>] ath10k_sdio_hif_stop+0x24c/0x294 [ath10k_sdio]
> > [<0>] ath10k_core_stop+0x50/0x78 [ath10k_core]
> > [<0>] ath10k_halt+0x120/0x178 [ath10k_core]
> > [<0>] ath10k_stop+0x4c/0x8c [ath10k_core]
> > [<0>] drv_stop+0xe0/0x1e4 [mac80211]
> > [<0>] ieee80211_stop_device+0x48/0x54 [mac80211]
> > [<0>] ieee80211_do_stop+0x678/0x6f8 [mac80211]
> > [<0>] ieee80211_stop+0x20/0x30 [mac80211]
> > [<0>] __dev_close_many+0xb8/0x11c
> > [<0>] __dev_change_flags+0xe0/0x1d0
> > [<0>] dev_change_flags+0x30/0x6c
> > [<0>] devinet_ioctl+0x370/0x564
> > [<0>] inet_ioctl+0xdc/0x304
> > [<0>] sock_do_ioctl+0x50/0x288
> > [<0>] compat_sock_ioctl+0x1b4/0x1aac
> > [<0>] __se_compat_sys_ioctl+0x100/0x26fc
> > [<0>] __arm64_compat_sys_ioctl+0x20/0x2c
> > [<0>] el0_svc_common+0xa4/0x154
> > [<0>] el0_svc_compat_handler+0x2c/0x38
> > [<0>] el0_svc_compat+0x8/0x18
> > [<0>] 0x
> >
> > callstack of rmmod:
> > [<0>] __switch_to+0x120/0x13c
> > [<0>] msleep+0x28/0x38
> > [<0>] ath10k_sdio_hif_stop+0x294/0x31c [ath10k_sdio]
> > [<0>] ath10k_core_stop+0x50/0x78 [ath10k_core]
> > [<0>] ath10k_halt+0x120/0x178 [ath10k_core]
> > [<0>] ath10k_stop+0x4c/0x8c [ath10k_core]
> > [<0>] drv_stop+0xe0/0x1e4 [mac80211]
> > [<0>] ieee80211_stop_device+0x48/0x54 [mac80211]
> > [<0>] ieee80211_do_stop+0x678/0x6f8 [mac80211]
> > [<0>] ieee80211_stop+0x20/0x30 [mac80211]
> > [<0>] __dev_close_many+0xb8/0x11c
> > [<0>] dev_close_many+0x70/0x100
> > [<0>] dev_close+0x4c/0x80
> > [<0>] cfg80211_shutdown_all_interfaces+0x50/0xcc [cfg80211]
> > [<0>] ieee80211_remove_interfaces+0x58/0x1a0 [mac80211]
> > [<0>] ieee80211_unregister_hw+0x40/0x100 [mac80211]
> > [<0>] ath10k_mac_unregister+0x1c/0x44 [ath10k_core]
> > [<0>] ath10k_core_unregister+0x38/0x7c [ath10k_core]
> > [<0>] ath10k_sdio_remove+0x8c/0xd0 [ath10k_sdio]
> > [<0>] sdio_bus_remove+0x48/0x108
> > [<0>] device_release_driver_internal+0x138/0x1ec
> > [<0>] driver_detach+0x6c/0xa8
> > [<0>] bus_remove_driver+0x78/0xa8
> > [<0>] driver_unregister+0x30/0x50
> > [<0>] sdio_unregister_driver+0x28/0x34
> > [<0>] cleanup_module+0x14/0x6bc [ath10k_sdio]
> > [<0>] __arm64_sys_delete_module+0x1e0/0x22c
> > [<0>] el0_svc_common+0xa4/0x154
> > [<0>] el0_svc_compat_handler+0x2c/0x38
> > [<0>] el0_svc_compat+0x8/0x18
> > [<0>] 0x
> >
> > The test command run simulate_fw_crash firstly and it call into
> > ath10k_sdio_hif_stop from ath10k_core_restart, then napi_disable
> > is called and bit NAPI_STATE_SCHED is set. After that, function
> > ath10k_sdio_hif_stop is called again from ath10k_stop by command
> > "ifconfig wlan0 down" or "rmmod ath10k_sdio", then command blocked.
> >
> > It is blocked by napi_synchronize, napi_disable will set bit with
> > NAPI_STATE_SCHED, and then napi_synchronize will enter dead loop
> > becuase bit NAPI_STATE_SCHED is set by napi_disable.
> >
> > function of napi_synchronize
> > static inline void napi_synchronize(const struct napi_struct *n)
> > {
> > if (IS_ENABLED(CONFIG_SMP))
> > while (test_bit(NAPI_STATE_SCHED, >state))
> > msleep(1);
> > else
> > barrier();
> > }
> >
> > function of napi_disable
> > void napi_disable(struct napi_struct *n)
> > {
> > might_sleep();
> >
Re: [RFC] ath10k: change to do napi_enable and napi_disable when insmod and rmmod for sdio
Wen Gong writes:
> It happened "Kernel panic - not syncing: hung_task: blocked tasks" when
> test simulate crash and ifconfig down/rmmod meanwhile.
>
> Test steps:
>
> 1.Test commands
> echo soft > /sys/kernel/debug/ieee80211/phy0/ath10k/simulate_fw_crash;sleep
> 0.05;ifconfig wlan0 down
> echo soft > /sys/kernel/debug/ieee80211/phy0/ath10k/simulate_fw_crash;rmmod
> ath10k_sdio
>
> 2. dmesg:
> [ 5622.548630] ath10k_sdio mmc1:0001:1: simulating soft firmware crash
> [ 5622.655995] ieee80211 phy0: Hardware restart was requested
> [ 5776.355164] INFO: task shill:1572 blocked for more than 122 seconds.
> [ 5776.355687] INFO: task kworker/1:2:24437 blocked for more than 122 seconds.
> [ 5776.359812] Kernel panic - not syncing: hung_task: blocked tasks
> [ 5776.359836] CPU: 1 PID: 55 Comm: khungtaskd Tainted: GW
> 4.19.86 #137
> [ 5776.359846] Hardware name: MediaTek krane sku176 board (DT)
> [ 5776.359855] Call trace:
> [ 5776.359868] dump_backtrace+0x0/0x170
> [ 5776.359881] show_stack+0x20/0x2c
> [ 5776.359896] dump_stack+0xd4/0x10c
> [ 5776.359916] panic+0x12c/0x29c
> [ 5776.359937] hung_task_panic+0x0/0x50
> [ 5776.359953] kthread+0x120/0x130
> [ 5776.359965] ret_from_fork+0x10/0x18
> [ 5776.359986] SMP: stopping secondary CPUs
> [ 5776.360012] Kernel Offset: 0x141ea0 from 0xff800800
> [ 5776.360026] CPU features: 0x0,2188200c
> [ 5776.360035] Memory Limit: none
>
> command "ifconfig wlan0 down" or "rmmod ath10k_sdio" will be blocked
> callstack of ifconfig:
> [<0>] __switch_to+0x120/0x13c
> [<0>] msleep+0x28/0x38
> [<0>] ath10k_sdio_hif_stop+0x24c/0x294 [ath10k_sdio]
> [<0>] ath10k_core_stop+0x50/0x78 [ath10k_core]
> [<0>] ath10k_halt+0x120/0x178 [ath10k_core]
> [<0>] ath10k_stop+0x4c/0x8c [ath10k_core]
> [<0>] drv_stop+0xe0/0x1e4 [mac80211]
> [<0>] ieee80211_stop_device+0x48/0x54 [mac80211]
> [<0>] ieee80211_do_stop+0x678/0x6f8 [mac80211]
> [<0>] ieee80211_stop+0x20/0x30 [mac80211]
> [<0>] __dev_close_many+0xb8/0x11c
> [<0>] __dev_change_flags+0xe0/0x1d0
> [<0>] dev_change_flags+0x30/0x6c
> [<0>] devinet_ioctl+0x370/0x564
> [<0>] inet_ioctl+0xdc/0x304
> [<0>] sock_do_ioctl+0x50/0x288
> [<0>] compat_sock_ioctl+0x1b4/0x1aac
> [<0>] __se_compat_sys_ioctl+0x100/0x26fc
> [<0>] __arm64_compat_sys_ioctl+0x20/0x2c
> [<0>] el0_svc_common+0xa4/0x154
> [<0>] el0_svc_compat_handler+0x2c/0x38
> [<0>] el0_svc_compat+0x8/0x18
> [<0>] 0x
>
> callstack of rmmod:
> [<0>] __switch_to+0x120/0x13c
> [<0>] msleep+0x28/0x38
> [<0>] ath10k_sdio_hif_stop+0x294/0x31c [ath10k_sdio]
> [<0>] ath10k_core_stop+0x50/0x78 [ath10k_core]
> [<0>] ath10k_halt+0x120/0x178 [ath10k_core]
> [<0>] ath10k_stop+0x4c/0x8c [ath10k_core]
> [<0>] drv_stop+0xe0/0x1e4 [mac80211]
> [<0>] ieee80211_stop_device+0x48/0x54 [mac80211]
> [<0>] ieee80211_do_stop+0x678/0x6f8 [mac80211]
> [<0>] ieee80211_stop+0x20/0x30 [mac80211]
> [<0>] __dev_close_many+0xb8/0x11c
> [<0>] dev_close_many+0x70/0x100
> [<0>] dev_close+0x4c/0x80
> [<0>] cfg80211_shutdown_all_interfaces+0x50/0xcc [cfg80211]
> [<0>] ieee80211_remove_interfaces+0x58/0x1a0 [mac80211]
> [<0>] ieee80211_unregister_hw+0x40/0x100 [mac80211]
> [<0>] ath10k_mac_unregister+0x1c/0x44 [ath10k_core]
> [<0>] ath10k_core_unregister+0x38/0x7c [ath10k_core]
> [<0>] ath10k_sdio_remove+0x8c/0xd0 [ath10k_sdio]
> [<0>] sdio_bus_remove+0x48/0x108
> [<0>] device_release_driver_internal+0x138/0x1ec
> [<0>] driver_detach+0x6c/0xa8
> [<0>] bus_remove_driver+0x78/0xa8
> [<0>] driver_unregister+0x30/0x50
> [<0>] sdio_unregister_driver+0x28/0x34
> [<0>] cleanup_module+0x14/0x6bc [ath10k_sdio]
> [<0>] __arm64_sys_delete_module+0x1e0/0x22c
> [<0>] el0_svc_common+0xa4/0x154
> [<0>] el0_svc_compat_handler+0x2c/0x38
> [<0>] el0_svc_compat+0x8/0x18
> [<0>] 0x
>
> The test command run simulate_fw_crash firstly and it call into
> ath10k_sdio_hif_stop from ath10k_core_restart, then napi_disable
> is called and bit NAPI_STATE_SCHED is set. After that, function
> ath10k_sdio_hif_stop is called again from ath10k_stop by command
> "ifconfig wlan0 down" or "rmmod ath10k_sdio", then command blocked.
>
> It is blocked by napi_synchronize, napi_disable will set bit with
> NAPI_STATE_SCHED, and then napi_synchronize will enter dead loop
> becuase bit NAPI_STATE_SCHED is set by napi_disable.
>
> function of napi_synchronize
> static inline void napi_synchronize(const struct napi_struct *n)
> {
> if (IS_ENABLED(CONFIG_SMP))
> while (test_bit(NAPI_STATE_SCHED, >state))
> msleep(1);
> else
> barrier();
> }
>
> function of napi_disable
> void napi_disable(struct napi_struct *n)
> {
> might_sleep();
> set_bit(NAPI_STATE_DISABLE, >state);
>
> while (test_and_set_bit(NAPI_STATE_SCHED, >state))
> msleep(1);
> while (test_and_set_bit(NAPI_STATE_NPSVC, >state))
> msleep(1);
>
> hrtimer_cancel(>timer);
>
> clear_bit(NAPI_STATE_DISABLE, >state);
> }
>
> Tested with
[ath6kl:ath-next] BUILD SUCCESS 3c45f21af84eb05a355919abc80cf70a3a681cee
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath-next branch HEAD: 3c45f21af84eb05a355919abc80cf70a3a681cee ath10k: sdio: add firmware coredump support elapsed time: 723m configs tested: 89 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig arm pcm027_defconfig armmvebu_v7_defconfig arm pxa168_defconfig powerpc skiroot_defconfig powerpc powernv_defconfig sh ap325rxa_defconfig arc nsimosci_hs_smp_defconfig microblaze mmu_defconfig arm vf610m4_defconfig arm h5000_defconfig mipsnlm_xlp_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a005-20200818 i386 randconfig-a001-20200818 i386 randconfig-a006-20200818 i386 randconfig-a003-20200818 i386 randconfig-a004-20200818 i386 randconfig-a002-20200818 x86_64 randconfig-a013-20200818 x86_64 randconfig-a016-20200818 x86_64 randconfig-a012-20200818 x86_64 randconfig-a011-20200818 x86_64 randconfig-a014-20200818 x86_64 randconfig-a015-20200818 x86_64 randconfig-a015-20200820 x86_64 randconfig-a012-20200820 x86_64 randconfig-a016-20200820 x86_64 randconfig-a014-20200820 x86_64 randconfig-a011-20200820 x86_64 randconfig-a013-20200820 i386 randconfig-a016-20200818 i386 randconfig-a011-20200818 i386 randconfig-a015-20200818 i386 randconfig-a013-20200818 i386 randconfig-a012-20200818 i386 randconfig-a014-20200818 i386 randconfig-a016-20200819 i386 randconfig-a011-20200819 i386 randconfig-a015-20200819 i386 randconfig-a013-20200819 i386 randconfig-a012-20200819 i386 randconfig-a014-20200819 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
[ath6kl:ath-qca] BUILD SUCCESS 929043343db1e22814c156692f0b89da9008be6b
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath-qca branch HEAD: 929043343db1e22814c156692f0b89da9008be6b Merge branch 'ath-next' into ath-qca elapsed time: 723m configs tested: 83 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig powerpc powernv_defconfig arm pcm027_defconfig armmvebu_v7_defconfig arm pxa168_defconfig powerpc skiroot_defconfig sh ap325rxa_defconfig arc nsimosci_hs_smp_defconfig microblaze mmu_defconfig arm vf610m4_defconfig arm h5000_defconfig mipsnlm_xlp_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a005-20200818 i386 randconfig-a001-20200818 i386 randconfig-a006-20200818 i386 randconfig-a003-20200818 i386 randconfig-a004-20200818 i386 randconfig-a002-20200818 x86_64 randconfig-a013-20200818 x86_64 randconfig-a016-20200818 x86_64 randconfig-a012-20200818 x86_64 randconfig-a011-20200818 x86_64 randconfig-a014-20200818 x86_64 randconfig-a015-20200818 x86_64 randconfig-a015-20200820 x86_64 randconfig-a012-20200820 x86_64 randconfig-a016-20200820 x86_64 randconfig-a014-20200820 x86_64 randconfig-a011-20200820 x86_64 randconfig-a013-20200820 i386 randconfig-a016-20200818 i386 randconfig-a011-20200818 i386 randconfig-a015-20200818 i386 randconfig-a013-20200818 i386 randconfig-a012-20200818 i386 randconfig-a014-20200818 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
[ath6kl:master] BUILD SUCCESS 248337586a5095dce4515a8d24acd207d9054bbb
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git master branch HEAD: 248337586a5095dce4515a8d24acd207d9054bbb Add localversion-wireless-testing-ath elapsed time: 722m configs tested: 89 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig arm pcm027_defconfig armmvebu_v7_defconfig arm pxa168_defconfig powerpc skiroot_defconfig powerpc powernv_defconfig sh ap325rxa_defconfig arc nsimosci_hs_smp_defconfig microblaze mmu_defconfig arm vf610m4_defconfig arm h5000_defconfig mipsnlm_xlp_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a005-20200818 i386 randconfig-a001-20200818 i386 randconfig-a006-20200818 i386 randconfig-a003-20200818 i386 randconfig-a004-20200818 i386 randconfig-a002-20200818 x86_64 randconfig-a013-20200818 x86_64 randconfig-a016-20200818 x86_64 randconfig-a012-20200818 x86_64 randconfig-a011-20200818 x86_64 randconfig-a014-20200818 x86_64 randconfig-a015-20200818 x86_64 randconfig-a015-20200820 x86_64 randconfig-a012-20200820 x86_64 randconfig-a016-20200820 x86_64 randconfig-a014-20200820 x86_64 randconfig-a011-20200820 x86_64 randconfig-a013-20200820 i386 randconfig-a016-20200818 i386 randconfig-a011-20200818 i386 randconfig-a015-20200818 i386 randconfig-a013-20200818 i386 randconfig-a012-20200818 i386 randconfig-a014-20200818 i386 randconfig-a016-20200819 i386 randconfig-a011-20200819 i386 randconfig-a015-20200819 i386 randconfig-a013-20200819 i386 randconfig-a012-20200819 i386 randconfig-a014-20200819 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
[ath6kl:master-pending] BUILD SUCCESS 7cdcc832632673f6f91995863604af95ed4bc353
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git master-pending branch HEAD: 7cdcc832632673f6f91995863604af95ed4bc353 Merge branch 'pending' into master-pending elapsed time: 723m configs tested: 83 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig arm pcm027_defconfig armmvebu_v7_defconfig arm pxa168_defconfig powerpc skiroot_defconfig powerpc powernv_defconfig sh ap325rxa_defconfig arc nsimosci_hs_smp_defconfig microblaze mmu_defconfig arm vf610m4_defconfig arm h5000_defconfig mipsnlm_xlp_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a005-20200818 i386 randconfig-a001-20200818 i386 randconfig-a006-20200818 i386 randconfig-a003-20200818 i386 randconfig-a004-20200818 i386 randconfig-a002-20200818 x86_64 randconfig-a013-20200818 x86_64 randconfig-a016-20200818 x86_64 randconfig-a012-20200818 x86_64 randconfig-a011-20200818 x86_64 randconfig-a014-20200818 x86_64 randconfig-a015-20200818 x86_64 randconfig-a015-20200820 x86_64 randconfig-a012-20200820 x86_64 randconfig-a016-20200820 x86_64 randconfig-a014-20200820 x86_64 randconfig-a011-20200820 x86_64 randconfig-a013-20200820 i386 randconfig-a016-20200818 i386 randconfig-a011-20200818 i386 randconfig-a015-20200818 i386 randconfig-a013-20200818 i386 randconfig-a012-20200818 i386 randconfig-a014-20200818 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
[ath6kl:pending] BUILD SUCCESS 75f2996f481bea32ae6ae1e503157c04ea7ab955
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git pending branch HEAD: 75f2996f481bea32ae6ae1e503157c04ea7ab955 wcn36xx: Fix software-driven scan elapsed time: 723m configs tested: 89 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig powerpc powernv_defconfig arm pcm027_defconfig armmvebu_v7_defconfig arm pxa168_defconfig powerpc skiroot_defconfig sh ap325rxa_defconfig arc nsimosci_hs_smp_defconfig microblaze mmu_defconfig arm vf610m4_defconfig arm h5000_defconfig mipsnlm_xlp_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386defconfig mips allyesconfig mips allmodconfig powerpc defconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a005-20200818 i386 randconfig-a001-20200818 i386 randconfig-a006-20200818 i386 randconfig-a003-20200818 i386 randconfig-a004-20200818 i386 randconfig-a002-20200818 x86_64 randconfig-a013-20200818 x86_64 randconfig-a016-20200818 x86_64 randconfig-a012-20200818 x86_64 randconfig-a011-20200818 x86_64 randconfig-a014-20200818 x86_64 randconfig-a015-20200818 x86_64 randconfig-a015-20200820 x86_64 randconfig-a012-20200820 x86_64 randconfig-a016-20200820 x86_64 randconfig-a014-20200820 x86_64 randconfig-a011-20200820 x86_64 randconfig-a013-20200820 i386 randconfig-a016-20200818 i386 randconfig-a011-20200818 i386 randconfig-a015-20200818 i386 randconfig-a013-20200818 i386 randconfig-a012-20200818 i386 randconfig-a014-20200818 i386 randconfig-a016-20200819 i386 randconfig-a011-20200819 i386 randconfig-a015-20200819 i386 randconfig-a013-20200819 i386 randconfig-a012-20200819 i386 randconfig-a014-20200819 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig x86_64 rhel x86_64 allyesconfig x86_64rhel-7.6-kselftests x86_64 defconfig x86_64 rhel-8.3 x86_64 kexec --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
