I'm hoping having done it right and I can try your first suggestion, but I
really cannot solve this problem by myself: sorry, I have no capabilities
in programming in any known and unknown computer language. Surely, I can
test all the patches you want and report the results but this is the best I
can do. Best regards
Valerio
Il 08/Set/2016 19:25, "Kalle Valo" ha scritto:
> Valerio Passini writes:
>
> > On mercoledì 7 settembre 2016 11:32:24 CEST Kalle Valo wrote:
> >> Valerio Passini writes:
> >> > I have found some connection problems since 4.7 release using ath9k
> that
> >> > turn the wifi pretty useless, I think it might be something in the
> power
> >> > management because the signal seems really low. Previously, up to
> kernel
> >> > 4.6.7 everything worked very well.
> >> >
> >> > This is a sample of dmesg in kernel 4.7.2:
> >> > 239.898935] wlp4s0: authenticate with XX:XX:XX:XX:XX:XX
> >> >
> >> > [ 239.919995] wlp4s0: send auth to XX:XX:XX:XX:XX:XX (try 1/3)
> >> > [ 239.931877] wlp4s0: authenticated
> >> > [ 239.932357] wlp4s0: associate with XX:XX:XX:XX:XX:XX (try 1/3)
> >> > [ 239.942171] wlp4s0: RX AssocResp from XX:XX:XX:XX:XX:XX
> (capab=0x431
> >> > status=0 aid=2)
> >> > [ 239.942301] wlp4s0: associated
> >> > [ 244.802853] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x0024
> >> > AR_DIAG_SW=0x0220 DMADBG_7=0x
> >> > 6100
> >> > [ 245.931832] wlp4s0: authenticate with XX:XX:XX:XX:XX:XX
> >> > [ 245.953028] wlp4s0: send auth to XX:XX:XX:XX:XX:XX (try 1/3)
> >> > [ 245.958702] wlp4s0: authenticated
> >> > [ 245.960386] wlp4s0: associate withXX:XX:XX:XX:XX:XX (try 1/3)
> >> > [ 245.980543] wlp4s0: RX AssocResp from XX:XX:XX:XX:XX:XX
> (capab=0x431
> >> > status=0 aid=2)
> >> >
> >> > lspci on 4.6.7 kernel:
> >> > 04:00.0 Network controller: Qualcomm Atheros AR9485 Wireless Network
> >> > Adapter (rev 01)
> >> >
> >> > Subsystem: AzureWave AR9485 Wireless Network Adapter
> >> > Flags: bus master, fast devsel, latency 0, IRQ 18
> >> > Memory at f790 (64-bit, non-prefetchable) [size=512K]
> >> > Expansion ROM at f798 [disabled] [size=64K]
> >> > Capabilities: [40] Power Management version 2
> >> > Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
> >> > Capabilities: [70] Express Endpoint, MSI 00
> >> > Capabilities: [100] Advanced Error Reporting
> >> > Capabilities: [140] Virtual Channel
> >> > Capabilities: [160] Device Serial Number
> 00-00-00-00-00-00-00-00
> >> > Kernel driver in use: ath9k
> >> > Kernel modules: ath9k
> >> >
> >> > Probably you need some debugging output, but before recompiling the
> kernel
> >> > I would like to know if you are interested in any kind of help from me
> >> > and what steps I should take (I'm able to help in testing patches but
> I'm
> >> > not familiar with git). Thank you
> >>
> >> Usually it's really helpful if you can find the commit id which broke
> >> it. 'git bisect' is a great tool to do that and this seems to be a nice
> >> tutorial how to use it:
> >>
> >> http://webchick.net/node/99
> >>
> >> Instead of commit ids you can use release tags like v4.6 and v4.7 to
> >> make it easier to start the bisect. Just make sure that v4.7 is really
> >> broken and v4.6 works before you start the bisection.
> >
> > Hi Kalle,
> >
> > I tried to understand the whole procedure related to git and git bisect,
> and
> > this is the first time I try it, so I can have done some mistake. In the
> git
> > log you'll find the commit that could be guilty for the behaviour I
> reported
> > yesterday. Anyhow, the resulting commit doesn't make any sense to me.
>
> So your bisect found this as the bad commit:
>
> commit 9257b4a206fc0229dd5f84b78e4d1ebf3f91d270
> Author: Omer Peleg
> Date: Wed Apr 20 11:34:11 2016 +0300
>
> iommu/iova: introduce per-cpu caching to iova allocation
>
> The ath9k log you provided has a DMA warning and iommu problems can
> cause DMA problems but I cannot make any conclusions yet. To confirm
> that this commit really is the problem you could try to revert it wit