netdev - Re: stmmac on Banana PI CPU stalls since Linux 6.6

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ufdsvmdz4cac2s6fkvyvzj7gyogg3tlpj6w34vafqhhecfoofg@h6arhapag3t3>
Date: Tue, 23 Jan 2024 00:34:37 +0300
From: "Andrey Jr. Melnikov" <temnota.am@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Marc Haber <mh+netdev@...schlus.de>, alexandre.torgue@...s.st.com, 
	Jose Abreu <joabreu@...opsys.com>, Chen-Yu Tsai <wens@...e.org>, 
	Jernej Skrabec <jernej.skrabec@...il.com>, Samuel Holland <samuel@...lland.org>, 
	Jisheng Zhang <jszhang@...nel.org>, netdev@...r.kernel.org
Subject: Re: stmmac on Banana PI CPU stalls since Linux 6.6

On Sun, Jan 21, 2024 at 10:52:56PM +0100, Andrew Lunn wrote:
> On Sun, Jan 21, 2024 at 09:17:32PM +0100, Marc Haber wrote:
> > Hi,

Hello. I have same symthom on same board.

[skip]
 
> make drivers/net/ethernet/stmicro/stmmac/stmmac_main.lst. You can then
> use whatever it is reporting for:
> 
> PC is at stmmac_get_stats64+0x64/0x20c [stmmac]
> 
> to find where it is in the listing.

root@bpi:~# grep -ah 'PC is at ' /var/log/syslog*
Jan 22 20:13:04 bpi kernel: [256048.826170] PC is at stmmac_get_stats64+0x5c/0x1f8 [stmmac]
Jan 22 20:14:51 bpi kernel: [256156.077831] PC is at stmmac_get_stats64+0x40/0x1f8 [stmmac]
Jan 22 20:15:18 bpi kernel: [256183.687522] PC is at stmmac_get_stats64+0x64/0x1f8 [stmmac]
Jan 17 10:50:44 bpi kernel: [156104.837571] PC is at stmmac_get_stats64+0x4c/0x1f8 [stmmac]
Jan 17 10:51:52 bpi kernel: [156172.085436] PC is at stmmac_get_stats64+0x64/0x1f8 [stmmac]
Jan 17 10:52:37 bpi kernel: [156217.161344] PC is at stmmac_get_stats64+0x64/0x1f8 [stmmac]
Jan 17 10:53:03 bpi kernel: [156243.852175] PC is at stmmac_get_stats64+0x64/0x1f8 [stmmac]
Jan 17 10:54:40 bpi kernel: [156340.689082] PC is at stmmac_get_stats64+0x48/0x1f8 [stmmac]
Jan 17 10:55:07 bpi kernel: [156367.851904] PC is at stmmac_get_stats64+0x50/0x1f8 [stmmac]
Jan 17 10:56:11 bpi kernel: [156431.692860] PC is at stmmac_get_stats64+0x44/0x1f8 [stmmac]
Jan 17 10:56:49 bpi kernel: [156469.648758] PC is at stmmac_get_stats64+0x64/0x1f8 [stmmac]
Jan 17 10:57:15 bpi kernel: [156495.851573] PC is at stmmac_get_stats64+0x64/0x1f8 [stmmac]
Jan 17 10:59:20 bpi kernel: [156620.036359] PC is at stmmac_get_stats64+0x64/0x1f8 [stmmac]
Jan 17 11:00:31 bpi kernel: [156691.276191] PC is at stmmac_get_stats64+0x38/0x1f8 [stmmac]
Jan 17 11:01:07 bpi kernel: [156727.700103] PC is at stmmac_get_stats64+0x40/0x1f8 [stmmac]
Jan 17 11:01:31 bpi kernel: [156751.850926] PC is at stmmac_get_stats64+0x48/0x1f8 [stmmac]

so, PC always after first memory barrier (according to objdump -DS sttmac.ko):

....

00005b6c <stmmac_get_stats64>:
    5b6c:       e92d47f0        push    {r4, r5, r6, r7, r8, r9, sl, lr}
    5b70:       e52de004        push    {lr}            @ (str lr, [sp, #-4]!)
    5b74:       ebfffffe        bl      0 <__gnu_mcount_nc>
    5b78:       e2805a03        add     r5, r0, #12288  @ 0x3000
    5b7c:       e59535c0        ldr     r3, [r5, #1472] @ 0x5c0
    5b80:       e5937078        ldr     r7, [r3, #120]  @ 0x78
    5b84:       e5934074        ldr     r4, [r3, #116]  @ 0x74
    5b88:       e3570000        cmp     r7, #0 // r7 - 
    5b8c:       12802db9        addne   r2, r0, #11840  @ 0x2e40
    5b90:       12822008        addne   r2, r2, #8
    5b94:       13a06000        movne   r6, #0
    5b98:       1a00000b        bne     5bcc <stmmac_get_stats64+0x60>
    5b9c:       ea000026        b       5c3c <stmmac_get_stats64+0xd0>
    5ba0:       f57ff05b        dmb     ish
    5ba4:       e320f000        nop     {0}
    5ba8:       e320f000        nop     {0}
    5bac:       e320f000        nop     {0}
    5bb0:       e320f000        nop     {0}
    5bb4:       e320f000        nop     {0}
    5bb8:       e320f000        nop     {0}
    5bbc:       e320f000        nop     {0}
    5bc0:       e320f000        nop     {0}
    5bc4:       e320f000        nop     {0}
    5bc8:       e320f000        nop     {0}
    5bcc:       e5923000        ldr     r3, [r2]
    5bd0:       e3130001        tst     r3, #1
    5bd4:       1afffff1        bne     5ba0 <stmmac_get_stats64+0x34>
    5bd8:       f57ff05b        dmb     ish

....

it loops in tx stats reading.
 
> Once we know if its the RX or the TX loop, we have a better idea where
> to look for an unbalanced u64_stats_update_begin() /
> u64_stats_update_end().