1. 25 Sep, 2021 1 commit
  2. 17 Sep, 2021 4 commits
  3. 15 Sep, 2021 2 commits
    • Kevin Bowling's avatar
      e1000: Fix variable typo · 22b20b45
      Kevin Bowling authored
      Forgot to git add this in last commit
      Reported by:	jenkins
      Fixes:		2796f7ca
      MFC after:	2 week
    • Kevin Bowling's avatar
      e1000: Fix up HW vlan ops · 2796f7ca
      Kevin Bowling authored
      * Don't reset the entire adapter for vlan changes, fix up the problems
      * Add some functions for vlan filter (vfta) manipulation
      * Don't muck with the vfta if we aren't doing HW vlan filtering
      * Disable interrupts when manipulating vfta on lem(4)-class NICs
      * On the I350 there is a specification update (2.4.20) in which the
      suggested workaround is to write to the vfta 10 times (if at first you
      don't succeed, try, try again). Our shared code has the goods, use it
      * Increase a VF's frame receive size in the case of vlans
      From the referenced PR, this reduced vlan configuration from minutes
      to seconds with hundreds or thousands of vlans and prevents wedging the
      adapter with needless adapter reinitialization for each vlan ID.
      PR:		230996
      Reviewed by:	markj
      Tested by:	Ozkan KIRIK <ozkan.kirik@gmail.com>
      MFC after:	2 weeks
      Differential Revision:	https://reviews.freebsd.org/D30002
  4. 20 Aug, 2021 1 commit
  5. 19 Aug, 2021 1 commit
  6. 16 Aug, 2021 1 commit
  7. 10 Aug, 2021 1 commit
  8. 27 Apr, 2021 1 commit
    • Kevin Bowling's avatar
      e1000: Rework em_msi_link interrupt filter · eea55de7
      Kevin Bowling authored
      * Fix 82574 Link Status Changes, carrying the OTHER mask bit around as
      * Move igb-class LSC re-arming out of FAST back into the handler.
      * Clarify spurious/other interrupt re-arms in FAST.
      In MSI-X mode, 82574 and igb-class devices use an interrupt filter to
      handle Link Status Changes. We want to do LSC re-arms in the handler
      to take advantage of autoclear (EIAC) single shot behavior.
      82574 uses 'Other' in ICR and IMS for LSC interrupt types when in MSI-X
      mode, so we need to set and re-arm the 'Other' bit during attach and
      after ICR reads in the FAST handler if not an LSC or after handling on
      LSC due to autoclearing.
      This work was primarily done to address the referenced PR, but inspired
      some clarification and improvement for igb-class devices once the
      intentions of previous bug fix attempts became clearer.
      PR:		211219
      Reported by:	Alexey <aserp3@gmail.com>
      Tested by:	kbowling (I210 lagg), markj (I210)
      Approved by:	markj
      MFC after:	1 month
      Differential Revision:	https://reviews.freebsd.org/D29943
  9. 26 Apr, 2021 2 commits
  10. 19 Apr, 2021 2 commits
    • Kevin Bowling's avatar
      e1000: Add support for [Tiger, Alder, Meteor] Lake · 59690eab
      Kevin Bowling authored
      Add support for current and future client platform PCI IDs. These are
      all I219 variants and have no known driver changes versus previous
      generation client platform I219 variants.
      Reviewed by:	markj
      MFC after:	2 weeks
      Differential Revision:	https://reviews.freebsd.org/D29801
    • Kevin Bowling's avatar
      e1000: Correct promisc multicast filter handling · 4b38eed7
      Kevin Bowling authored
      There are a number of issues in the e1000 multicast filter handling
      that have been present for a long time. Take the updated approach from
      ixgbe(4) which does not have the issues.
      The issues are outlined in the PR, in particular this solves crossing
      over and under the hardware's filter limit, not programming the
      hardware filter when we are above its limit, disabling SBP (show bad
      packets) when the tunable is enabled and exiting promiscuous mode, and
      an off-by-one error in the em_copy_maddr function.
      PR:		140647
      Reported by:	jtl
      Reviewed by:	markj
      MFC after:	1 month
      Differential Revision:	https://reviews.freebsd.org/D29789
  11. 15 Apr, 2021 3 commits
  12. 08 Mar, 2021 1 commit
    • Mark Johnston's avatar
      iflib: Make if_shared_ctx_t a pointer to const · ffe3def9
      Mark Johnston authored
      This structure is shared among multiple instances of a driver, so we
      should ensure that it doesn't somehow get treated as if there's a
      separate instance per interface.  This is especially important for
      software-only drivers like wg.
      DEVICE_REGISTER() still returns a void * and so the per-driver sctx
      structures are not yet defined with the const qualifier.
      Reviewed by:	gallatin, erj
      MFC after:	2 weeks
      Sponsored by:	The FreeBSD Foundation
      Differential Revision:	https://reviews.freebsd.org/D29102
  13. 01 Feb, 2021 1 commit
    • Sai Rajesh Tallamraju's avatar
      iflib: Free resources in a consistent order during detach · 38bfc6de
      Sai Rajesh Tallamraju authored
      Memory and PCI resources are freed with no particular order.  This could
      cause use-after-frees when detaching following a failed attach.  For
      instance, iflib_tx_structures_free() frees ctx->ifc_txqs[] but
      iflib_tqg_detach() attempts to access this array. Similarly, adapter
      queues gets freed by IFDI_QUEUES_FREE() but IFDI_DETACH() attempts to
      access adapter queues to free PCI resources.
      MFC after:	2 weeks
      Sponsored by:	NetApp, Inc.
      Differential Revision:	https://reviews.freebsd.org/D27634
  14. 27 Jan, 2021 1 commit
  15. 26 Jan, 2021 1 commit
  16. 16 Dec, 2020 2 commits
  17. 02 Dec, 2020 1 commit
    • Mitchell Horne's avatar
      em: fix a null de-reference in em_free_pci_resources · a3cd2439
      Mitchell Horne authored
      A failure in iflib_device_register() can result in
      em_free_pci_resources() being called after receive queues have already
      been freed. In particular, a failure to allocate IRQ resources will goto
      fail_queues, where IFDI_QUEUES_FREE() will be called via
      iflib_tx_structures_free(), preceding the call to IFDI_DETACH().
      Cope with this by checking adapter->rx_queues before dereferencing it.
      A similar check is present in ixgbe(4) and ixl(4).
      MFC after:	1 week
      Sponsored by:	NetApp, Inc.
      Sponsored by:	Klara, Inc.
      Differential Revision:	https://reviews.freebsd.org/D27260
  18. 15 Sep, 2020 1 commit
    • Eric Joyner's avatar
      e1000: Properly retain promisc flag · a3b9a736
      Eric Joyner authored
      From Franco:
      The iflib rewrite forced the promisc flag but it was not reported
      to the system.  Noticed on a stock VM that went into unsolicited
      promisc mode when dhclient was started during bootup.
      PR:		248869
      Submitted by:	Franco Fichtner <franco@opnsense.org>
      Reviewed by:	erj@
      MFC after:	3 days
  19. 06 Aug, 2020 1 commit
    • Vincenzo Maffione's avatar
      em(4): honor vlanhwtag offload · 7e6223b2
      Vincenzo Maffione authored
      The FreeBSD em driver fails to properly reset the VME flag
      in the e1000 CTRL register oneg the following ifconfig command
      	ifconfig em1 -vlanhwtag
      Tested on the e1000 device emulated by QEMU, and on a real
      NIC (chip=0x10d38086).
      PR:	236584
      Submitted by:	 murat@sunnyvalley.io
      Reported by:	 murat@sunnyvalley.io
      MFC after:	3 weeks
      Differential Revision:	https://reviews.freebsd.org/D25286
  20. 11 Jun, 2020 1 commit
    • Eric Joyner's avatar
      em(4): Always reinit interface when adding/removing VLAN · 104d75a0
      Eric Joyner authored
      This partially reverts r361053 since there have been reports
      by users that this breaks some functionality for em(4)
      devices; it seems at first glance that some sort of interface
      restart is required for those cards.
      This isn't a proper fix; this unbreaks those users until a proper
      fix is found for their issues.
      PR:		240818
      Reported by:	Marek Zarychta <zarychtam@plan-b.pwste.edu.pl>
      MFC after:	3 days
  21. 04 Jun, 2020 1 commit
    • Eric Joyner's avatar
      em(4): Add support for Comet Lake Mobile Platform, update shared code · 51569bd7
      Eric Joyner authored
      This change introduces Comet Lake Mobile Platform support in the e1000
      driver along with shared code patches described below.
      - Cast return value of e1000_ltr2ns() to higher type to avoid overflow
      - Remove useless statement of assigning act_offset
      - Add initialization of identification LED
      - Fix flow control setup after connected standby:
        After connected standby the driver blocks resets during
        "AdapterStart" and skips flow control setup. This change adds
        condition in e1000_setup_link_ich8lan() to always setup flow control
        and to setup physical interface only when there is no need to block
      Signed-off-by: default avatarPiotr Pietruszewski <piotr.pietruszewski@intel.com>
      Submitted by:	Piotr Pietruszewski <piotr.pietruszewski@intel.com>
      Reviewed by:	erj@
      Tested by:	Jeffrey Pieper <jeffrey.e.pieper@intel.com>
      MFC after:	1 week
      Relnotes:	yes
      Sponsored by:	Intel Corporation
      Differential Revision:	https://reviews.freebsd.org/D25035
  22. 11 May, 2020 1 commit
    • Eric Joyner's avatar
      em/ix/ixv/ixl/iavf: Implement ifdi_needs_restart iflib method · cf150917
      Eric Joyner authored
      Pursuant to r360398, implement driver-specific versions of the
      ifdi_needs_restart iflib device method.
      Some (if not most?) Intel network cards don't need reinitializing when a
      VLAN is added or removed from the device hardware, so these implement
      ifdi_needs_restart in a way that tell iflib not to bring the interface
      up or down when a VLAN is added or removed, regardless of whether the
      VLAN_HWFILTER interface capability flag is set or not.
      This could potentially solve several PRs relating to link flaps that
      occur when VLANs are added/removed to devices.
      Signed-off-by: default avatarEric Joyner <erj@freebsd.org>
      PR:		240818, 241785
      Reviewed by:	gallatin@, olivier@
      MFC after:	3 days
      MFC with:	r360398
      Sponsored by:	Intel Corporation
      Differential Revision:	https://reviews.freebsd.org/D24659
  23. 24 Feb, 2020 1 commit
    • Pawel Biernacki's avatar
      Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (15 of many) · 20b91f0a
      Pawel Biernacki authored
      r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
      still not MPSAFE (or already are but aren’t properly marked).
      Use it in preparation for a general review of all nodes.
      This is non-functional change that adds annotations to SYSCTL_NODE and
      SYSCTL_PROC nodes using one of the soon-to-be-required flags.
  24. 20 Jan, 2020 1 commit
  25. 04 Nov, 2019 1 commit
  26. 21 Oct, 2019 1 commit
  27. 20 Oct, 2019 1 commit
    • Marius Strobl's avatar
      - In em_intr(), just call em_handle_link() instead of duplicating it. · cd1cf2fc
      Marius Strobl authored
      - In em_msix_link(), properly handle IGB-class devices after the iflib(4)
        conversion again by only setting EM_MSIX_LINK for the EM-class 82574
        and by re-arming link interrupts unconditionally, i. e. not only in
        case of spurious interrupts. This fixes the interface link state change
        detection for the IGB-class. [1]
      - In em_if_update_admin_status(), only re-arm the link state change
        interrupt for 82574 and also only if such a device uses MSI-X, i. e.
        takes advantage of autoclearing. In case of INTx and MSI as well as
        for LEM- and IGB-class devices, re-arming isn't appropriate here and
        setting EM_MSIX_LINK isn't either.
        While at it, consistently take advantage of the hw variable.
      PR:	236724 [1]
      Differential Revision:	https://reviews.freebsd.org/D21924
  28. 16 Oct, 2019 1 commit
    • Eric Joyner's avatar
      e1000: correctly set isc_pause_frames only when XOFF increases · ea0e3f4d
      Eric Joyner authored
      From Jake:
      The e1000 driver sets the iflib shared context isc_pause_frames value to
      the number of received xoff frames. This is done so that the iflib
      watchdog timer won't trigger a Tx Hang due to pause frames.
      Unfortunately, the function simply sets it to the value of the xoffrxc
      counter. Once the device has received a single XOFF packet, the driver
      always reports that we received pause frames. This will prevent the Tx
      hang detection entirely from that point on.
      Fix this by assigning isc_pause_frames to a non-zero value if we
      received any XOFF packets in the last timer interval.
      We could attempt to calculate the total number of received packets by
      doing a subtraction, but the iflib stack only seems to check if
      isc_pause_frames is non-zero.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Submitted by:	Jacob Keller <jacob.e.keller@intel.com>
      Reviewed by:	gallatin@
      Sponsored by:	Intel Corporation
      Differential Revision:	https://reviews.freebsd.org/D21868
  29. 07 May, 2019 1 commit
    • Marius Strobl's avatar
      o Avoid determining the MAC class (LEM/EM or IGB) - possibly even multiple · ca2ebb27
      Marius Strobl authored
        times - on every interrupt by using an own set of device methods for the
        IGB class. This translates to introducing igb_if_intr_{disable,enable}()
        and igb_if_{rx,tx}_queue_intr_enable() with that IGB-specific code moved
        out of their EM counterparts and otherwise continuing to use the EM IFDI
        methods also for IGB.
        Note that igb_if_intr_{disable,enable}() also issue E1000_WRITE_FLUSH as
        lost with the conversion of igb(4) to iflib(4).
        Also note, that the em_if_{disable,enable}_intr() methods are renamed to
        em_if_intr_{disable,enable}() for consistency with the names used in the
        interface declaration.
      o In em_intr():
        - Don't bother to bail out if the interrupt type is "legacy", i. e. INTx
          or MSI, as iflib(4) doesn't use ift_legacy_intr methods for MSI-X. All
          other iflib(4)-based drivers avoid this check, too.
        - Given that only the MSI-X interrupts have one-shot behavior (by taking
          advantage of the EIAC register), explicitly disable interrupts. Hence,
          em_intr() now matches what {em,igb}_irq_fast() previously did (in case
          of igb(4) supposedly also to work around MSI message reordering errata
          on certain systems).
      o In em_if_intr_disable():
        - Clear the EIAC register unconditionally for 82574 and not just in case
          of MSI-X, matching em_if_intr_enable() and bringing back the last hunk
          of r206437 lost with the iflib(4) conversion.
        - Write to EM_EIAC for clearing said register instead of to the IGB-only
          E1000_EIAC used ever since the iflib(4) conversion.
      Reviewed by:	shurd
      Differential Revision:	https://reviews.freebsd.org/D20176
  30. 19 Mar, 2019 1 commit
    • Eric Joyner's avatar
      iflib: expose the Rx mbuf buffer size to drivers · 1b9d9394
      Eric Joyner authored
      From Jake:
      iflib_fl_setup calculates a suitable buffer size for the Rx mbufs based
      on the isc_max_frame_size value that drivers setup. This calculation is
      repeated by drivers when programming their hardware with the size of
      each Rx buffer.
      This can lead to a mismatch where the iflib mbuf size is different from
      the expected size of the buffer as programmed by the hardware. This can
      lead to unexpected results.
      If iflib ever wants to support mbuf sizes larger than one page, every
      driver must be updated to account for the new possible buffer sizes.
      Fix this by calculating the mbuf size prior to calling IFDI_INIT, and
      adding the iflib_get_rx_mbuf_sz function which will expose this value to
      drivers, so that they do not repeat the same calculation.
      Submitted by:	Jacob Keller <jacob.e.keller@intel.com>
      Reviewed by:	shurd@, erj@
      MFC after:	1 week
      Sponsored by:	Intel Corporation
      Differential Revision:	https://reviews.freebsd.org/D19489
  31. 05 Mar, 2019 1 commit
    • Eric Joyner's avatar
      Remove references to CONTIGMALLOC_WORKS in iflib and em · bc408c7d
      Eric Joyner authored
      From Jake:
      "The iflib_fl_setup() function tries to pick various buffer sizes based
      on the max_frame_size value defined by the parent driver. However, this
      code was wrapped under CONTIGMALLOC_WORKS, which was never actually
      defined anywhere.
      This same code pattern was used in if_em.c, likely trying to match
      what iflib uses.
      Since CONTIGMALLOC_WORKS is not defined, remove this dead code from
      iflib_fl_setup and if_em.c
      Given that various iflib drivers appear to be using a similar
      calculation, it might be worth making this buffer size a value that the
      driver can peek at in the future."
      Submitted by:	Jacob Keller <jacob.e.keller@intel.com>
      Reviewed by:	shurd@
      MFC after:	1 week
      Sponsored by:	Intel Corporation
      Differential Revision:	https://reviews.freebsd.org/D19199