1. 15 Nov, 2019 4 commits
  2. 09 Nov, 2019 6 commits
    • Magnus Karlsson's avatar
      ixgbe: need_wakeup flag might not be set for Tx · 0843aa8f
      Magnus Karlsson authored
      
      
      The need_wakeup flag for Tx might not be set for AF_XDP sockets that
      are only used to send packets. This happens if there is at least one
      outstanding packet that has not been completed by the hardware and we
      get that corresponding completion (which will not generate an
      interrupt since interrupts are disabled in the napi poll loop) between
      the time we stopped processing the Tx completions and interrupts are
      enabled again. In this case, the need_wakeup flag will have been
      cleared at the end of the Tx completion processing as we believe we
      will get an interrupt from the outstanding completion at a later point
      in time. But if this completion interrupt occurs before interrupts
      are enable, we lose it and should at that point really have set the
      need_wakeup flag since there are no more outstanding completions that
      can generate an interrupt to continue the processing. When this
      happens, user space will see a Tx queue need_wakeup of 0 and skip
      issuing a syscall, which means will never get into the Tx processing
      again and we have a deadlock.
      
      This patch introduces a quick fix for this issue by just setting the
      need_wakeup flag for Tx to 1 all the time. I am working on a proper
      fix for this that will toggle the flag appropriately, but it is more
      challenging than I anticipated and I am afraid that this patch will
      not be completed before the merge window closes, therefore this easier
      fix for now. This fix has a negative performance impact in the range
      of 0% to 4%. Towards the higher end of the scale if you have driver
      and application on the same core and issue a lot of packets, and
      towards no negative impact if you use two cores, lower transmission
      speeds and/or a workload that also receives packets.
      
      Signed-off-by: default avatarMagnus Karlsson <magnus.karlsson@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      0843aa8f
    • Magnus Karlsson's avatar
      i40e: need_wakeup flag might not be set for Tx · 70563957
      Magnus Karlsson authored
      
      
      The need_wakeup flag for Tx might not be set for AF_XDP sockets that
      are only used to send packets. This happens if there is at least one
      outstanding packet that has not been completed by the hardware and we
      get that corresponding completion (which will not generate an
      interrupt since interrupts are disabled in the napi poll loop) between
      the time we stopped processing the Tx completions and interrupts are
      enabled again. In this case, the need_wakeup flag will have been
      cleared at the end of the Tx completion processing as we believe we
      will get an interrupt from the outstanding completion at a later point
      in time. But if this completion interrupt occurs before interrupts
      are enable, we lose it and should at that point really have set the
      need_wakeup flag since there are no more outstanding completions that
      can generate an interrupt to continue the processing. When this
      happens, user space will see a Tx queue need_wakeup of 0 and skip
      issuing a syscall, which means will never get into the Tx processing
      again and we have a deadlock.
      
      This patch introduces a quick fix for this issue by just setting the
      need_wakeup flag for Tx to 1 all the time. I am working on a proper
      fix for this that will toggle the flag appropriately, but it is more
      challenging than I anticipated and I am afraid that this patch will
      not be completed before the merge window closes, therefore this easier
      fix for now. This fix has a negative performance impact in the range
      of 0% to 4%. Towards the higher end of the scale if you have driver
      and application on the same core and issue a lot of packets, and
      towards no negative impact if you use two cores, lower transmission
      speeds and/or a workload that also receives packets.
      
      Signed-off-by: default avatarMagnus Karlsson <magnus.karlsson@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      70563957
    • Jacob Keller's avatar
      igb/igc: use ktime accessors for skb->tstamp · 6acab13b
      Jacob Keller authored
      
      
      When implementing launch time support in the igb and igc drivers, the
      skb->tstamp value is assumed to be a s64, but it's declared as a ktime_t
      value.
      
      Although ktime_t is typedef'd to s64 it wasn't always, and the kernel
      provides accessors for ktime_t values.
      
      Use the ktime_to_timespec64 and ktime_set accessors instead of directly
      assuming that the variable is always an s64.
      
      This improves portability if the code is ever moved to another kernel
      version, or if the definition of ktime_t ever changes again in the
      future.
      
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Acked-by: default avatarVinicius Costa Gomes <vinicius.gomes@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      6acab13b
    • Arkadiusz Kubalewski's avatar
      i40e: Fix for ethtool -m issue on X722 NIC · 4c9da6f2
      Arkadiusz Kubalewski authored
      
      
      This patch contains fix for a problem with command:
      'ethtool -m <dev>'
      which breaks functionality of:
      'ethtool <dev>'
      when called on X722 NIC
      
      Disallowed update of link phy_types on X722 NIC
      Currently correct value cannot be obtained from FW
      Previously wrong value returned by FW was used and was
      a root cause for incorrect output of 'ethtool <dev>' command
      
      Signed-off-by: default avatarArkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      4c9da6f2
    • Nicholas Nunley's avatar
      iavf: initialize ITRN registers with correct values · 4eda4e00
      Nicholas Nunley authored
      Since commit 92418fb1
      
       ("i40e/i40evf: Use usec value instead of reg
      value for ITR defines") the driver tracks the interrupt throttling
      intervals in single usec units, although the actual ITRN registers are
      programmed in 2 usec units. Most register programming flows in the driver
      correctly handle the conversion, although it is currently not applied when
      the registers are initialized to their default values. Most of the time
      this doesn't present a problem since the default values are usually
      immediately overwritten through the standard adaptive throttling mechanism,
      or updated manually by the user, but if adaptive throttling is disabled and
      the interval values are left alone then the incorrect value will persist.
      
      Since the intended default interval of 50 usecs (vs. 100 usecs as
      programmed) performs better for most traffic workloads, this can lead to
      performance regressions.
      
      This patch adds the correct conversion when writing the initial values to
      the ITRN registers.
      
      Signed-off-by: default avatarNicholas Nunley <nicholas.d.nunley@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      4eda4e00
    • Colin Ian King's avatar
      ice: fix potential infinite loop because loop counter being too small · 615457a2
      Colin Ian King authored
      Currently the for-loop counter i is a u8 however it is being checked
      against a maximum value hw->num_tx_sched_layers which is a u16. Hence
      there is a potential wrap-around of counter i back to zero if
      hw->num_tx_sched_layers is greater than 255.  Fix this by making i
      a u16.
      
      Addresses-Coverity: ("Infinite loop")
      Fixes: b36c598c
      
       ("ice: Updates to Tx scheduler code")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      615457a2
  3. 01 Nov, 2019 4 commits
  4. 31 Oct, 2019 2 commits
    • Manfred Rudigier's avatar
      igb: Enable media autosense for the i350. · fb2308ba
      Manfred Rudigier authored
      
      
      This patch enables the hardware feature "Media Auto Sense" also on the
      i350. It works in the same way as on the 82850 devices. Hardware designs
      using dual PHYs (fiber/copper) can enable this feature by setting the MAS
      enable bits in the NVM_COMPAT register (0x03) in the EEPROM.
      
      Signed-off-by: default avatarManfred Rudigier <manfred.rudigier@omicronenergy.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      fb2308ba
    • Lyude Paul's avatar
      igb/igc: Don't warn on fatal read failures when the device is removed · 94bc1e52
      Lyude Paul authored
      
      
      Fatal read errors are worth warning about, unless of course the device
      was just unplugged from the machine - something that's a rather normal
      occurrence when the igb/igc adapter is located on a Thunderbolt dock. So,
      let's only WARN() if there's a fatal read error while the device is
      still present.
      
      This fixes the following WARN splat that's been appearing whenever I
      unplug my Caldigit TS3 Thunderbolt dock from my laptop:
      
        igb 0000:09:00.0 enp9s0: PCIe link lost
        ------------[ cut here ]------------
        igb: Failed to read reg 0x18!
        WARNING: CPU: 7 PID: 516 at
        drivers/net/ethernet/intel/igb/igb_main.c:756 igb_rd32+0x57/0x6a [igb]
        Modules linked in: igb dca thunderbolt fuse vfat fat elan_i2c mei_wdt
        mei_hdcp i915 wmi_bmof intel_wmi_thunderbolt iTCO_wdt
        iTCO_vendor_support x86_pkg_temp_thermal intel_powerclamp joydev
        coretemp crct10dif_pclmul crc32_pclmul i2c_algo_bit ghash_clmulni_intel
        intel_cstate drm_kms_helper intel_uncore syscopyarea sysfillrect
        sysimgblt fb_sys_fops intel_rapl_perf intel_xhci_usb_role_switch mei_me
        drm roles idma64 i2c_i801 ucsi_acpi typec_ucsi mei intel_lpss_pci
        processor_thermal_device typec intel_pch_thermal intel_soc_dts_iosf
        intel_lpss int3403_thermal thinkpad_acpi wmi int340x_thermal_zone
        ledtrig_audio int3400_thermal acpi_thermal_rel acpi_pad video
        pcc_cpufreq ip_tables serio_raw nvme nvme_core crc32c_intel uas
        usb_storage e1000e i2c_dev
        CPU: 7 PID: 516 Comm: kworker/u16:3 Not tainted 5.2.0-rc1Lyude-Test+ #14
        Hardware name: LENOVO 20L8S2N800/20L8S2N800, BIOS N22ET35W (1.12 ) 04/09/2018
        Workqueue: kacpi_hotplug acpi_hotplug_work_fn
        RIP: 0010:igb_rd32+0x57/0x6a [igb]
        Code: 87 b8 fc ff ff 48 c7 47 08 00 00 00 00 48 c7 c6 33 42 9b c0 4c 89
        c7 e8 47 45 cd dc 89 ee 48 c7 c7 43 42 9b c0 e8 c1 94 71 dc <0f> 0b eb
        08 8b 00 ff c0 75 b0 eb c8 44 89 e0 5d 41 5c c3 0f 1f 44
        RSP: 0018:ffffba5801cf7c48 EFLAGS: 00010286
        RAX: 0000000000000000 RBX: ffff9e7956608840 RCX: 0000000000000007
        RDX: 0000000000000000 RSI: ffffba5801cf7b24 RDI: ffff9e795e3d6a00
        RBP: 0000000000000018 R08: 000000009dec4a01 R09: ffffffff9e61018f
        R10: 0000000000000000 R11: ffffba5801cf7ae5 R12: 00000000ffffffff
        R13: ffff9e7956608840 R14: ffff9e795a6f10b0 R15: 0000000000000000
        FS:  0000000000000000(0000) GS:ffff9e795e3c0000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 0000564317bc4088 CR3: 000000010e00a006 CR4: 00000000003606e0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
        Call Trace:
         igb_release_hw_control+0x1a/0x30 [igb]
         igb_remove+0xc5/0x14b [igb]
         pci_device_remove+0x3b/0x93
         device_release_driver_internal+0xd7/0x17e
         pci_stop_bus_device+0x36/0x75
         pci_stop_bus_device+0x66/0x75
         pci_stop_bus_device+0x66/0x75
         pci_stop_and_remove_bus_device+0xf/0x19
         trim_stale_devices+0xc5/0x13a
         ? __pm_runtime_resume+0x6e/0x7b
         trim_stale_devices+0x103/0x13a
         ? __pm_runtime_resume+0x6e/0x7b
         trim_stale_devices+0x103/0x13a
         acpiphp_check_bridge+0xd8/0xf5
         acpiphp_hotplug_notify+0xf7/0x14b
         ? acpiphp_check_bridge+0xf5/0xf5
         acpi_device_hotplug+0x357/0x3b5
         acpi_hotplug_work_fn+0x1a/0x23
         process_one_work+0x1a7/0x296
         worker_thread+0x1a8/0x24c
         ? process_scheduled_works+0x2c/0x2c
         kthread+0xe9/0xee
         ? kthread_destroy_worker+0x41/0x41
         ret_from_fork+0x35/0x40
        ---[ end trace 252bf10352c63d22 ]---
      
      Signed-off-by: default avatarLyude Paul <lyude@redhat.com>
      Fixes: 47e16692
      
       ("igb/igc: warn when fatal read failure happens")
      Acked-by: default avatarSasha Neftin <sasha.neftin@intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Acked-by: default avatarFeng Tang <feng.tang@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      94bc1e52
  5. 16 Sep, 2019 2 commits
  6. 13 Sep, 2019 1 commit
  7. 12 Sep, 2019 7 commits
  8. 11 Sep, 2019 14 commits