On Tue, Mar 27, 2018 at 11:43 PM, Alexander Duyck <alexander.du...@gmail.com> wrote: > On Tue, Mar 27, 2018 at 1:52 AM, Ran Shalit <ransha...@gmail.com> wrote: >> On Thu, Mar 22, 2018 at 7:31 PM, Alexander Duyck >> <alexander.du...@gmail.com> wrote: >>> On Thu, Mar 22, 2018 at 9:11 AM, Ran Shalit <ransha...@gmail.com> wrote: >>>> On Mon, Mar 19, 2018 at 10:23 PM, Alexander Duyck >>>> <alexander.du...@gmail.com> wrote: >>>>> On Mon, Mar 19, 2018 at 12:31 PM, Ran Shalit <ransha...@gmail.com> wrote: >>>>>> On Mon, Mar 19, 2018 at 6:27 PM, Alexander Duyck >>>>>> <alexander.du...@gmail.com> wrote: >>>>>>> On Mon, Mar 19, 2018 at 9:07 AM, Ran Shalit <ransha...@gmail.com> wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I am using igb driver: >>>>>>>> >>>>>>>> cat output/build/linux-4.10.17/.config | grep IGB >>>>>>>> >>>>>>>> CONFIG_IGB=y >>>>>>>> >>>>>>>> CONFIG_IGB_HWMON=y >>>>>>>> >>>>>>>> CONFIG_IGBVF=y >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> But every boot is takes a lot of time till ethernet is ready. >>>>>>>> >>>>>>>> I try to disable auto negotiation, but nothing helps yet, the device >>>>>>>> resist, and keep resets phy. >>>>>>>> >>>>>>>> adapter->fc_autoneg = false; >>>>>>>> >>>>>>>> hw->mac.autoneg = false; >>>>>>>> >>>>>>>> hw->phy.autoneg_advertised = 0; >>>>>>>> >>>>>>>> >>>>>>>> I tried more flags, but nothing helps. >>>>>>>> The phy always disabled/reset at boot (led is off for 1 second and >>>>>>>> then on). >>>>>>>> >>>>>>>> Is there a way to disable auto-negotiation with igb driver ? >>>>>>>> I use buildroot with kernel 4.10.81. >>>>>>>> >>>>>>>> >>>>>>>> Thank you for any suggestion, >>>>>>>> >>>>>>>> ran >>>>>>> >>>>>>> Instead of trying to disable it in the driver why not just change your >>>>>>> system configuration to disable it? You should be able to configure >>>>>>> things in either Network Manager, or via the network init scripts so >>>>>>> that you instead just used a forced speed/duplex combination. If >>>>>>> nothing else you can go through and drop support for any other >>>>>>> advertised speed/duplex and that should improve the speed of autoneg >>>>>>> itself. >>>>>>> >>>>>> >>>>>> I think I tried it and it did not work, but I shall try again. >>>>>> Where should I put it ? in init.d startup scripts ? >>>>>> I think I tried, and yet , I have seen that in reset, the leds of the >>>>>> phy are always turned off for a ~1.5 second and then on again. >>>>>> This is actually what I am trying to overcome, this strange reset of >>>>>> phy every powerup. >>>>> >>>>> So it sounds like what you may want to disable would not be the phy >>>>> autoneg, but the phy reset itself. If that is what you are looking for >>>>> then you might try modifying igb_reset_phy, or at least when we invoke >>>>> it in igb_power_up_link. You could look at adding a private flag to >>>>> the igb driver to disable it for your use case if that is the issue. >>>>> >>>>>>> You could refer to something like this for more information: >>>>>>> https://www.shellhacks.com/change-speed-duplex-ethernet-card-linux/ >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> - Alex >>>>>> >>>>>> Thank you very much, >>>>>> ran >>>>> >>>>> Now I am not so certain if this will solve you issue. What you may >>>>> want to do instead is take a look at the function igb_power_up_link in >>>>> igb_main.c and possibly consider adding a flag check to allow you to >>>>> disable it on the systems you need to disable it on, or if this is for >>>>> just one driver you could comment the line out and see if that will >>>>> solve the issue. >>>>> >>>> >>>> Using dmesg to understand what's going on , I see 2 things: >>>> 1. Long time interval between opening and link up (5.0 - 1.9 = ~3seconds !) >>> >>> For a 1G link 3 seconds isn't all that long. >>> >>>> 2. Long time interval between link up state and ping success ( 8 - 5 = >>>> ~3 sedconds !) >>> >>> I don't know what to tell you about that part. I suspect that may be >>> some delays in notifiers being processed after the interface has >>> reported link up. In addition I don't know what you link partner is. >>> Normally for a ping you have to take care of things like setting up >>> routes, getting an ARP out to find your target, and then sending the >>> ping to that address. >>> >>> What might be interesting would be to add a dump of the tx_buffer_info >>> data for the rings that have transmitted packets. For example we might >>> have reported link up, but the link partner may not have been >>> responding to us because it wasn't. >>> >> >> Hi Alexander, >> >> Is there a way to open this dump with compilation flag ? How to dump >> this information ? >> This time interval (from igb probe to link up) is now is the major >> delay (we solved the other time to ping). >> >> Thanks, >> ranran > > Actually it can be turned on dynamically to some extend. The code to > dump the Tx descriptor information is in a function called igb_dump in > the driver. To turn on the bits related to dumping Tx packets you > would need to use: > ethtool -s <ethX> msglvl hw on > ethtool -s <ethX> msglvl tx_done on > ethtool -s <ethX> msglvl pktdata on > > Then it is just a matter of triggering a call to the reset task. There > are a few ways to get there. If nothing else you might modify the > driver to call igb_dump() at the start of the igb_close() function. > Then all you would have to do is bring down the interface with > something like an ifconfig <ethX> down and that should trigger the > dump of the Tx descriptor data. > > - Alex
Hi Alex, I've dumped the tx descriptors here: https://drive.google.com/file/d/1OaP4rTT4TF8fcFTerVRosUihJDoAgeDz/view?usp=sharing Do you think it can explain the long boot time till link is up ? Thank you, ranran ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
