ath10k: freeze after disconnection on killer1525
Michal Kazior
michal.kazior at tieto.com
Mon May 11 06:30:27 PDT 2015
On 11 May 2015 at 14:50, Gabriele Martino <g.martino at gmx.com> wrote:
> Hi,
> I'm using a Killer 1525 with hw2.1 firmware, and sometimes it stop working.
> I can get it working again disconnecting and reconnecting, but sometimes
> on disconnection it freezes for a long time:
>
> [ 2740.035190] dmar: DRHD: handling fault status reg 2
> [ 2740.035195] dmar: DMAR:[DMA Read] Request device [03:00.0] fault addr
> ffbeb000
> DMAR:[fault reason 06] PTE Read access is not
> set
This looks like DMA tx pool memory address. I suspect
firmware/hardware tried to access memory which was already unmapped by
ath10k.
If you're feeling lucky you could disable IOMMU - this should prevent
from crashing and disconnecting. However this is hardly a solution
unless you're okay with the device reading random memory and doing
*stuff* with it (plaintext password from RAM sent on the air, anyone?
:-)
> [ 2797.979143] wlp3s0: deauthenticating from 64:31:50:e9:1c:71 by local
> choice (Reason: 3=DEAUTH_LEAVING)
> [ 2800.979030] ath10k_pci 0000:03:00.0: failed to set PS Mode 0 for vdev
> 0: -11
> [ 2800.979034] ath10k_pci 0000:03:00.0: failed to setup powersave: -11
> [ 2800.979035] ath10k_pci 0000:03:00.0: failed to setup ps on vdev 0: -11
> [ 2805.979025] ath10k_pci 0000:03:00.0: failed to flush transmit queue
> (skip 0 ar-state 1): 0
> [ 2808.979072] ath10k_pci 0000:03:00.0: failed to install key for vdev 0
> peer 64:31:50:e9:1c:71: -11
[...]
> When it freezes, I can't use any command like ifconfig, iwconfig,
> ethtool (they sit there until the freeze ends, ctrl+c is useless).
> I can't even rmmod the ath10k_pci. After about a minute, it works again
> and the freezed commands are executed.
You're experiencing the freeze because there's a lot of command
flow/sequences pending upon device crash. Most of them require locks
so it all serializes into a very long sequence. Combined with RTNL
here and there you can get a major lag on the entire networking
subsystem.
I guess this could be improved but first and foremost device shouldn't
be crashing just like that.
Michał
More information about the ath10k
mailing list