Messages in this thread |  | | From | Jensen Huang <> | | Date | Thu, 7 May 2026 20:49:01 +0800 | | Subject | Re: [REGRESSION] stmmac: Random DMA reset failure on RK3399 since v6.18 |
| |
On Tue, May 5, 2026 at 4:26 PM Thorsten Leemhuis <regressions@leemhuis.info> wrote: > > [Jumping in here, as there are no replies yet] > > BTW, Russel, just in case you missed this: looks like this regressions > caused by a change of yours. > > 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"). Additionally, I tested the case where CONFIG_VLAN_8021Q is not set, and the DMA reset issue occurs again.
Best regards, Jensen Huang
> > 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 > > >
|  |