1. 25 1月, 2018 14 次提交
    • D
      igb: Clear TXSTMP when ptp_tx_work() is timeout · 3a532852
      Daniel Hua 提交于
      Problem description:
      After ethernet cable connect and disconnect for several iterations on a
      device with i210, tx timestamp will stop being put into the socket.
      
      Steps to reproduce:
      1. Setup a device with i210 and wire it to a 802.1AS capable switch (
      Extreme Networks Summit x440 is used in our case)
      2. Have the gptp daemon running on the device and make sure it is synced
      with the switch
      3. Have the switch disable and enable the port, wait for the device gets
      resynced with the switch
      4. Iterates step 3 until the device is not albe to get resynced
      5. Review the log in dmesg and you will see warning message "igb : clearing
      Tx timestamp hang"
      
      Root cause:
      If ptp_tx_work() gets scheduled just before the port gets disabled, a LINK
      DOWN event will be processed before ptp_tx_work(), which may cause timeout
      in ptp_tx_work(). In the timeout logic, the TSYNCTXCTL's TXTT bit (Transmit
      timestamp valid bit) is not cleared, causing no new timestamp loaded to
      TXSTMP register. Consequently therefore, no new interrupt is triggerred by
      TSICR.TXTS bit and no more Tx timestamp send to the socket.
      Signed-off-by: NDaniel Hua <daniel.hua@ni.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      3a532852
    • M
      igb: Delete an error message for a failed memory allocation in igb_enable_sriov() · 13169bad
      Markus Elfring 提交于
      Omit an extra message for a memory allocation failure in this function.
      
      This issue was detected by using the Coccinelle software.
      Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      13169bad
    • L
      igb: Free IRQs when device is hotplugged · 888f2293
      Lyude Paul 提交于
      Recently I got a Caldigit TS3 Thunderbolt 3 dock, and noticed that upon
      hotplugging my kernel would immediately crash due to igb:
      
      [  680.825801] kernel BUG at drivers/pci/msi.c:352!
      [  680.828388] invalid opcode: 0000 [#1] SMP
      [  680.829194] Modules linked in: igb(O) thunderbolt i2c_algo_bit joydev vfat fat btusb btrtl btbcm btintel bluetooth ecdh_generic hp_wmi sparse_keymap rfkill wmi_bmof iTCO_wdt intel_rapl x86_pkg_temp_thermal coretemp crc32_pclmul snd_pcm rtsx_pci_ms mei_me snd_timer memstick snd pcspkr mei soundcore i2c_i801 tpm_tis psmouse shpchp wmi tpm_tis_core tpm video hp_wireless acpi_pad rtsx_pci_sdmmc mmc_core crc32c_intel serio_raw rtsx_pci mfd_core xhci_pci xhci_hcd i2c_hid i2c_core [last unloaded: igb]
      [  680.831085] CPU: 1 PID: 78 Comm: kworker/u16:1 Tainted: G           O     4.15.0-rc3Lyude-Test+ #6
      [  680.831596] Hardware name: HP HP ZBook Studio G4/826B, BIOS P71 Ver. 01.03 06/09/2017
      [  680.832168] Workqueue: kacpi_hotplug acpi_hotplug_work_fn
      [  680.832687] RIP: 0010:free_msi_irqs+0x180/0x1b0
      [  680.833271] RSP: 0018:ffffc9000030fbf0 EFLAGS: 00010286
      [  680.833761] RAX: ffff8803405f9c00 RBX: ffff88033e3d2e40 RCX: 000000000000002c
      [  680.834278] RDX: 0000000000000000 RSI: 00000000000000ac RDI: ffff880340be2178
      [  680.834832] RBP: 0000000000000000 R08: ffff880340be1ff0 R09: ffff8803405f9c00
      [  680.835342] R10: 0000000000000000 R11: 0000000000000040 R12: ffff88033d63a298
      [  680.835822] R13: ffff88033d63a000 R14: 0000000000000060 R15: ffff880341959000
      [  680.836332] FS:  0000000000000000(0000) GS:ffff88034f440000(0000) knlGS:0000000000000000
      [  680.836817] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  680.837360] CR2: 000055e64044afdf CR3: 0000000001c09002 CR4: 00000000003606e0
      [  680.837954] Call Trace:
      [  680.838853]  pci_disable_msix+0xce/0xf0
      [  680.839616]  igb_reset_interrupt_capability+0x5d/0x60 [igb]
      [  680.840278]  igb_remove+0x9d/0x110 [igb]
      [  680.840764]  pci_device_remove+0x36/0xb0
      [  680.841279]  device_release_driver_internal+0x157/0x220
      [  680.841739]  pci_stop_bus_device+0x7d/0xa0
      [  680.842255]  pci_stop_bus_device+0x2b/0xa0
      [  680.842722]  pci_stop_bus_device+0x3d/0xa0
      [  680.843189]  pci_stop_and_remove_bus_device+0xe/0x20
      [  680.843627]  trim_stale_devices+0xf3/0x140
      [  680.844086]  trim_stale_devices+0x94/0x140
      [  680.844532]  trim_stale_devices+0xa6/0x140
      [  680.845031]  ? get_slot_status+0x90/0xc0
      [  680.845536]  acpiphp_check_bridge.part.5+0xfe/0x140
      [  680.846021]  acpiphp_hotplug_notify+0x175/0x200
      [  680.846581]  ? free_bridge+0x100/0x100
      [  680.847113]  acpi_device_hotplug+0x8a/0x490
      [  680.847535]  acpi_hotplug_work_fn+0x1a/0x30
      [  680.848076]  process_one_work+0x182/0x3a0
      [  680.848543]  worker_thread+0x2e/0x380
      [  680.848963]  ? process_one_work+0x3a0/0x3a0
      [  680.849373]  kthread+0x111/0x130
      [  680.849776]  ? kthread_create_worker_on_cpu+0x50/0x50
      [  680.850188]  ret_from_fork+0x1f/0x30
      [  680.850601] Code: 43 14 85 c0 0f 84 d5 fe ff ff 31 ed eb 0f 83 c5 01 39 6b 14 0f 86 c5 fe ff ff 8b 7b 10 01 ef e8 b7 e4 d2 ff 48 83 78 70 00 74 e3 <0f> 0b 49 8d b5 a0 00 00 00 e8 62 6f d3 ff e9 c7 fe ff ff 48 8b
      [  680.851497] RIP: free_msi_irqs+0x180/0x1b0 RSP: ffffc9000030fbf0
      
      As it turns out, normally the freeing of IRQs that would fix this is called
      inside of the scope of __igb_close(). However, since the device is
      already gone by the point we try to unregister the netdevice from the
      driver due to a hotplug we end up seeing that the netif isn't present
      and thus, forget to free any of the device IRQs.
      
      So: make sure that if we're in the process of dismantling the netdev, we
      always allow __igb_close() to be called so that IRQs may be freed
      normally. Additionally, only allow igb_close() to be called from
      __igb_close() if it hasn't already been called for the given adapter.
      Signed-off-by: NLyude Paul <lyude@redhat.com>
      Fixes: 9474933c ("igb: close/suspend race in netif_device_detach")
      Cc: Todd Fujinaka <todd.fujinaka@intel.com>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Cc: stable@vger.kernel.org
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      888f2293
    • M
      e1000e: Alert the user that C-states will be disabled by enabling jumbo frames · 8299b006
      Matt Turner 提交于
      I personally spent a long time trying to decypher why my CPU would not
      reach deeper C-states. Let's just tell the next user what's going on.
      Signed-off-by: NMatt Turner <matt.turner@intel.com>
      Acked-by: NShannon Nelson <shannon.nelson@oracle.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      8299b006
    • J
      igb: Clarify idleslope config constraints · 0da6090f
      Jesus Sanchez-Palencia 提交于
      By design, the idleslope increments are restricted to 16.384kbps steps.
      Add a comment to igb_main.c making that explicit and add one example
      that illustrates the impact of that.
      Signed-off-by: NJesus Sanchez-Palencia <jesus.sanchez-palencia@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      0da6090f
    • M
      e1000e: Set HTHRESH when PTHRESH is used · b701cacd
      Matt Turner 提交于
      According to section 12.0.3.4.13 "Receive Descriptor Control - RXDCTL"
      of the Intel® 82579 Gigabit Ethernet PHY Datasheet v2.1:
      
          "HTHRESH should be given a non zero value when ever PTHRESH is
           used."
      
      In RXDCTL(0), PTHRESH lives at bits 5:0, and HTHREST lives at bits 13:8.
      Set only bit 8 of HTHREST as is done in e1000_flush_rx_ring(). Found by
      inspection.
      Signed-off-by: NMatt Turner <matt.turner@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      b701cacd
    • Z
      igb: add function to get maximum RSS queues · 28cb2d1b
      Zhang Shengju 提交于
      This patch adds a new function igb_get_max_rss_queues() to get maximum
      RSS queues, this will reduce duplicate code and facilitate future
      maintenance.
      Signed-off-by: NZhang Shengju <zhangshengju@cmss.chinamobile.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      28cb2d1b
    • C
      igb: Allow to remove administratively set MAC on VFs · 177132df
      Corinna Vinschen 提交于
      Before libvirt modifies the MAC address and vlan tag for an SRIOV VF
      for use by a virtual machine (either using vfio device assignment or
      macvtap passthru mode), it saves the current MAC address and vlan tag
      so that it can reset them to their original value when the guest is
      done.  Libvirt can't leave the VF MAC set to the value used by the
      now-defunct guest since it may be started again later using a
      different VF, but it certainly shouldn't just pick any random value,
      either. So it saves the state of everything prior to using the VF, and
      resets it to that.
      
      The igb driver initializes the MAC addresses of all VFs to
      00:00:00:00:00:00, and reports that when asked (via an RTM_GETLINK
      netlink message, also visible in the list of VFs in the output of "ip
      link show"). But when libvirt attempts to restore the MAC address back
      to 00:00:00:00:00:00 (using an RTM_SETLINK netlink message) the kernel
      responds with "Invalid argument".
      
      Forbidding a reset back to the original value leaves the VF MAC at the
      value set for the now-defunct virtual machine. Especially on a system
      with NetworkManager enabled, this has very bad consequences, since
      NetworkManager forces all interfacess to be IFF_UP all the time - if
      the same virtual machine is restarted using a different VF (or even on
      a different host), there will be multiple interfaces watching for
      traffic with the same MAC address.
      
      To allow libvirt to revert to the original state, we need a way to
      remove the administrative set MAC on a VF, to allow normal host
      operation again, and to reset/overwrite the VF MAC via VF netdev.
      
      This patch implements the outlined scenario by allowing to set the
      VF MAC to 00:00:00:00:00:00 via RTM_SETLINK on the PF.
      igb_ndo_set_vf_mac resets the IGB_VF_FLAG_PF_SET_MAC flag to 0,
      so it's possible to reset the VF MAC back to the original value via
      the VF netdev.
      
      Note: Recent patches to libvirt allow for a workaround if the NIC
      isn't capable of resetting the administrative MAC back to all 0, but
      in theory the NIC should allow resetting the MAC in the first place.
      Signed-off-by: NCorinna Vinschen <vinschen@redhat.com>
      Tested-by: NAaron Brown <arron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      177132df
    • D
      Merge branch 'pktgen-Behavior-flags-fixes' · 46410c2e
      David S. Miller 提交于
      Dmitry Safonov says:
      
      ====================
      pktgen: Behavior flags fixes
      
      v2:
        o fixed a nitpick from David Miller
      
      There are a bunch of fixes/cleanups/Documentations.
      Diffstat says for itself, regardless added docs and missed flag
      parameters.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      46410c2e
    • D
      pktgen: Clean read user supplied flag mess · 52e12d5d
      Dmitry Safonov 提交于
      Don't use error-prone-brute-force way.
      Signed-off-by: NDmitry Safonov <dima@arista.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      52e12d5d
    • D
      pktgen: Remove brute-force printing of flags · 99c6d3d2
      Dmitry Safonov 提交于
      Add macro generated pkt_flag_names array, with a little help of which
      the flags can be printed by using an index.
      Signed-off-by: NDmitry Safonov <dima@arista.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      99c6d3d2
    • D
      pktgen: Add behaviour flags macro to generate flags/names · 6f107c74
      Dmitry Safonov 提交于
      PKT_FALGS macro will be used to add package behavior names definitions
      to simplify the code that prints/reads pkg flags.
      Sorted the array in order of printing the flags in pktgen_if_show()
      Note: Renamed IPSEC_ON => IPSEC for simplicity.
      
      No visible behavior change expected.
      Signed-off-by: NDmitry Safonov <dima@arista.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6f107c74
    • D
      pktgen: Add missing !flag parameters · 57a5749b
      Dmitry Safonov 提交于
      o FLOW_SEQ now can be disabled with pgset "flag !FLOW_SEQ"
      o FLOW_SEQ and FLOW_RND are antonyms, as it's shown by pktgen_if_show()
      o IPSEC now may be disabled
      
      Note, that IPV6 is enabled with dst6/src6 parameters, not with
      a flag parameter.
      Signed-off-by: NDmitry Safonov <dima@arista.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      57a5749b
    • D
      Documentation/pktgen: Clearify how-to use pktgen samples · d2ee7973
      Dmitry Safonov 提交于
      o Change process name in ps output: looks like, these days the process
        is named kpktgend_<cpu>, rather than pktgen/<cpu>.
      o Use pg_ctrl for start/stop as it can work well with pgset without
        changes to $(PGDEV) variable.
      o Clarify a bit needed $(PGDEV) definition for sample scripts and that
        one needs to `source functions.sh`.
      o Document how-to unset a behaviour flag, note about history expansion.
      o Fix pgset spi parameter value.
      
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: linux-doc@vger.kernel.org
      Signed-off-by: NDmitry Safonov <dima@arista.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d2ee7973
  2. 24 1月, 2018 26 次提交