On 9 October 2014 11:38, Michal Kazior <michal.kazior@xxxxxxxxx> wrote:
> In some cases hw recovery was taking an absurdly
> long time due to ath10k waiting for things that
> would never really complete.
>
> Instead of waiting for inevitable timeouts poke
> all completions and wakequeues and check if it's
> still worth waiting.
>
> Signed-off-by: Michal Kazior <michal.kazior@xxxxxxxxx>
> ---
[...]
> @@ -685,6 +685,20 @@ static void ath10k_core_restart(struct work_struct *work)
> {
> struct ath10k *ar = container_of(work, struct ath10k, restart_work);
>
> + set_bit(ATH10K_FLAG_CRASH_FLUSH, &ar->dev_flags);
> + barrier();
> + ieee80211_stop_queues(ar->hw);
> + ath10k_drain_tx(ar);
> + complete_all(&ar->scan.started);
> + complete_all(&ar->scan.completed);
> + complete_all(&ar->scan.on_channel);
> + complete_all(&ar->offchan_tx_completed);
> + complete_all(&ar->install_key_done);
> + complete_all(&ar->vdev_setup_done);
> + wake_up(&ar->htt.empty_tx_wq);
> + wake_up(&ar->wmi.tx_credits_wq);
> + wake_up(&ar->peer_mapping_wq);
Janusz found a problem with waitqueues. I'll need to move waitqueue
initialization to core_create or else if, e.g. fw probing fails
there's a chance a spurious interrupt will cause the kernel to deref
an invalid pointer.
I'll post a v2 later.
Michał
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
