[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Problems using stock kernel armmp with Marvell 38x hardware.



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

On 25.09.2018 10:45, LinAdmin wrote:
> Hi experts!
>
> I recently bought a NAS with the Marvell Armada 385 dual
> core CPU and 2x 8TB disks. The performance of the hardware
> is excellent but the software from the manufacturer is
> ugly with a rather old kernel (3.10).
>
> I succeeded cross-building a recent 4.9.y kernel using
> kernel config and dts from the manufacturers GPL source
> with Debian Stretch armhf. All this works perfect.
>
> Since I prefer not to repeatedly build a kernel I tried
> using the Debian multi platform kernel 4.9.0-8-armmp. It
> does work, but I was not able to solve the following problems:
>
> a) In the kernel config I used, the buffer management
> CONFIG_MVNETA_BM_ENABLE was set, while in
> config-4.9.0-8-armmp it is not set. This seems to lower
> network throughput by approx. 20%.
>
> Imho all Marvell 38x are capable of using this buffer
> management and therefore it seems preferable to switch it
> on by default?
>
> b) Dmesg always shows "sr_init: platform driver register
> failed for SR". This comes from activated SmartReflex/OMAP
> power management which lacks in all Marvell designs. It
> seems not to have other consequences but I would prefer
> not to see any errors in dmesg.
>
> Many thanks for your help.
>
> LinAdmin
>


Reply to: