Re: [REGRESSION] stmmac: Random DMA reset failure on RK3399 since v6.18

[Thorsten Leemhuis <regressions@leemhuis.info>]

[+Ovidiu Panait]

On 5/7/26 14:49, Jensen Huang wrote:
> On Tue, May 5, 2026 at 4:26 PM Thorsten Leemhuis
> <regressions@leemhuis.info> wrote:
>> On 4/29/26 14:53, Jensen Huang wrote:
>
>>> I'm reporting a regression on RK3399 (stmmac) observed in v6.18.24.
>>> When a network cable is connected during boot, the DMA reset
>>> occasionally fails with the error message: "Failed to reset the dma".
>>>
>>> This appears to be a timing issue related to the EEE RX clock-stop
>>> logic. Based on my investigation with the RTL8211E PHY, I monitored
>>> the PHY register PS1R (MMD device 3, address 0x01) and observed a
>>> value of 0x0f40. This indicates that the PHY is in LPI mode and the RX
>>> clock may have already stopped.
>>>
>>> While commit dd557266cf5f ("net: stmmac: block PHY RXC clock-stop")
>>
>> Just wondering: have you tried if mainline (e.g. 7.1-rc1) is still
>> affected? This is something that is always a good advisable (some people
>> would call it required). In this case even more, as it since a while
>> contains a fix for the change you mentioned, that wasn't backported:
>> c171e679ee66d7 ("net: stmmac: Disable EEE RX clock stop when VLAN is
>> enabled"). But this is not my area of expertise (and in different area
>> of the code), so that fix might be unrelated to your issue.
> 
> Thanks for the pointer.
> As you suggested, I have tested the mainline and confirmed that the
> issue is not present in v7.1-rc2, nor as early as v6.19-rc1. However,
> I verified that the issue persists in the latest stable v6.18.26.
> I performed a git bisect and the result pointed exactly to the commit
> you mentioned: c171e679ee66d7 ("net: stmmac: Disable EEE RX clock stop
> when VLAN is enabled").

Great! Could you please cherry-pick c171e679ee66d7 to 6.18.y and see if
that fixes things? It sounds like it should.

@Ovidiu Panait: c171e679ee66d7 is a commit of yours. If Jensen confirms
that cherry-picking fixed the problem, I'd say we ask Greg to pick it up
for 6.18.y -- unless you see any reasons why that might be a bad idea.

> Additionally, I tested the case where CONFIG_VLAN_8021Q is not set,
> and the DMA reset issue occurs again.

I'd say that is likely best discussed in a new thread you might want to
start. Also wondering if it was like that earlier. Or iow: if that is a
regression or not.

Ciao, Thorsten

>>> ensures the clock is running before the DMA reset, my tests suggest
>>> that the phylink_rx_clk_stop_block() call might not provide a
>>> sufficiently stable RX clock in time for the immediate DMA reset that
>>> follows.
>>>
>>> Since stmmac already sets mac_requires_rxc = true, I modified
>>> phylink_bringup_phy() to honor this flag. This avoids toggling the
>>> PHY's clk_stop_enable during the initialization sequence, ensuring the
>>> RX clock remains active and stable throughout.
>>> With the change below, I achieved 200/200 successful reboots with the
>>> cable connected (previously ~50% failure rate).
>>>
>>> --- a/drivers/net/phy/phylink.c
>>> +++ b/drivers/net/phy/phylink.c
>>> @@ -2171,7 +2171,7 @@ static int phylink_bringup_phy(struct phylink
>>> *pl, struct phy_device *phy,
>>>      /* Allow the MAC to stop its clock if the PHY has the capability */
>>>      pl->mac_tx_clk_stop = phy_eee_tx_clock_stop_capable(phy) > 0;
>>>
>>> -    if (pl->mac_supports_eee_ops) {
>>> +    if (pl->mac_supports_eee_ops && !pl->config->mac_requires_rxc) {
>>>          /* Explicitly configure whether the PHY is allowed to stop it's
>>>           * receive clock.
>>>           */
>>>
>>> Any feedback/testing on this would be appreciated.
>>>
>>> Best regards,
>>> Jensen Huang
>>>
>>