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 !) 2. Long time interval between link up state and ping success ( 8 - 5 = ~3 sedconds !) # 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 > Thanks. > > - 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
