Johannes Berg <johan...@sipsolutions.net> writes:
>> ath10k_pci 0000:02:00.0: wmi command 16387 timeout, restarting hardware
>> ath10k_pci 0000:02:00.0: failed to set 5g txpower 23: -11
>> ath10k_pci 0000:02:00.0: failed to setup tx power 23: -11
>> ath10k_pci 0000:02:00.0: failed to recalc tx power: -11
>> ath10k_pci 0000:02:00.0: failed to set inactivity time for vdev 0: -108
>> ath10k_pci 0000:02:00.0: failed to setup powersave: -108
>>
>> That certainly looks like something did try to set a power limit, but
>> eventually failed.
>
> Yeah, that does seem a bit fishy. Kalle would have to comment for
> ath10k.
>
>> Immediately after that:
>>
>> wlp2s0: deauthenticating from 54:ec:2f:05:70:2c by local choice
>> (Reason: 3=DEAUTH_LEAVING)
>
> I don't _think_ any of the above would be a reason to disconnect, but it
> clearly looks like the device got stuck at this point, since everything
> just fails afterwards.
Yeah, to me it looks anything ath10k tries to do with the devie fails,
even resetting the device.
> Looks like indeed the driver gives the device at least *3 seconds* for
> every command, see ath10k_wmi_cmd_send(), so most likely this would
> eventually have finished, but who knows how many firmware commands it
> would still have attempted to send...
3 seconds is a bit short but in normal cases it should be enough. Of
course we could increase the delay but I'm skeptic it would help here.
> Perhaps the driver should mark the device as dead and fail quickly once
> it timed out once, or so, but I'll let Kalle comment on that.
Actually we do try to restart the device when a timeout happens in
ath10k_wmi_cmd_send():
if (ret == -EAGAIN) {
ath10k_warn(ar, "wmi command %d timeout, restarting hardware\n",
cmd_id);
queue_work(ar->workqueue, &ar->restart_work);
}
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
