netdev - ARM: meson8m2: new board suffering from "rcu_preempt detected stall" / "CPU#n stuck" with stmmac enabled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Fri, 2 Jul 2021 21:55:06 +0200
From:   Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To:     linux-amlogic@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org
Cc:     linux-kernel@...r.kernel.org, rcu@...r.kernel.org,
        netdev@...r.kernel.org,
        Christian Hewitt <christianshewitt@...il.com>
Subject: ARM: meson8m2: new board suffering from "rcu_preempt detected stall"
 / "CPU#n stuck" with stmmac enabled

Hello,

I am currently trying to make mainline Linux run on a device called
WeTek Core [0]
It uses an Amlogic S812 SoC with 4x Cortex-A9 cores and 2GB DDR3.

Enabling the dwmac-meson8b / stmmac Ethernet IP however is giving me
some trouble.
Four out of five times the board hangs during boot when the Ethernet
controller is enabled.
I have attached three boot logs:
- with-twd.txt - the boot process with the TWD timer enabled
- no-twd.txt - the boot process with the TWD timer disabled (since the
first log contained some TWD related bits I wanted to confirm that TWD
is not causing this issue)
- with-twd-successful.txt - uses the very same uImage, dtb and kernel
cmdline as "with-twd.txt" but this time the kernel does not hang

Disabling the Ethernet controller makes it boot every time (I tried it
five times in a row with 100% success rate).
That said, I am not insisting on the fact that the stmmac or
dwmac-meson8b drivers must be at fault. All of my other Meson8b and
Meson8m2 boards (none of them are using the TrustZone firmware) don't
have any Ethernet problems.

I am hoping that someone in the Linux community can share some advice
on how I can debug this issue.

Some background info:
Initially I thought adding support to mainline Linux would be easy.
After failing to read from the eFuse I found out that this board is
running a TrustZone firmware which prevents Linux from reading/writing
some registers.
So far this TrustZone firmware is affecting three areas (for which I
have patches ready):
- booting the secondary cores requires an SMCCC firmware call
- reading/writing the eFuse requires an SMCCC firmware call
- reading the SoC version requires an SMCCC firmware call
- some memory reservations need to be obtained from an SMCCC firmware
call (and then reserved in Linux as well)


Best regards,
Martin


[0] https://kodi.wiki/view/Archive:WeTek_Core

View attachment "with-twd.txt" of type "text/plain" (64434 bytes)

View attachment "with-twd-successful.txt" of type "text/plain" (43127 bytes)

View attachment "no-twd.txt" of type "text/plain" (44420 bytes)