Hello,
Upstream commit 11fbb1bfb5bc8c98b2d7db9da332b5e568f4aaab ("ice: use relative VSI index for VFs VSIs") was applied to stable 6.1, 6.6 and 6.8:
6.1: 5693dd6d3d01f0eea24401f815c98b64cb315b67 6.6: c926393dc3442c38fdcab17d040837cf4acad1c3 6.8: d3da0d4d9fb472ad7dccb784f3d9de40d0c2f6a9
However, it was a part of a series submitted to net-next [1]. Applying this one patch on its own broke the VF devices created with the ice as a PF:
# [ 307.688237] iavf: Intel(R) Ethernet Adaptive Virtual Function Network Driver # [ 307.688241] Copyright (c) 2013 - 2018 Intel Corporation. # [ 307.688424] iavf 0000:af:01.0: enabling device (0000 -> 0002) # [ 307.758860] iavf 0000:af:01.0: Invalid MAC address 00:00:00:00:00:00, using random # [ 307.759628] iavf 0000:af:01.0: Multiqueue Enabled: Queue pair count = 16 # [ 307.759683] iavf 0000:af:01.0: MAC address: 6a:46:83:88:c2:26 # [ 307.759688] iavf 0000:af:01.0: GRO is enabled # [ 307.790937] iavf 0000:af:01.0 ens802f0v0: renamed from eth0 # [ 307.896041] iavf 0000:af:01.0: PF returned error -5 (IAVF_ERR_PARAM) to our request 6 # [ 307.916967] iavf 0000:af:01.0: PF returned error -5 (IAVF_ERR_PARAM) to our request 8
The VF initialization fails and the VF device is completely unusable.
This can be fixed either by: 1 - Reverting the above mentioned commit (upstream 11fbb1bfb5bc8c98b2d7db9da332b5e568f4aaab)
Or,
2 - applying the following upstream commits (part of the series): a) a21605993dd5dfd15edfa7f06705ede17b519026 ("ice: pass VSI pointer into ice_vc_isvalid_q_id") b) 363f689600dd010703ce6391bcfc729a97d21840 ("ice: remove unnecessary duplicate checks for VF VSI ID")
Thanks, Ahmed