- 29 Feb, 2016 40 commits
-
-
Dmitriy Vyukov authored
e1000_clean_tx_irq cleans buffers and sets tx_ring->next_to_clean, then e1000_xmit_frame reuses the cleaned buffers. But there are no memory barriers when buffers gets recycled, so the recycled buffers can be corrupted. Use smp_store_release to update tx_ring->next_to_clean and smp_load_acquire to read tx_ring->next_to_clean to properly hand off buffers from e1000_clean_tx_irq to e1000_xmit_frame. The data race was found with KernelThreadSanitizer (KTSAN). Signed-off-by:
Dmitry Vyukov <dvyukov@google.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> (cherry picked from commit 9eab46b7) Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Joern Engel authored
Code was responsible for ~150ms scheduler latencies. Signed-off-by:
Joern Engel <joern@logfs.org> Signed-off-by:
Spencer Baugh <sbaugh@catern.com> Tested-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Right now ATR is not handling IPv6 extended headers, so ATR is not being performed on such packets. Fix that by skipping extended headers when they are present. This also fixes a problem where the ATR code was not checking that the inner protocol was actually TCP before setting up the signature rules. Since the protocol check is intimately involved with the extended header processing as well, this all gets fixed together. Signed-off-by:
Mark Rustad <mark.d.rustad@intel.com> Tested-by:
Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by:
-
Neerav Parikh authored
BugLink: http://bugs.launchpad.net/bugs/1536473 When FCoE is enabled with SR-IOV on the X550 NIC the hardware generates MDD events. This patch fixes these by setting the expected values in the Tx context descriptors for FCoE/FIP frames and adding a flush after writing the RDLEN register. Signed-off-by:
Neerav Parikh <neerav.parikh@intel.com> Tested-by:
-
Usha Ketineni authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Check whether the FCOE support is enabled for the devices to get the FDMI HBA attributes information instead of checking each device id. Also, add Model string information for X550. Signed-off-by:
Usha Ketineni <usha.k.ketineni@intel.com> Tested-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 If an outer UDP checksum is set, pass the skb up with CHECKSUM_NONE so that the stack will check the checksum. Do not increment an error counter, because we don't know that there is an actual error. Signed-off-by:
-
Emil Tantilov authored
BugLink: http://bugs.launchpad.net/bugs/1536473 In ixgbe_get_settings() the link status and speed of the interface are determined based on a read from the LINKS register via the call to mac.ops.check.link(). This can cause issues where external drivers may end up with unknown speed when calling ethtool_get_setings(). Instead of calling the mac.ops.check_link() we can report the speed from the adapter structure which is populated by the driver. Signed-off-by:
Emil Tantilov <emil.s.tantilov@intel.com> Tested-by:
-
Vasu Dev authored
BugLink: http://bugs.launchpad.net/bugs/1536473 PFC is configuration is skipped for X550 devices due to a incorrect device id check, fixing that to include X550 PFC configuration. Signed-off-by:
Vasu Dev <vasu.dev@intel.com> Tested-by:
-
Vasu Dev authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Use fcoe_ddp_xid from netdev as this is correctly set for different device IDs to avoid DDP skip error on X550 as "xid=0x20b out-of-range" Signed-off-by:
-
Vasu Dev authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Currently credit_refill and credit_max could be zero for a TC and that is causing Tx hang for CEE mode configuration, so to fix that have at min credit assigned to a TC and that is as what IEEE mode already does. Change-ID: If652c133093a21e530f4e9eab09097976f57fb12 Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 When I had rewritten the code for ixgbe_clear_vf_vlans() it looks like I had transitioned back and forth between using word as an offset and using word as a register offset. As a result I honestly don't see how the code was working before other than the fact that resetting the VLANs on the VF like didn't do much to clear them. Another issue found is that the mask was using a divide instead of a modulus. As a result the mask bit was incorrectly being set to either bit 0 or 1 based on the value of the VF being tested. As a result the wrong VFs were having their VLANs cleared if they were enabled. I have updated the code so that word represents the offset in the array. This way we can use the modulus and xor operations and they will make sense instead of being performed on a 4 byte aligned value. I replaced the statement "(word % 2) ^ 1" with "~word % 2" in order to reduce the line length as the line exceeded 80 characters with the register name inserted. The two should be equivalent so the change should be safe. Reported-by:
Alexander Duyck <aduyck@mirantis.com> Tested-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 The X550EM_x revision check needs to check a value, not just a bit. Use a mask and check the value. Also remove the redundant check inside the ixgbe_enter_lplu_t_x550em, because it can only be called when both the mac type and revision check pass. Signed-off-by:
-
Emil Tantilov authored
BugLink: http://bugs.launchpad.net/bugs/1536473 X550 allows for up to 64 RSS queues, but the driver can have max of 63 (-1 MSIX vector for link). On systems with >= 64 CPUs the driver will set the redirection table for all 64 queues which will result in packets being dropped. Signed-off-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Clean up minor redundancy in the setting of hw_enc_features that makes it appears that X550 uniquely has more encapsulation features than other devices. The driver only supports one more feature, so make it look that way. No longer set NETIF_F_SG since that is set by the register_netdev call. Thanks to Alex Duyck for noticing this slight confusion. Reported-by:
-
Veola Nazareth authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Ethtool reports backplane type interfaces as 1000/10000baseT link modes. This has been corrected to report the media as KR, KX or KX4 based on the backplane interface present. Signed-off-by:
Veola Nazareth <veola.nazareth@intel.com> Tested-by:
-
Emil Tantilov authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Add missing QSFP PHY types to allow for more accurate reporting of port settings. Signed-off-by:
-
Emil Tantilov authored
BugLink: http://bugs.launchpad.net/bugs/1536473 adapter->rx_itr_setting is not a mask so check it with == instead of & do not default to 12K interrupts in ixgbevf_set_itr() There should be no functional effect from these changes. Signed-off-by:
-
William Dauchy authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This is the same patch as for ixgbe but applied differently according to busy polling. See commit 5d6002b7 ("ixgbe: Fix handling of NAPI budget when multiple queues are enabled per vector") Signed-off-by:
William Dauchy <william@gandi.net> Tested-by:
-
Emil Tantilov authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Some X550 devices can connect at 2.5Gbps during fail-over, but only with certain link partners. Also setting the advertised speed will not work so we do not report it as supported to avoid confusion. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This patch guarantees that the VFs do not have access to VLANs that they were not supposed to. What this patch does is add code so that we delete the previous port VLAN after adding a new one, and if we reset the VF we clear all of the filters associated with it. Previously the code was leaving all previous VLANs mapped to the VF and they didn't get deleted unless the VF specifically requested it or if the PF itself was reset. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This patch makes certain that we clear the pool mappings added when we configure default MAC addresses for the interface. Without this we run the risk of leaking an address into pool 0 which really belongs to VF 0 when SR-IOV is enabled. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This patch is a follow-on for enabling VLAN promiscuous and allowing the PF to add VLANs without adding a VLVF entry. What this patch does is go through and free the VLVF registers if they are not needed as the VLAN belongs only to the PF which is the default pool. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This patch adds support for VLAN promiscuous with SR-IOV enabled. The code prior to this patch was only adding the PF to VLANs that the VF had added. As such enabling promiscuous mode would actually not add any additional VLAN filters so visibility was limited. This lead to a number of issues as the bridge and OVS would expect us to accept all VLAN tagged packets when promiscuous mode was enabled, and instead we would filter out most if not all depending on the configuration of the PF. With this patch what we do is set all the bits in the VFTA and all of the VLVF bits associated with the pool belonging to the PF. By doing this the PF is guaranteed to receive all VLAN tagged traffic associated with the RAR filters assigned to the PF. In addition we will clean up those same bits in the event of promiscuous mode being disabled. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This patch is meant to reduce the complexity of the search function used for finding a VLVF entry associated with a given VLAN ID. The previous code was searching from bottom to top. I reordered it to search from top to bottom. In addition I pulled an AND statement out of the loop and instead replaced it with an OR statement outside the loop. This should help to reduce the overall size and complexity of the function. There was also some formatting I cleaned up in regards to whitespace and such. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This patch adds support for bypassing the VLVF entry creation when the PF is adding a new VLAN. The advantage to doing this is that we can then save the VLVF entries for the VFs which must have them in order to function, versus the PF which can fall back on the default pool entry. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This patch addresses several issues within the VLVF and VLVFB configuration First was the fact that code was overly complicated with multiple conditional paths depending on if we adding or removing and which bit we were going to add or remove. Instead of messing with all that I have simplified it by using (vid / 32) and (1 - vid / 32) to identify our register and the other vlvfb register. Second was the fact that we were likely leaking a few packets into the PF in cases where we were deleting an entry and the VFTA filter for that entry as the ordering was such that we deleted the pool and then the VLAN filter instead of the other way around. I have updated that by adding a check for no bits being set and if that occurs we clear things up in the proper order. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 In order to clear the way for upcoming work I thought it best to drop the level of indent in the ixgbe_set_vfta_generic function. Most of the code is held in the virtualization specific section. So the easiest approach is to just add a jump label and jump past the bulk of the code if it is not enabled. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This patch simplifies the logic for setting the VFTA register by removing the number of conditional checks needed. Instead we just use some boolean logic to generate vfta_delta, and if that is set then we xor the vfta by that value and write it back. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 The code for checking the PF bit in ixgbe_set_vf_vlan_msg was using the wrong offset and as a result it was pulling the VLAN off of the PF even if there were VFs numbered greater than 40 that still had the VLAN enabled. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Add a check to make certain mac_table was actually allocated and is not NULL. If it is NULL return -ENOMEM and allow the probe routine to fail rather then causing a NULL pointer dereference further down the line. Signed-off-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Check for and handle IPv6 extended headers so that Tx checksum offload can be done. Also use skb_checksum_help for unexpected cases. Thanks to Tom Herbert for noticing these problems. Thanks to Alexander Duyck for seeing how to coalesce the error handling into one location. Reported-by:
Tom Herbert <tom@herbertland.com> Signed-off-by:
Darin Miller <darin.j.miller@intel.com> Signed-off-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Instead of inhibiting PHY power control when manageability is present, only inhibit turning PHY power off when manageability is present. Consequently, PHY power will always be turned on when requested. Without this patch, some systems with X540 or X550 devices in some conditions will never get link. Signed-off-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Check for and handle IPv6 extended headers so that Tx checksum offload can be done. Also use skb_checksum_help for unexpected cases. Thanks to Tom Herbert for noticing these problems. Thanks to Alexander Duyck for recognizing problems with the first version of this patch and recognizing how to coalesce error conditions into a single location. Reported-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Save VF device pointers and take references to speed accesses used to monitor the device behavior to avoid slot resets. The saved information avoids lock contention during the search used to access each of the VFs. Signed-off-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 According to the datasheets, the driver should wait for the master disable bit to read as being set before checking the status register for master disable. Reported-by:
Dan Streetman <dan.streetman@canonical.com> Signed-off-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 The ixgbe driver was violating the specification in the datasheet by not waiting 1ms before checking for the reset bit clearing. This is called out for devices supported by ixgbe, so implement the required delay. Reported-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 The X550EM_x devices handle clocking differently, so update the PTP implementation to accommodate them. This involves significant changes to ixgbe's PTP code to accommodate the new range of behaviors including things like non-power-of-2 clock wrapping. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This change makes it so that we allow the PF to make use of all free RAR entries for FDB use if needed. Previously the code limited us to 16 unicast entries, however this was shared between MACVLAN which wasn't limited and the FDB code which was. So instead of treating the FDB code as a second class citizen I have updated it so that it has access to just as many entries as the MACVLAN filters. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This change replaces the ixgbe_write_uc_addr_list call in ixgbe_set_rx_mode with a call to __dev_uc_sync instead. This works much better with the MAC addr list code that was already in place and solves an issue in which you couldn't remove an FDB address without having to reset the port. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 In the process of tracking down a memory leak when adding/removing FDB entries I had to go through the MAC address configuration code for ixgbe. In the process of doing so I found a number of issues that impacted readability and performance. This change updates the code in general to clean it up so it becomes clear what each step is doing. From what I can tell there a couple of bugs cleaned up in this code. First is the fact that the MAC addresses were being double counted for the PF. As a result once entries up to 63 had been used you could no longer add additional filters. A simple test case for this: for i in `seq 0 96` do ip link add link ens8 name mv$i type macvlan ip link set dev mv$i up done Test script: ethregs -s 0:8.0 | grep -e "RAH" | grep 8000....$ When things are working correctly RAL/H registers 1 - 97 will be consumed. In the failing case it will stop at 63 and prevent any further filters from being added. Signed-off-by:
-
