From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay.yourmailgateway.de (relay.yourmailgateway.de [46.38.247.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 975DE30C37A; Tue, 5 May 2026 08:36:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=46.38.247.119 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777970166; cv=none; b=ecKwQeLQGPvxT/lgPhvfhgu1+9axjyCTNg4TFU30jVyxVIkwjwgdcaoYO7U6X+wnmiNfMu5ozFJAqNwDA4MBGnpBvxLdGig7Ra3XUVViQQWKNB68NuKrWJSg169D1aDSIdHTvZvr3DgX7PZBkG5/7ubIcF7kPOMsxKA4BH1T2CY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777970166; c=relaxed/simple; bh=CWaeVcm00SPOZ3SYrZTELMqqVT5hEgks1+ooT6SplRw=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=fOEKQFY8bjiFZ+dmRjgLTdSHznhl/d5sy0k4Vrk3zkRYzNtKGL0dy/ltOavSL0vOpw4ficIT5KjyW4pEIk/nFZA0iAmOUERne2OpyHwaDKZTwOZ1LDdnaf498Le90TQweTcYeBCYvMJqcg2NAu5zEa5KB0vl0ESokxZQGDb9GnE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=leemhuis.info; spf=pass smtp.mailfrom=leemhuis.info; dkim=pass (2048-bit key) header.d=leemhuis.info header.i=@leemhuis.info header.b=ecDVrcwI; arc=none smtp.client-ip=46.38.247.119 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=leemhuis.info Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=leemhuis.info Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=leemhuis.info header.i=@leemhuis.info header.b="ecDVrcwI" Received: from mors-relay-8404.netcup.net (localhost [127.0.0.1]) by mors-relay-8404.netcup.net (Postfix) with ESMTPS id 4g8s6l03Xlz84gm; Tue, 5 May 2026 10:26:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=leemhuis.info; s=key2; t=1777969583; bh=CWaeVcm00SPOZ3SYrZTELMqqVT5hEgks1+ooT6SplRw=; h=Date:From:Subject:To:Cc:References:In-Reply-To:From; b=ecDVrcwI/NsVgH94jp9G5ZpdTyRQiWodi0k6kneErLedsBZNU+DO9EcpFdG28vLcv nOBZGqgQUlGzN60MI71ZvhNBgMt0Hkvl6W3FDQ/MNcReC7kNbbdC1bvD6wz9GVxygk TAouICfeOWo9Zakgms8+eQ2as9PMOtccOKyTCNURbGQzdznwE3J/z5Us2AOfjQcJar Nbdq0R8qCuSLwA6oFxMjr2nZyPDX38+iOLt9cr2X38FqaSCBDmpywfwaari3VpCufs h98iihPlb6Uwg3MscQqJcxlxEnGdEdoLaCyaHUILl2fDjhCI106xQk4DHHJerPVdb5 1mK8XN8PIiU3g== Received: from policy01-mors.netcup.net (unknown [46.38.225.35]) by mors-relay-8404.netcup.net (Postfix) with ESMTPS id 4g8s6k6SX0z4xBP; Tue, 5 May 2026 10:26:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at policy01-mors.netcup.net X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: Received: from mxe9fb.netcup.net (unknown [10.243.12.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by policy01-mors.netcup.net (Postfix) with ESMTPS id 4g8s6j2GKxz8tcZ; Tue, 5 May 2026 10:26:21 +0200 (CEST) Received: from [IPV6:2a02:8108:8984:1d00:a0cf:1912:4be:477f] (unknown [IPv6:2a02:8108:8984:1d00:a0cf:1912:4be:477f]) by mxe9fb.netcup.net (Postfix) with ESMTPSA id 0D705632E7; Tue, 5 May 2026 10:26:20 +0200 (CEST) Authentication-Results: mxe9fb; spf=pass (sender IP is 2a02:8108:8984:1d00:a0cf:1912:4be:477f) smtp.mailfrom=regressions@leemhuis.info smtp.helo=[IPV6:2a02:8108:8984:1d00:a0cf:1912:4be:477f] Received-SPF: pass (mxe9fb: connection is authenticated) Message-ID: <198e2ce4-07e1-46c0-818d-1eb18645aca0@leemhuis.info> Date: Tue, 5 May 2026 10:26:18 +0200 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Thorsten Leemhuis Subject: Re: [REGRESSION] stmmac: Random DMA reset failure on RK3399 since v6.18 To: Jensen Huang , Russell King Cc: Heiner Kallweit , Andrew Lunn , regressions@lists.linux.dev, netdev@vger.kernel.org, LKML References: Content-Language: de-DE, en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-PPP-Message-ID: <177796958042.440629.6346085614767550390@mxe9fb.netcup.net> X-Rspamd-Server: rspamd-worker-8404 X-Rspamd-Queue-Id: 0D705632E7 X-NC-CID: X0X9YM9AO5JfeE2JIDWZSK0of2cFrXJQgrXnbgYhGbZq4CaBI28= [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. 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 >