Page MenuHomeFreeBSD

ixgbe: Acquire lock for shared code API calls in handle_phy
ClosedPublic

Authored by rstone on Apr 28 2017, 3:13 PM.

Details

Reviewers
sbruno
Group Reviewers
Intel Networking

Diff Detail

Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 8961
Build 9354: arc lint + arc unit

Event Timeline

rstone created this revision.Apr 28 2017, 3:13 PM
sbruno edited edge metadata.Apr 28 2017, 9:12 PM

Maybe you've seen something that requires this lock acquisition in your testing. Can you explain why we need to acquire this lock here?

rstone added a comment.EditedMay 3 2017, 9:36 PM

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.

sbruno accepted this revision.Sep 27 2017, 6:52 PM
This revision is now accepted and ready to land.Sep 27 2017, 6:52 PM
sbruno closed this revision.May 13 2018, 3:40 PM

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.