Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP
Adding regressions list so that this can be tracked properly, including the full report below. Oleksandr Natalenko writes: > Hello. > > The following upstream commits: > > aa6f8dcbab47 swiotlb: rework "fix info leak with DMA_FROM_DEVICE" > ddbd89deb7d3 swiotlb: fix info leak with DMA_FROM_DEVICE > > break ath9k-based Wi-Fi access point for me. The AP emits beacons, but no > client can connect to it, either from the very beginning, or shortly after > start. These are the only symptoms I've noticed (i.e., no BUG/WARNING > messages in `dmesg` etc). > > The hardware is: > > ``` > $ dmesg | grep -i swiotlb > [0.426785] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) > > BIOS Information > Vendor: American Megatrends Inc. > Version: P1.50 > Release Date: 04/16/2018 > > Base Board Information > Manufacturer: ASRock > Product Name: J3710-ITX > > 02:00.0 Network controller: Qualcomm Atheros AR9462 Wireless Network Adapter > (rev 01) > Subsystem: Lite-On Communications Inc Device 6621 > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- DisINTx- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-Latency: 0, Cache Line Size: 64 bytes > Interrupt: pin A routed to IRQ 17 > Region 0: Memory at 8140 (64-bit, non-prefetchable) [size=512K] > Expansion ROM at 8148 [disabled] [size=64K] > Capabilities: [40] Power Management version 2 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA > PME(D0+,D1+,D2+,D3hot+,D3cold+) > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+ > Address: Data: > Masking: Pending: > Capabilities: [70] Express (v2) Endpoint, MSI 00 > DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s > unlimited, L1 <64us > ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- > SlotPowerLimit 10.000W > DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- > RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- > MaxPayload 128 bytes, MaxReadReq 512 bytes > DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ > TransPend- > LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit > Latency L0s <4us, L1 <64us > ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- > LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- > LnkSta: Speed 2.5GT/s (ok), Width x1 (ok) > TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- > DevCap2: Completion Timeout: Not Supported, TimeoutDis+ > NROPrPrP- LTR- >10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- > EETLPPrefix- >EmergencyPowerReduction Not Supported, > EmergencyPowerReductionInit- >FRS- TPHComp- ExtTPHComp- >AtomicOpsCap: 32bit- 64bit- 128bitCAS- > DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- > OBFF Disabled, >AtomicOpsCtl: ReqEn- > LnkCap2: Supported Link Speeds: 2.5GT/s, Crosslink- Retimer- > 2Retimers- DRS- > LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis- >Transmit Margin: Normal Operating Range, > EnterModifiedCompliance- ComplianceSOS- >Compliance De-emphasis: -6dB > LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- > EqualizationPhase1- >EqualizationPhase2- EqualizationPhase3- > LinkEqualizationRequest- >Retimer- 2Retimers- CrosslinkRes: unsupported > Capabilities: [100 v1] Advanced Error Reporting > UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- > RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- > UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- > RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- > UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- > RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- > CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- > AdvNonFatalErr- > CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- > AdvNonFatalErr+ > AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- > ECRCChkCap- ECRCChkEn- > MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- > HeaderLog: > Capabilities: [140 v1] Virtual Channel > Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 > Arb:Fixed- WRR32- WRR64- WRR128- > Ctrl: ArbSelect=Fixed >
Re: [PATCH] [RFC] qcom_scm: hide Kconfig symbol
Arnd Bergmann writes: > From: Arnd Bergmann > > Now that SCM can be a loadable module, we have to add another > dependency to avoid link failures when ipa or adreno-gpu are > built-in: > > aarch64-linux-ld: drivers/net/ipa/ipa_main.o: in function `ipa_probe': > ipa_main.c:(.text+0xfc4): undefined reference to `qcom_scm_is_available' > > ld.lld: error: undefined symbol: qcom_scm_is_available >>>> referenced by adreno_gpu.c >>>> gpu/drm/msm/adreno/adreno_gpu.o:(adreno_zap_shader_load) >>>> in archive drivers/built-in.a > > This can happen when CONFIG_ARCH_QCOM is disabled and we don't select > QCOM_MDT_LOADER, but some other module selects QCOM_SCM. Ideally we'd > use a similar dependency here to what we have for QCOM_RPROC_COMMON, > but that causes dependency loops from other things selecting QCOM_SCM. > > This appears to be an endless problem, so try something different this > time: > > - CONFIG_QCOM_SCM becomes a hidden symbol that nothing 'depends on' >but that is simply selected by all of its users > > - All the stubs in include/linux/qcom_scm.h can go away > > - arm-smccc.h needs to provide a stub for __arm_smccc_smc() to >allow compile-testing QCOM_SCM on all architectures. > > - To avoid a circular dependency chain involving RESET_CONTROLLER >and PINCTRL_SUNXI, change the 'depends on RESET_CONTROLLER' in >the latter one to 'select'. > > The last bit is rather annoying, as drivers should generally never > 'select' another subsystem, and about half the users of the reset > controller interface do this anyway. > > Nevertheless, this version seems to pass all my randconfig tests > and is more robust than any of the prior versions. > > Comments? > > Signed-off-by: Arnd Bergmann [...] > diff --git a/drivers/net/wireless/ath/ath10k/Kconfig > b/drivers/net/wireless/ath/ath10k/Kconfig > index 741289e385d5..ca007b800f75 100644 > --- a/drivers/net/wireless/ath/ath10k/Kconfig > +++ b/drivers/net/wireless/ath/ath10k/Kconfig > @@ -44,7 +44,7 @@ config ATH10K_SNOC > tristate "Qualcomm ath10k SNOC support" > depends on ATH10K > depends on ARCH_QCOM || COMPILE_TEST > - depends on QCOM_SCM || !QCOM_SCM #if QCOM_SCM=m this can't be =y > + select QCOM_SCM > select QCOM_QMI_HELPERS > help > This module adds support for integrated WCN3990 chip connected I assume I can continue to build test ATH10K_SNOC with x86 as before? That's important for me. If yes, then: Acked-by: Kalle Valo -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] dma-mapping: move hint unlikely for dma_mapping_error from drivers to core
Heiner Kallweit writes: > Zillions of drivers use the unlikely() hint when checking the result of > dma_mapping_error(). This is an inline function anyway, so we can move > the hint into the function and remove it from drivers. >>From time to time discussions pop up how effective unlikely() is, > and that it should be used only if something is really very unlikely. > I think that's the case here. > > Patch was created with some help from coccinelle. > > @@ > expression dev, dma_addr; > @@ > > - unlikely(dma_mapping_error(dev, dma_addr)) > + dma_mapping_error(dev, dma_addr) > > Signed-off-by: Heiner Kallweit > --- > If ok, then tbd through which tree this is supposed to go. > Patch is based on linux-next-20201210. > --- [...] > drivers/net/wireless/ath/ath10k/htt_rx.c | 2 +- > drivers/net/wireless/ath/ath10k/pci.c | 2 +- > drivers/net/wireless/ath/ath10k/snoc.c| 2 +- > drivers/net/wireless/ath/ath11k/ce.c | 2 +- > drivers/net/wireless/ath/ath11k/dp_rx.c | 2 +- > drivers/net/wireless/ath/ath5k/base.c | 2 +- > drivers/net/wireless/ath/ath9k/beacon.c | 2 +- > drivers/net/wireless/ath/ath9k/recv.c | 21 +++- > drivers/net/wireless/ath/ath9k/xmit.c | 2 +- > drivers/net/wireless/ath/wil6210/txrx.c | 10 > drivers/net/wireless/ath/wil6210/txrx_edma.c | 4 +-- > drivers/net/wireless/broadcom/b43/dma.c | 2 +- > drivers/net/wireless/broadcom/b43legacy/dma.c | 2 +- > drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 10 > drivers/net/wireless/intel/iwlwifi/queue/tx.c | 10 > drivers/net/wireless/mediatek/mt76/dma.c | 8 +++--- > .../net/wireless/ralink/rt2x00/rt2x00queue.c | 4 +-- For wireless drivers: Acked-by: Kalle Valo -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v5 2/2] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module
+ ath10k list John Stultz writes: > Allow the qcom_scm driver to be loadable as a permenent module. > > This still uses the "depends on QCOM_SCM || !QCOM_SCM" bit to > ensure that drivers that call into the qcom_scm driver are > also built as modules. While not ideal in some cases its the > only safe way I can find to avoid build errors without having > those drivers select QCOM_SCM and have to force it on (as > QCOM_SCM=n can be valid for those drivers). > > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Andy Gross > Cc: Bjorn Andersson > Cc: Joerg Roedel > Cc: Thomas Gleixner > Cc: Jason Cooper > Cc: Marc Zyngier > Cc: Linus Walleij > Cc: Vinod Koul > Cc: Kalle Valo > Cc: Maulik Shah > Cc: Lina Iyer > Cc: Saravana Kannan > Cc: Todd Kjos > Cc: Greg Kroah-Hartman > Cc: linux-arm-...@vger.kernel.org > Cc: iommu@lists.linux-foundation.org > Cc: linux-g...@vger.kernel.org > Acked-by: Greg Kroah-Hartman > Signed-off-by: John Stultz > --- > v3: > * Fix __arm_smccc_smc build issue reported by > kernel test robot > v4: > * Add "depends on QCOM_SCM || !QCOM_SCM" bit to ath10k > config that requires it. > v5: > * Fix QCOM_QCM typo in Kconfig, it should be QCOM_SCM > --- > drivers/firmware/Kconfig| 4 ++-- > drivers/firmware/Makefile | 3 ++- > drivers/firmware/qcom_scm.c | 4 > drivers/iommu/Kconfig | 2 ++ > drivers/net/wireless/ath/ath10k/Kconfig | 1 + > 5 files changed, 11 insertions(+), 3 deletions(-) For ath10k part: Acked-by: Kalle Valo -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 15/20] net: Remove depends on HAS_DMA in case of platform dependency
(adding linux-wireless) Geert Uytterhoeven writes: > Remove dependencies on HAS_DMA where a Kconfig symbol depends on another > symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". > In most cases this other symbol is an architecture or platform specific > symbol, or PCI. > > Generic symbols and drivers without platform dependencies keep their > dependencies on HAS_DMA, to prevent compiling subsystems or drivers that > cannot work anyway. > > This simplifies the dependencies, and allows to improve compile-testing. > > Signed-off-by: Geert Uytterhoeven > Reviewed-by: Mark Brown > Acked-by: Robin Murphy > --- > v3: > - Rebase to v4.17-rc1, > - Drop obsolete note about FSL_FMAN, > > v2: > - Add Reviewed-by, Acked-by, > - Drop RFC state, > - Split per subsystem. > --- > drivers/net/ethernet/amd/Kconfig| 2 +- > drivers/net/ethernet/apm/xgene-v2/Kconfig | 1 - > drivers/net/ethernet/apm/xgene/Kconfig | 1 - > drivers/net/ethernet/arc/Kconfig| 6 -- > drivers/net/ethernet/broadcom/Kconfig | 2 -- > drivers/net/ethernet/calxeda/Kconfig| 2 +- > drivers/net/ethernet/hisilicon/Kconfig | 2 +- > drivers/net/ethernet/marvell/Kconfig| 8 +++- > drivers/net/ethernet/mellanox/mlxsw/Kconfig | 2 +- > drivers/net/ethernet/renesas/Kconfig| 2 -- > drivers/net/wireless/broadcom/brcm80211/Kconfig | 1 - > drivers/net/wireless/quantenna/qtnfmac/Kconfig | 2 +- > 12 files changed, 12 insertions(+), 19 deletions(-) For wireless: Acked-by: Kalle Valo Leaving the hunks for linux-wireless list to see: > diff --git a/drivers/net/wireless/broadcom/brcm80211/Kconfig > b/drivers/net/wireless/broadcom/brcm80211/Kconfig > index 9d99eb42d9176f0f..6acba67bca07abd7 100644 > --- a/drivers/net/wireless/broadcom/brcm80211/Kconfig > +++ b/drivers/net/wireless/broadcom/brcm80211/Kconfig > @@ -60,7 +60,6 @@ config BRCMFMAC_PCIE > bool "PCIE bus interface support for FullMAC driver" > depends on BRCMFMAC > depends on PCI > - depends on HAS_DMA > select BRCMFMAC_PROTO_MSGBUF > select FW_LOADER > ---help--- > diff --git a/drivers/net/wireless/quantenna/qtnfmac/Kconfig > b/drivers/net/wireless/quantenna/qtnfmac/Kconfig > index 025fa6018550895a..8d1492a90bd135c0 100644 > --- a/drivers/net/wireless/quantenna/qtnfmac/Kconfig > +++ b/drivers/net/wireless/quantenna/qtnfmac/Kconfig > @@ -7,7 +7,7 @@ config QTNFMAC > config QTNFMAC_PEARL_PCIE > tristate "Quantenna QSR10g PCIe support" > default n > - depends on HAS_DMA && PCI && CFG80211 > + depends on PCI && CFG80211 > select QTNFMAC > select FW_LOADER > select CRC32 -- Kalle Valo ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: Stability connection problems in ath9k kernel 4.7
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 with 'git revert -n 9257b4a206fc0229dd5f84b78e4d1ebf3f91d270'. For some reason I got conflicts but if you are good enough with C you could try to fix those yourself. Another option is that you disable iommu and see if that helps. I'm adding more people and mailing lists related to this commit, hopefully they have better ideas. This is Valerio's bisect log: git bisect start # good: [2dcd0af568b0cf583645c8a317dd12e344b1c72a] Linux 4.6 git bisect good 2dcd0af568b0cf583645c8a317dd12e344b1c72a # bad: [523d939ef98fd712632d93a5a2b588e477a7565e] Linux 4.7 git bisect bad 523d939ef98fd712632d93a5a2b588e477a7565e # good: [0694f0c9e20c47063e4237e5f6649ae5ce5a369a] radix tree test suite: remove dependencies on height git bisect good 0694f0c9e20c47063e4237e5f6649ae5ce5a369a # good: [e4f7bdc2ec0d0dcc27f7d70db27a62
