Re: Stability connection problems in ath9k kernel 4.7
On venerdì 9 settembre 2016 10:38:32 CEST Joerg Roedel wrote: > Hi Valerio, > > On Thu, Sep 08, 2016 at 09:07:56PM +0200, Valerio Passini wrote: > > 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 > > Can you please send me the full dmesg after boot? The Intel-IOMMU is not > enabled by default, so I want to check if it is either enabled by > kernel-config or kernel command-line. > > Thanks, > > Joerg Hi Joerg, It is enabled by kernel config. Indeed, unchecking that option makes the problem disappearing. Valerio Full dmesg as you asked me. [0.00] microcode: microcode updated early to revision 0x20, date = 2016-03-16 [0.00] Linux version 4.7.3 (valerio@Automatix) (gcc version 6.2.0 20160901 (Debian 6.2.0-3) ) #1 SMP PREEMPT Fri Sep 9 16:15:07 CEST 2016 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.7.3 root=UUID=917286ea-e4a0-4a3e-9307-102636ba2a20 ro quiet acpi_osi= [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. [0.00] x86/fpu: Using 'eager' FPU context switches. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x00057fff] usable [0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved [0.00] BIOS-e820: [mem 0x00059000-0x0009dfff] usable [0.00] BIOS-e820: [mem 0x0009e000-0x0009] reserved [0.00] BIOS-e820: [mem 0x0010-0xb5df7fff] usable [0.00] BIOS-e820: [mem 0xb5df8000-0xb5dfefff] ACPI NVS [0.00] BIOS-e820: [mem 0xb5dff000-0xb6719fff] usable [0.00] BIOS-e820: [mem 0xb671a000-0xb69b7fff] reserved [0.00] BIOS-e820: [mem 0xb69b8000-0xc6045fff] usable [0.00] BIOS-e820: [mem 0xc6046000-0xc624] reserved [0.00] BIOS-e820: [mem 0xc625-0xc6402fff] usable [0.00] BIOS-e820: [mem 0xc6403000-0xc6b08fff] ACPI NVS [0.00] BIOS-e820: [mem 0xc6b09000-0xc6f59fff] reserved [0.00] BIOS-e820: [mem 0xc6f5a000-0xc6ffefff] type 20 [0.00] BIOS-e820: [mem 0xc6fff000-0xc6ff] usable [0.00] BIOS-e820: [mem 0xc7c0-0xcfdf] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00022f1f] usable [0.00] NX (Execute Disable) protection: active [0.00] efi: EFI v2.31 by American Megatrends [0.00] efi: ESRT=0xc6f58798 ACPI 2.0=0xc648b000 ACPI=0xc648b000 SMBIOS=0xc6f58398 [0.00] esrt: Reserving ESRT space from 0xc6f58798 to 0xc6f587d0. [0.00] SMBIOS 2.7 present. [0.00] DMI: ASUSTeK COMPUTER INC. N551JW/N551JW, BIOS N551JW.207 08/03/2015 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x22f200 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-E uncachable [0.00] F-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 00 mask 7E write-back [0.00] 1 base 02 mask 7FE000 write-back [0.00] 2 base 022000 mask 7FF000 write-back [0.00] 3 base 00E000 mask 7FE000 uncachable [0.00] 4 base 00D000 mask 7FF000 uncachable [0.00] 5 base 00C800 mask 7FF800 uncachable [0.00] 6 base 00C7C0 mask 7FFFC0 uncachable [0.00] 7 base 022F80 mask 7FFF80 uncachable [0.00] 8 base 022F40
Re: Stability connection problems in ath9k kernel 4.7
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" <kv...@codeaurora.org> ha scritto: > Valerio Passini <valerio.pass...@unicam.it> writes: > > > On mercoledì 7 settembre 2016 11:32:24 CEST Kalle Valo wrote: > >> Valerio Passini <valerio.pass...@unicam.it> 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 <o...@cs.technion.ac.il> > 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
