Details
- Reviewers
sbruno - Group Reviewers
Intel Networking
Diff Detail
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 8961 Build 9354: arc lint + arc unit
Event Timeline
Maybe you've seen something that requires this lock acquisition in your testing. Can you explain why we need to acquire this lock here?
The history here is that we downloaded the latest Intel driver from their website last summer (version ixgbe-3.1.14). As it turns out, that version was missing r293334. With the locking not present in ixgbe_handle_msf() and ixgbe_handle_mod(), we found that sometimes after the remote end of the fiber brought link up, the driver would fail with the error "Unsupported SFP+ module type was detected." and would require manual intervention (ifconfig down/up) to restore functionality.
To fix that we manually added the locking to those two functions. Code inspection turned up the fact that ixgbe_handle_phy() is also missing locking around the shared code. I don't have any test cases that explicitly show that it's a problem, but I note that handle_lasi() seems to call things that ixgbe_setup_internal_phy() that definitely look like they need locking, as they read data via the I2C bus.
At this point, head is running an IFLIB version of ixgbe(4) so this is not needed (shouldn't be anyway).
stable/11 is running 3.2.12-k and shouldn't need this version either.