netdev - Re: [RFC] net: stmmac: keep RXC running in LPI mode to avoid system overload

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <52557606.8030201@st.com>
Date:	Wed, 9 Oct 2013 17:28:06 +0200
From:	Giuseppe CAVALLARO <peppe.cavallaro@...com>
To:	Romain Baeriswyl <Romain.Baeriswyl@...lis.com>
Cc:	"David S. Miller" <davem@...emloft.net>, <netdev@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>,
	Romain Baeriswyl <romainba@...lis.com>
Subject: Re: [RFC] net: stmmac: keep RXC running in LPI mode to avoid system
 overload

Hello Romain

On 10/8/2013 5:06 PM, Romain Baeriswyl wrote:
> In order to avoid system overload, the clock RXC from the Phy should not be
> stopped when in LPI mode.
>
> With the RTL8211E PHY which support EEE mode and with Apple Airport Extreme that
> supports it also, the kernel get frozen as soon as some Ethernet transfers are


hmm, I have a board with this transceiver so I could do some tests
this could take a while, unfortunately.

> on-going. System seems to be overloaded with too many interrupts. The 'top'
> command reports often around ~80% irq.

do you mean lpi mac interrupts?

>
> By letting the RXC clock running even in LPI mode as proposed below, the issue
> seems solved. Is it the right way to proceed?

For EEE capability, RX_CLK may be halted for this reason i used it as 
default in the stmmac and never seen your issue.

>
> What is the power impact to not stop RXC in LPI mode?

I can point you to "22.2.2.8a Receive direction LPI transition"
in IEEE802-3az... where is it reported that the PHY  halt the RX_CLK
in LPI mode.

May I suspect some issues on your HW? or disable it with ethtool


peppe

>
> ---
>   drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |    6 ++++--
>   1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index e9eab29..d40d26b 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -314,7 +314,8 @@ bool stmmac_eee_init(struct stmmac_priv *priv)
>   	/* MAC core supports the EEE feature. */
>   	if (priv->dma_cap.eee) {
>   		/* Check if the PHY supports EEE */
> -		if (phy_init_eee(priv->phydev, 1))
> +		/* Keeps RXC running in LPI mode to avoid stability issue */
> +		if (phy_init_eee(priv->phydev, 0))
>   			goto out;
>
>   		if (!priv->eee_active) {
> @@ -770,7 +771,8 @@ static void stmmac_adjust_link(struct net_device *dev)
>   	/* At this stage, it could be needed to setup the EEE or adjust some
>   	 * MAC related HW registers.
>   	 */
> -	priv->eee_enabled = stmmac_eee_init(priv);
> +	if (new_state)
> +		priv->eee_enabled = stmmac_eee_init(priv);

this seems out of context and not necessary

>
>   	spin_unlock_irqrestore(&priv->lock, flags);
>   }
>

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html