Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761858Ab3JPU3S (ORCPT ); Wed, 16 Oct 2013 16:29:18 -0400 Received: from eu1sys200aog119.obsmtp.com ([207.126.144.147]:42272 "EHLO eu1sys200aog119.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760830Ab3JPU3Q (ORCPT ); Wed, 16 Oct 2013 16:29:16 -0400 Message-ID: <525EF70C.9090708@st.com> Date: Wed, 16 Oct 2013 22:29:00 +0200 From: Giuseppe CAVALLARO User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Romain Baeriswyl Cc: "David S. Miller" , , , Christian Ruppert Subject: Re: [RFC] net: stmmac: keep RXC running in LPI mode to avoid system overload References: <808496140.2212.1381694572197.JavaMail.root@abilis.com> In-Reply-To: <808496140.2212.1381694572197.JavaMail.root@abilis.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.129.4.206] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2637 Lines: 79 Hello Romain On 10/13/2013 10:02 PM, Romain Baeriswyl wrote: > Hello Guiseppe, > > Thanks for your answer. Please find below some details and answers. > >>> 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 disabling the LPI mode with ethtool --set-eee eth0 eee off, the > interrupt overload remains. Both counters irq_rx_path_in_lpi_mode_n and > irq_rx_path_exit_lpi_mode_n continue to run meaning the PHY continue > to put the RX path in LPI mode. > > Only way I found to get ride of the overload is to keep the RX_CLK running > in LPI mode. In this configuration, the RX link still continue to go in > LPI mode and the two above counters continue to run. > >>> >>> 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. > > Actually the PHY "may" stop RX_CLK. Another option it could be add a new parameter to enable/disable it. We can decide a parameter for the stmmac or something for ethtool. > >> >> May I suspect some issues on your HW? or disable it with ethtool >> > > Yes, it could be HW issue. It would be very useful if you could reproduce > the setup using a SoC with "DesignWare Cores Ethernet MAC" core, > the RTL8211E PHY and an Apple Airport Extreme. The issue could well be between > the controller and the PHY. > > Which Ethernet switch or router did you use to test the EEE mode? when I tested EEE I connected with P2P two STi boards. You can test it too. > I may try these equipments as well. > peppe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/