Thanks to hints towards the perf tool I have been able to resolve problem c)
The unacceptable high CPU load in idle periods shown by kworker as armada_370_delay_timer_read is due to the function mmc_rescan not correctly working when there is no card reader hardware or no card present.
When the module sdhci_pxav3 (and evt. sdhci_pltfm & sdhci) is blacklisted the idle load vanishes.
Others with Marvell not experiencing the problem probably did not load that module or have memory cards inserted....
How to analyze such situations?
a) Record some 10 seconds of backtraces on all your CPUs:
Thanks again and regards
On 19.10.2018 16:39, LinAdmin wrote:
Having further investigated the problems of armmp with Marvell I would like to thank Uwe for submitting a patch which resolves problem a). Problem b) arises because code intended only for TI chips gets initialized on Marvell. When disabling in kconfigs "POWER_AVS, POWER_AVS_OMAP, CONFIG_POWER_AVS_OMAP_CLASS3" the red error of sr_init vanishes. My first guess would be that this code should be in a module that can be blacklisted for Marvell? In the meantime I have become aware that there is yet another major problem c): When the system is idle, one CPU is always busy at least 50% with a kworker thread which IMHO does not perform any useful work. When idle, the kernel 4.9.y built exclusively for Marvell has both CPU’s at below 1% load. This additional load is not acceptable and prevents use of the Debian mp-kernel on my Marvell :-( Unfortunately I do not know how to find out what part of code results in this waste... Somehow I start doubting that this kernel has ever been in productive use on Marvell??? LinAdmin