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 ------------------------------------------------------------------------------ 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
