- 29 Feb, 2016 40 commits
-
-
Jan Beulich authored
The combined effect of commits 6423fc34 ("igb: do not re-init SR-IOV during probe") and ceee3450 ("igb: make sure SR-IOV init uses the right number of queues") causes VFs no longer getting set up, leading to NULL pointer dereferences due to the adapter's ->vf_data being NULL while ->vfs_allocated_count is non-zero. The first commit not only neglected the side effect of igb_sriov_reinit() that the second commit tried to account for, but also that of setting IGB_FLAG_HAS_MSIX, without which igb_enable_sriov() is effectively a no-op. Calling igb_{,re}set_interrupt_capability() as done here seems to address this, but I'm not sure whether this is better than sinply reverting the other two commits. Signed-off-by:
Jan Beulich <jbeulich@suse.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> (cherry picked from commit be06998f) Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Todd Fujinaka authored
The i210 has two EEPROM access registers that are located in non-standard offsets: EEARBC and EEMNGCTL. EEARBC was fixed previously and EEMNGCTL should also be corrected. Reported-by:
Roman Hodek <roman.aud@siemens.com> Signed-off-by:
Todd Fujinaka <todd.fujinaka@intel.com> Tested-by:
-
Jarod Wilson authored
I've got a startech thunderbolt dock someone loaned me, which among other things, has the following device in it: 08:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03) This hotplugs just fine (kernel 4.2.0 plus a patch or two here): [ 863.020315] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.2.18-k [ 863.020316] igb: Copyright (c) 2007-2014 Intel Corporation. [ 863.028657] igb 0000:08:00.0: enabling device (0000 -> 0002) [ 863.062089] igb 0000:08:00.0: added PHC on eth0 [ 863.062090] igb 0000:08:00.0: Intel(R) Gigabit Ethernet Network Connection [ 863.062091] igb 0000:08:00.0: eth0: (PCIe:2.5Gb/s:Width x1) e8:ea:6a:00:1b:2a [ 863.062194] igb 0000:08:00.0: eth0: PBA No: 000200-000 [ 863.062196] igb 0000:08:00.0: Using MSI-X interrupts. 4 rx queue(s), 4 tx queue(s) [ 863.064889] igb 0000:08:00.0 enp8s0: renamed from eth0 But disconnecting it is another story: [ 1002.807932] igb 0000:08:00.0: removed PHC on enp8s0 [ 1002.807944] igb 0000:08:00.0 enp8s0: PCIe link lost, device now detached [ 1003.341141] ------------[ cut here ]------------ [ 1003.341148] WARNING: CPU: 0 PID: 199 at lib/iomap.c:43 bad_io_access+0x38/0x40() [ 1003.341149] Bad IO access at port 0x0 () [ 1003.342767] Modules linked in: snd_usb_audio snd_usbmidi_lib snd_rawmidi igb dca firewire_ohci firewire_core crc_itu_t rfcomm ctr ccm arc4 iwlmvm mac80211 fuse xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw iptable_filter bnep dm_mirror dm_region_hash dm_log dm_mod coretemp x86_pkg_temp_thermal intel_powerclamp kvm_intel snd_hda_codec_hdmi kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel drbg [ 1003.342793] ansi_cprng aesni_intel hp_wmi aes_x86_64 iTCO_wdt lrw iTCO_vendor_support ppdev gf128mul sparse_keymap glue_helper ablk_helper cryptd snd_hda_codec_realtek snd_hda_codec_generic microcode snd_hda_intel uvcvideo iwlwifi snd_hda_codec videobuf2_vmalloc videobuf2_memops snd_hda_core videobuf2_core snd_hwdep btusb v4l2_common btrtl snd_seq btbcm btintel videodev cfg80211 snd_seq_device rtsx_pci_ms bluetooth pcspkr input_leds i2c_i801 media parport_pc memstick rfkill sg lpc_ich snd_pcm 8250_fintek parport joydev snd_timer snd soundcore hp_accel ie31200_edac mei_me lis3lv02d edac_core input_polldev mei hp_wireless shpchp tpm_infineon sch_fq_codel nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables autofs4 xfs libcrc32c sd_mod sr_mod cdrom rtsx_pci_sdmmc mmc_core crc32c_intel serio_raw rtsx_pci [ 1003.342822] nouveau ahci libahci mxm_wmi e1000e xhci_pci hwmon ptp drm_kms_helper pps_core xhci_hcd ttm wmi video ipv6 [ 1003.342839] CPU: 0 PID: 199 Comm: kworker/0:2 Not tainted 4.2.0-2.el7_UNSUPPORTED.x86_64 #1 [ 1003.342840] Hardware name: Hewlett-Packard HP ZBook 15 G2/2253, BIOS M70 Ver. 01.07 02/26/2015 [ 1003.342843] Workqueue: pciehp-3 pciehp_power_thread [ 1003.342844] ffffffff81a90655 ffff8804866d3b48 ffffffff8164763a 0000000000000000 [ 1003.342846] ffff8804866d3b98 ffff8804866d3b88 ffffffff8107134a ffff8804866d3b88 [ 1003.342847] ffff880486f46000 ffff88046c8a8000 ffff880486f46840 ffff88046c8a8098 [ 1003.342848] Call Trace: [ 1003.342852] [<ffffffff8164763a>] dump_stack+0x45/0x57 [ 1003.342855] [<ffffffff8107134a>] warn_slowpath_common+0x8a/0xc0 [ 1003.342857] [<ffffffff810713c6>] warn_slowpath_fmt+0x46/0x50 [ 1003.342859] [<ffffffff8133719e>] ? pci_disable_msix+0x3e/0x50 [ 1003.342860] [<ffffffff812f6328>] bad_io_access+0x38/0x40 [ 1003.342861] [<ffffffff812f6567>] pci_iounmap+0x27/0x40 [ 1003.342865] [<ffffffffa0b728d7>] igb_remove+0xc7/0x160 [igb] [ 1003.342867] [<ffffffff8132189f>] pci_device_remove+0x3f/0xc0 [ 1003.342869] [<ffffffff81433426>] __device_release_driver+0x96/0x130 [ 1003.342870] [<ffffffff814334e3>] device_release_driver+0x23/0x30 [ 1003.342871] [<ffffffff8131b404>] pci_stop_bus_device+0x94/0xa0 [ 1003.342872] [<ffffffff8131b3ad>] pci_stop_bus_device+0x3d/0xa0 [ 1003.342873] [<ffffffff8131b3ad>] pci_stop_bus_device+0x3d/0xa0 [ 1003.342874] [<ffffffff8131b516>] pci_stop_and_remove_bus_device+0x16/0x30 [ 1003.342876] [<ffffffff81333f5b>] pciehp_unconfigure_device+0x9b/0x180 [ 1003.342877] [<ffffffff81333a73>] pciehp_disable_slot+0x43/0xb0 [ 1003.342878] [<ffffffff81333b6d>] pciehp_power_thread+0x8d/0xb0 [ 1003.342885] [<ffffffff810881b2>] process_one_work+0x152/0x3d0 [ 1003.342886] [<ffffffff8108854a>] worker_thread+0x11a/0x460 [ 1003.342887] [<ffffffff81088430>] ? process_one_work+0x3d0/0x3d0 [ 1003.342890] [<ffffffff8108ddd9>] kthread+0xc9/0xe0 [ 1003.342891] [<ffffffff8108dd10>] ? kthread_create_on_node+0x180/0x180 [ 1003.342893] [<ffffffff8164e29f>] ret_from_fork+0x3f/0x70 [ 1003.342894] [<ffffffff8108dd10>] ? kthread_create_on_node+0x180/0x180 [ 1003.342895] ---[ end trace 65a77e06d5aa9358 ]--- Upon looking at the igb driver, I see that igb_rd32() attempted to read from hw_addr and failed, so it set hw->hw_addr to NULL and spit out the message in the log output above, "PCIe link lost, device now detached". Well, now that hw_addr is NULL, the attempt to call pci_iounmap is obviously not going to go well. As suggested by Mark Rustad, do something similar to what ixgbe does, and save a copy of hw_addr as adapter->io_addr, so we can still call pci_iounmap on it on teardown. Additionally, for consistency, make the pci_iomap call assignment directly to io_addr, so map and unmap match. Signed-off-by:
Jarod Wilson <jarod@redhat.com> Tested-by:
-
Todd Fujinaka authored
Initialize the 88E1543 PHY. Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1534647Signed-off-by:
-
Jesse Brandeburg authored
BugLink: http://bugs.launchpad.net/bugs/1536474 Somehow an ID that has never been productized is in the code. There are no plans to use it, so just get rid of it. Change-ID: I59117d48ea9ee0360b0fe33833ac8092f8a24b4c Signed-off-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
-
Anjali Singhai Jain authored
BugLink: http://bugs.launchpad.net/bugs/1536474 If the driver calls skb_set_hash even with a zero hash, that indicates to the stack that the hash calculation is offloaded in hardware. So the Stack doesn't do a SW hash which is required for load balancing if the user decides to turn of rx-hashing on our device. This patch fixes the path so that we do not call skb_set_hash if the feature is disabled. Change-ID: Ic4debfa4ff91b5a72e447348a75768ed7a2d3e1b Signed-off-by:
Anjali Singhai Jain <anjali.singhai@intel.com> Tested-by:
-
Sowmini Varadhan authored
BugLink: http://bugs.launchpad.net/bugs/1536474 This is the i40e equivalent of commit c762dff2 ("ixgbe: Look up MAC address in Open Firmware or IDPROM"). As with that fix, attempt to look up the MAC address in Open Firmware on systems that support it, and use IDPROM on SPARC if no OF address is found. In the case of the i40e there is an assumption that the default mac address has already been set up as the primary mac filter on probe, so if this filter is obtained from the Open Firmware or IDPROM, an explicit write is needed via i40e_aq_mac_address_write() and i40e_aq_add_macvlan() invocation. The I40E_FLAG_PF_MAC flag in the platform-private i40e_pf structure tracks whether a platform-specific mac address was found, in which case calls to i40e_aq_mac_address_write() and i40e_aq_add_macvlan() will be triggered. Reviewed-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Sowmini Varadhan <sowmini.varadhan@oracle.com> Acked-by:
Shannon Nelson <shannon.nelson@intel.com> Tested-by:
-
Mitch Williams authored
BugLink: http://bugs.launchpad.net/bugs/1536474 Allow the user to specify a zero MAC address for VFs. This removes the existing MAC address and allows the VF to use a random address. Libvirt does this normally when removing a VF from a VM. Signed-off-by:
Mitch Williams <mitch.a.williams@intel.com> Tested-by:
-
Mitch Williams authored
BugLink: http://bugs.launchpad.net/bugs/1536474 When VFs are being reset, there is a brief window of time when they cannot be configured because they don't have a VSI to configure. If a script is quick, it can fall through that window. To avoid defenestration, log a useful error message and return -EAGAIN. Signed-off-by:
-
Singhai, Anjali authored
BugLink: http://bugs.launchpad.net/bugs/1536474 This patch adds a call to geneve_get_rx_port in i40e so that when it comes up it can learn about the existing geneve tunnels. Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit cd866606) Signed-off-by:
-
Singhai, Anjali authored
BugLink: http://bugs.launchpad.net/bugs/1536474 This patch adds an op that the drivers can call into to get existing geneve ports. Signed-off-by:
-
Singhai, Anjali authored
BugLink: http://bugs.launchpad.net/bugs/1536474 This patch adds driver hooks to implement ndo_ops to add/del udp port in the HW to identify GENEVE tunnels. Signed-off-by:
Kiran Patil <kiran.patil@intel.com> Signed-off-by:
-
Singhai, Anjali authored
BugLink: http://bugs.launchpad.net/bugs/1536474 Add ndo_ops to add/del UDP ports to a device that supports geneve offload. v2: Comment fix. Signed-off-by:
-
Tom Herbert authored
BugLink: http://bugs.launchpad.net/bugs/1536474 Add support to enable and disable UDP checksums via netlink. This is similar to how VXLAN and GUE allow this. This includes support for enabling the UDP zero checksum (for both TX and RX). Signed-off-by:
Tom Herbert <tom@herbertland.com> Signed-off-by:
-
Catherine Sullivan authored
BugLink: http://bugs.launchpad.net/bugs/1536474 Bump. Change-ID: I2b8976bde070244de144e2ed8990b083de39f332 Signed-off-by:
Catherine Sullivan <catherine.sullivan@intel.com> Tested-by:
-
Mitch Williams authored
BugLink: http://bugs.launchpad.net/bugs/1536474 Generate version strings like the PF driver does. This gives us more flexibility to add suffixes to the version string at build time. Change-ID: I0a5ca0783dd8fb849516bfc1e37ea070127847bd Signed-off-by:
-
Shannon Nelson authored
BugLink: http://bugs.launchpad.net/bugs/1536474 Clean the whole mac filter list when resetting after an intermediate add or delete push to the firmware. The code had evolved from using a list from the stack to a heap allocation, but the memset() didn't follow the change correctly. This now cleans the whole list rather that just part of the first element. Change-ID: I4cd03d5a103b7407dd8556a3a231e800f2d6f2d5 Reported-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
-
Anjali Singhai Jain authored
BugLink: http://bugs.launchpad.net/bugs/1536474 X722 supports Expanded version of TCP, UDP PCTYPES for RSS. Add a Virtchnl offload to support this. Without this patch with X722 devices, driver will set wrong PCTYPES for VF and UDP flows will not fan out. Change-ID: I04fe4988253b7cd108c9179a643c969764efcb76 Signed-off-by:
-
Mitch Williams authored
BugLink: http://bugs.launchpad.net/bugs/1536474 These messages seem big and scary, but they're really not. The driver can fully recover from any of these. The overflow error in particular can happen when enabling a bunch of VFs and the VF driver is not blacklisted. Since these messages are really for debugging purposes, reclassify them as such. Change-ID: I628d0f5e135e7063450ba05393a50b7af23aa6d7 Signed-off-by:
-
Michal Kosiarz authored
BugLink: http://bugs.launchpad.net/bugs/1536474 This is a part of implementation which contains data structures and opcode for new AQ command. There's a new ARQ message that gets sent near the end of the NVM update process that the driver should recognize and ignore, rather than printing an Unknown Event error. Change-ID: I04830a5bcae14823e16b9424cc4165e169336c1f Signed-off-by:
Michal Kosiarz <michal.kosiarz@intel.com> Acked-by:
-
Kamil Krawczyk authored
BugLink: http://bugs.launchpad.net/bugs/1536474 Current implementation generates compilation warnings. Change-ID: Icceefb50fe62aefaf90a64afb7192e08355a4ec5 Signed-off-by:
Kamil Krawczyk <kamil.krawczyk@intel.com> Acked-by:
-
Mitch Williams authored
BugLink: http://bugs.launchpad.net/bugs/1536474 If the driver gets unloaded during reset recovery, it's possible that it will attempt to free resources when they're already free. Add a check to make sure that the Tx and Rx rings actually exist before dereferencing them to free resources. Change-ID: I4d2b7e9ede49f634d421a4c5deaa5446bc755eee Signed-off-by:
-
Mitch Williams authored
BugLink: http://bugs.launchpad.net/bugs/1536474 When VFs are created, the MAC address defaults to all zeros, indicating to the VF driver that it should use a random MAC address. However, the PF driver was incorrectly adding this zero MAC to the filter table, along with the VF's randomly generated MAC address. Check for a good address before adding the default filter. While we're at it, make the error message a bit more useful. Change-ID: Ia100947d68140e0f73a19ba755cbffc3e79a8fcf Signed-off-by:
-
Mitch Williams authored
BugLink: http://bugs.launchpad.net/bugs/1536474 The virtual channel interface was using incorrect semantics to remove MAC addresses, which would leave incorrect filters active when using VLANs. To correct this, add a new function that unconditionally removes MAC addresses from all VLANs, and call this function when the VF requests a MAC filter removal. Change-ID: I69826908ae4f6c847f5bf9b32f11faa760189c74 Signed-off-by:
-
Jesse Brandeburg authored
BugLink: http://bugs.launchpad.net/bugs/1536474 BIT_ULL was used on a u32 or less where it can simply be BIT. This fixes some trivial static analyzer warnings. Chomp, chomp. Tested with objdump of binary before and after, no changes to code. Change-ID: I6245e9abd447192dbde1669c747aeb2878126c7d Signed-off-by:
-
Singhai, Anjali authored
BugLink: http://bugs.launchpad.net/bugs/1536474 This reverts commit 8fe26999. The case where VXLAN is a module and i40e driver is inbuilt will not be handled properly with this change since i40e will have an undefined symbol vxlan_get_rx_port in it. v2: Add a signed-off-by. Signed-off-by:
-
Joe Perches authored
BugLink: http://bugs.launchpad.net/bugs/1536474 Commit 7fd89545 ("i40e: remove BUG_ON from feature string building") added defective output when I40E_FLAG_VEB_MODE_ENABLED was set in function i40e_print_features. Fix it. Miscellanea: - Remove unnecessary string variable - Add space before not after fixed strings - Use kmalloc not kzalloc - Don't initialize i to 0, use result of first snprintf Reported-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Jesse Brandeburg authored
BugLink: http://bugs.launchpad.net/bugs/1536474 1) remove duplicate include of tcp.h 2) put an ampersand at the end of a line instead of the beginning 3) remove a useless dev_info 4) match declaration of function to the implementation 5) repair incorrect comment 6) correct whitespace 7) remove unused define Signed-off-by:
-
Catherine Sullivan authored
BugLink: http://bugs.launchpad.net/bugs/1536474 Bump. Change-ID: Id8c83c64c973349a722bab40d285ad8ded8c28f7 Signed-off-by:
-
Mitch Williams authored
BugLink: http://bugs.launchpad.net/bugs/1536474 We shouldn't be using a bitwise operator here; it's not a bitwise operation. Use a logical operator instead. Why doesn't c have a logical-or-and-assign operator? Change-ID: Id84f3ca884910bed7073c84b1e16a102e958d0de Signed-off-by:
-
Mitch Williams authored
BugLink: http://bugs.launchpad.net/bugs/1536474 Operators should have spaces around them. Change-ID: I64735e9aa8618b9a5059a87ace1c999d6d3bfcfb Signed-off-by:
-
Neerav Parikh authored
BugLink: http://bugs.launchpad.net/bugs/1536474 The separate functions to gather Flow control Rx XOFF stats was to determine if the Tx for a queue was paused due to Link Flow Control(LFC) or Priority Flow Control(PFC). But, with recent change in the i40e driver the logic for checking th Tx hang has been removed and these functions don't do anything meaningful. Hence, there is no need to keep these separate functions to gather Rx XOFF stats for LFC or PFC. This patch removes these functions and moves the stat collection for XOFF Rx to the i40e_update_pf_stats() that collects all the PF stats. Change-ID: Iec1452dac3a6766f0d968e754cb407530d7c60cd Signed-off-by:
Neerav Parikh <neerav.parikh@intel.com> Tested-by:
-
Jesse Brandeburg authored
BugLink: http://bugs.launchpad.net/bugs/1536474 Instead of having our own custom symbol, we can just rely on whether or not the kernel has the feature enabled. In this case use IS_ENABLED(CONFIG_VXLAN) in order to handle built-in or module in the current BKM way. Change-ID: I5890fbb518ff8ed6bb07c3362fb0a8a829f9b241 Signed-off-by:
-
Jesse Brandeburg authored
BugLink: http://bugs.launchpad.net/bugs/1536474 Ethtool priv flags implementation to enable or disable packet split, which is a hardware feature that inspects headers and will put headers in a separate DMA buffer from the payload data. The driver was automatically choosing to enable packet split in some cases and this gives the user the ability to turn it off/on explicitly. to query state: ethtool --show-priv-flags ethx to enable: ethtool --set-priv-flags ethx packet-split on to disable: ethtool --set-priv-flags ethx packet-split off Why would anyone want this? Because some environments benefit from header/data split in the receive buffer, and the driver defaults to one or the other depending on environment/kernel parameters. Why didn't you implement a generic ethtool control for this feature? Because Intel hardware is the only hardware that supports header/data split. Change-ID: I803121e1eecc9ccb2884031fd85dd1110b3af66d Signed-off-by:
-
Mitch Williams authored
BugLink: http://bugs.launchpad.net/bugs/1536474 Don't use uint32_t type the kernel. Use u32 instead. No functional change. Change-ID: I77bbf3b6464edaef747c7104b43534032a4dba63 Signed-off-by:
-
Mitch Williams authored
BugLink: http://bugs.launchpad.net/bugs/1536474 i40e_sync_vsi_filters() is the surly teenager of this driver. It says it's going to report errors, but it doesn't actually do that most of the time. And when it does, it leaves a mess. Change this function to have a common exit point so it will properly release the busy lock on the VSI. Propagate errors to the callers. Finally, adjust a few callers to check for and deal with errors from this function. Change-ID: Ic6af4956491e72402ebb3c538a3c31a0ad7f8667 Signed-off-by:
-
Mitch Williams authored
BugLink: http://bugs.launchpad.net/bugs/1536474 These allocations don't need to be at atomic level. GFP_KERNEL is fine and they'll reduce stress on the allocator when the system is starved for memory. Change-ID: I3561d0399a681de0ad25291b6c848b224c1fde12 Signed-off-by:
-
Kiran Patil authored
BugLink: http://bugs.launchpad.net/bugs/1536474 This patch fixes the memory leak which would be seen otherwise when user programs flow-director filter using ethtool (sideband filter programming). When ethtool is used to program flow directory filter, 'raw_buf' gets allocated and it is supposed to be freed as part of queue cleanup. But check of 'tx_buffer->skb' was preventing it from being freed. Change-ID: Ief4f0a1a32a653180498bf6e987c1b4342ab8923 Signed-off-by:
-
Kiran Patil authored
BugLink: http://bugs.launchpad.net/bugs/1536474 This patch contains following changes: - detection and recovery logic (issue SW interrupt) has been moved to service_task from timeout function. - added some more debug info from tx_timeout. Logic to detect and recover TX queue hung is now two step process: - service_task detects TX queue hung and sets a bit(hung_detected) if it was not set. - if bit was set (means this is back-back hung condition detected), issue SW interrupt and clear the bit. - napi_poll clears the bit unconditionally since it cleans TX/RX queues. Change-ID: Ieed03a48927c845a988b3ff375090bf37caeb903 Signed-off-by:
-
