Page MenuHomeFreeBSD

Fix for direct attach cable and workaround for intermittent link issue with axgbe
ClosedPublic

Authored by rajesh1.kumar_amd.com on Jan 21 2021, 8:42 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Nov 13, 6:07 AM
Unknown Object (File)
Oct 14 2024, 11:23 PM
Unknown Object (File)
Oct 4 2024, 4:14 AM
Unknown Object (File)
Oct 4 2024, 1:26 AM
Unknown Object (File)
Oct 3 2024, 8:32 PM
Unknown Object (File)
Oct 3 2024, 5:26 AM
Unknown Object (File)
Oct 1 2024, 5:13 AM
Unknown Object (File)
Sep 24 2024, 5:31 PM

Details

Summary

This patch has fixes for link related issues with axgbe driver

Intermittently, some link issues observed with axgbe driver. By default,
axgbe driver does a receiver reset after predefined number of retries for the
link to come up. But intermittently, this receiver reset doesn't suffice.
In that case, as a workaround we need to reset the phy completely.

This patch introduces a sysctl where which can be set to reset the phy
completely, rather than just doing receiver reset.

This patch also has the necessary fixes for handling the direct attach cables
properly.

Test Plan

When trying with axgbe driver, if link doesn't comeup, the following sysctl
can be set as below.

Enable link workaround
dev.ax.X.link_workaround=1

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Wouldn't it be easier to always perform the complete phy reset if this is a known hardware issue? Or maye perform it automatically after a normal reset does not work?
I'm afraid that adding an obscure sysctl (obscure for anyone except for the axgbe developers) would be of little use. Unaware users wouldn't have a clue about what to do...
just my 2 cents

Wouldn't it be easier to always perform the complete phy reset if this is a known hardware issue? Or maye perform it automatically after a normal reset does not work?
I'm afraid that adding an obscure sysctl (obscure for anyone except for the axgbe developers) would be of little use. Unaware users wouldn't have a clue about what to do...
just my 2 cents

Thanks for your inputs @vmaffione. Resetting the receiver side is sufficient and supposed to recognize the link as per the spec. That is why the earlier code just do the receiver reset. But since it fails intermittently, we reset the complete phy as a workaround (not a fix) to get around this issue. We are internally working on this issue. Once a final resolution is arrived, this workaround can be removed.

For now, Once this patch is accepted, I will update the man page for the driver (D27800) with this sysctl for the users to be aware of it. Please let me know your comments.

Will the fix be provided as a firmware upgrade or how?
I could commit this change if you don't have someone else around that can do that for you.

Will the fix be provided as a firmware upgrade or how?
I could commit this change if you don't have someone else around that can do that for you.

Yes @vmaffione, the permanent fix would be most likely a BIOS update.

I don't have push access to the gerrit repo. So, it would be helpful if you can push these changes. I will update the man page once it's accepted. Thanks for all your inputs and time.

This revision was not accepted when it landed; it landed in state Needs Review.Jan 23 2021, 1:52 PM
This revision was automatically updated to reflect the committed changes.

@vmaffione, Sorry I just noticed that the stable/13 branch is created yesterday. So, can this patch be pushed to that branch as well? or do I need to submit the same patch separately for stable/13 branch?

It can be merged there (MFC'd) as well, after a period of a minimum of 3 days. There is no need to submit a separate patch.

It can be merged there (MFC'd) as well, after a period of a minimum of 3 days. There is no need to submit a separate patch.

That would be great. Thanks for the update @vmaffione