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 >> # dmesg | grep >> [ 1.897306] igb_init_module >> [ 1.897309] igb: Intel(R) Gigabit Ethernet Network Driver << - >> version 5.4.0-k >> [ 1.897310] igb: Copyright (c) 2007-2014 Intel Corporation. << >> [ 1.897338] igb_probe >> [ 1.897728] igb_sw_init >> [ 1.908895] igb_reset >> [ 1.923042] igb_power_down_link >> [ 1.926740] Starting network: >> [ 1.944956] __igb_open >> [ 1.945005] igb_power_up_link >> [ 5.043281] igb 0000:03:00.0 eth0: igb: eth0 NIC Link is Up 1000 >> Mbps Full Duplex, Flow Control: RX >> [ 7.966910] ping success ok 0 >> >> Is there any possible reason for this 2 long intervals in IGB driver ? >> >> Thanks, >> ranran > > These intervals aren't all that long. You have to realize we are > trying to put together a digital signal that goes over electrical > link. Setting all of that up takes time. The only way to short-cut > that would be to have the link up before we start, and by default the > link is normally at the lowest possible negotiated speed at power on > in order to save on power consumption since it is assumed to only be > needed to handle wake-on-lan events. > > - 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
