* Re: [REGRESSION] stmmac: Random DMA reset failure on RK3399 since v6.18
[not found] ` <5308c658-7d4c-4292-b091-a51546ea4d23@leemhuis.info>
@ 2026-05-11 7:35 ` Thorsten Leemhuis
2026-05-11 8:17 ` Greg KH
0 siblings, 1 reply; 2+ messages in thread
From: Thorsten Leemhuis @ 2026-05-11 7:35 UTC (permalink / raw)
To: stable@vger.kernel.org
Cc: Russell King, Heiner Kallweit, Andrew Lunn, regressions, netdev,
LKML, Jensen Huang, Ovidiu Panait
Greg, Sasha, could you please cherry-pick c171e679ee66d7 ("net: stmmac:
Disable EEE RX clock stop when VLAN is enabled") [v6.19-rc1] to 6.18.y?
It fixes a regression for Jensen Huang (for details see below; it was
later confirmed that c171e679ee66d7 really fixes this) caused by
dd557266cf5fb0 ("net: stmmac: block PHY RXC clock-stop") [v6.15-rc1]. tia!
Ciao, Thorsten
On 5/7/26 15:13, Thorsten Leemhuis wrote:
> [+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
>>>>
>>>
>
^ permalink raw reply [flat|nested] 2+ messages in thread