On 31/03/2021 12:41, Joakim Zhang wrote:
... >> In answer to your question, resuming from suspend does work on this board >> without your change. We have been testing suspend/resume now on this board >> since Linux v5.8 and so we have the ability to bisect such regressions. So >> it is >> clear to me that this is the change that caused this, but I am not sure why. > > Yes, I know this issue is regression caused by my patch. I just want to > analyze the potential reasons. Due to the code change only related to the > page recycle and reallocate. > So I guess if this page operate need IOMMU works when IOMMU is enabled. Could > you help check if IOMMU driver resume before STMMAC? Our common desire is to > find the root cause, right? Yes of course that is the desire here indeed. I had assumed that the suspend/resume order was good because we have never seen any problems, but nonetheless it is always good to check. Using ftrace I enabled tracing of the appropriate suspend/resume functions and this is what I see ... # tracer: function # # entries-in-buffer/entries-written: 4/4 #P:6 # # _-----=> irqs-off # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # ||| / delay # TASK-PID CPU# |||| TIMESTAMP FUNCTION # | | | |||| | | rtcwake-748 [000] ...1 536.700777: stmmac_pltfr_suspend <-platform_pm_suspend rtcwake-748 [000] ...1 536.735532: arm_smmu_pm_suspend <-platform_pm_suspend rtcwake-748 [000] ...1 536.757290: arm_smmu_pm_resume <-platform_pm_resume rtcwake-748 [003] ...1 536.856771: stmmac_pltfr_resume <-platform_pm_resume So I don't see any ordering issues that could be causing this. Jon -- nvpublic