Hi, It's netplan.io that needs the fix, since it owns the whole flow (`embedded-switch-mode: switchdev` and `sriov_numvfs`) through `netplan- sriov-apply.service` and `netplan_cli/cli/sriov.py`.
The issue right now is the order of events in `apply_sriov_config()` / `set_numvfs_for_pf()`. Netplan sets `sriov_numvfs` first, so the kernel immediately starts auto-probing `mlx5_core` on each VF because `sriov_drivers_autoprobe` defaults to 1. Then a few lines down netplan tries to unbind them for switchdev. Basically netplan and the kernel wrestle for the driver at the exact same microsecond, and the Mellanox firmware just pulls the handbrake with a -110 timeout :)) The clean fix in netplan would be: 1. Before writing `sriov_numvfs`, check if `/sys/class/net/<PF>/device/sriov_drivers_autoprobe` exists and flip it to 0. 2. Write `sriov_numvfs`. VFs pop up without any driver probing them. 3. Switch devlink to switchdev (`devlink dev eswitch set ...`). It goes through cleanly with no busy/timeout lockups. 4. Flip `sriov_drivers_autoprobe` back to 1 (or let `netplan-sriov-rebind.service` bind the VF drivers). I tested this order on my testbed by tracing `netplan apply --sriov- only` and running the sequence manually — with autoprobe zeroed out beforehand, devlink switches instantly and `netplan-sriov-rebind` exits 0 without any firmware grumbling. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2166228 Title: Mellanox NIC is unable to enter switchdev mode To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2166228/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
