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
| ||
|
Date: Wed, 16 Oct 2013 22:29:00 +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>, Christian Ruppert <chrisr@...lis.com> Subject: Re: [RFC] net: stmmac: keep RXC running in LPI mode to avoid system overload 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@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists