n the following bisect: # bad: [913011e5d0c07a71f3e2f174341e7f45b15eaa65] Revert "ixgbe: Return error on failure to allocate mac_table" # good: [4291ccca9ac6d20333c349fa6c6d4e9b79d4fabf] UBUNTU: Ubuntu-4.4.0-62.83
Where bad means "fixed" and good means "unfixed" (since I've reverted lots of ixgbe patches), this is the bisect log: git bisect start '913011e5d' '4291ccca' # bad: [cd559250820a01813656ef6edef3ee87551836fc] Revert "ixgbe: Reorder search to work from the top down instead of bottom up" git bisect bad cd559250820a01813656ef6edef3ee87551836fc # good: [3c7eb56223dd7c4a724384fbcd227036fbe1e349] Revert "ixgbe: Clear stale pool mappings" git bisect good 3c7eb56223dd7c4a724384fbcd227036fbe1e349 # bad: [c209e5021886f9168d96d55ea7bf10e88813bce1] Revert "ixgbe: Add support for VLAN promiscuous with SR-IOV" git bisect bad c209e5021886f9168d96d55ea7bf10e88813bce1 # good: [0da45985b746b23c29b754baedf13da4ec59bd77] Revert "ixgbe: Fix VLAN promisc in relation to SR-IOV" git bisect good 0da45985b746b23c29b754baedf13da4ec59bd77 And this is the reversion that made Ubuntu 4.4 kernel to work as expected: # first bad commit: [c209e5021886f9168d96d55ea7bf10e88813bce1] Revert "ixgbe: Add support for VLAN promiscuous with SR-IOV" ================= Meaning that this upstream commit: commit e1d0a2af2b30f5f0cbce2e4dd438d4da2433b226 Author: Alexander Duyck <adu...@mirantis.com> Date: Mon Nov 2 17:10:19 2015 -0800 ixgbe: Fix VLAN promisc in relation to SR-IOV 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 <adu...@mirantis.com> Tested-by: Phil Schmitt <phillip.j.schm...@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirs...@intel.com> Backported into Ubuntu 4.4 kernel by: commit ad740b71fba84e3d17bc0507d2cb696935cd944b Author: Alexander Duyck <adu...@mirantis.com> Date: Mon Nov 2 17:10:19 2015 -0800 ixgbe: Fix VLAN promisc in relation to SR-IOV 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 <adu...@mirantis.com> Tested-by: Phil Schmitt <phillip.j.schm...@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirs...@intel.com> (cherry picked from commit e1d0a2af2b30f5f0cbce2e4dd438d4da2433b226) Signed-off-by: Tim Gardner <tim.gard...@canonical.com> >From version: Ubuntu-4.4.0-9.24 (and existent in Ubuntu-4.4.0-62.83) because of https://bugs.launchpad.net/intel/+bug/1536473 These patches were backported likely during the development phase. Is the problematic one -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1658491 Title: VLAN SR-IOV regression for IXGBE driver Status in linux package in Ubuntu: In Progress Bug description: IXGBE driver, for SR-IOV setups, is misbehaving with VLANs. Description from affected user: - Create 2 networks (sriov 100 and 102 vlan) # neutron net-create --provider:physical_network=PHY0 --provider:network_type=vlan --provider:segmentation_id=100 PHY0_vlan_100 # neutron net-create --provider:physical_network=PHY0 --provider:network_type=vlan --provider:segmentation_id=102 PHY0_vlan_102 - Create the subnets: # neutron subnet-create PHY0_vlan_100 192.168.50.0/24 # neutron subnet-create PHY0_vlan_102 192.168.60.0/24 - Create the neutron ports: # neutron port-create e450757f-fec6-466e-bb21-a42a2019fe6b --name vlan_100_port1 --vnic-type direct # neutron port-create 32c468ed-7e1e-4267-bbbf-ec72d33e4454 --name vlan_102_port1 --vnic-type direct - Boot 2 VMs on 2 different hosts (add only 1 port to each of them + ovs dhcp network): # nova boot --flavor 789 --image ubuntu --nic net-id=1cf2a512-8963-413d-a745-99e758789c2b --nic port-id=92cf2867-cc0a-4e0d-aa87-14a345cdd708 102_port1_compute6 --key-name mkey --config-drive true --availability-zone nova:compute-0-6.domain.tld --poll # nova boot --flavor 789 --image ubutnu --nic net-id=1cf2a512-8963-413d-a745-99e758789c2b --nic port-id=baec6fd6-933d-4c58-94b6-44c50405d409 100_port1_compute5 --key-name mkey --config-drive true --availability-zone nova:compute-0-5.domain.tld --poll - After the VMs booted, configure the VFs: root@102-port1-compute6:~# ifconfig eth1 192.168.34.6 up root@100-port1-compute5:~# ifconfig eth1 192.168.34.5 up If I ping each other it works but it shouldn't work because in this case both of the VMs's interface (host VF) are in different vlans: - Pinging shouldn't work because the VMs interface (host VF) are in different VLANs. root@compute-0-5:~# ip link show eth6 8: eth6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2140 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether a0:36:9f:3f:1a:64 brd ff:ff:ff:ff:ff:ff vf 5 MAC fa:16:3e:f0:2c:e2, vlan 100, spoof checking on, link-state auto root@compute-0-6:~# ip link show eth5 8: eth5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2140 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether a0:36:9f:3f:20:88 brd ff:ff:ff:ff:ff:ff vf 7 MAC fa:16:3e:ce:69:41, vlan 101, spoof checking on, link-state auto But user can ping both VMs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1658491/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
