netdev - Re: [PATCH net] Revert "ixgbe: Manual AN-37 for troublesome link partners for X550 SFI"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 23 May 2024 09:15:27 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: <kernel.org-fo5k2w@...arbi.fr>, Jeff Daly <jeffd@...icom-usa.com>, "Simon
 Horman" <horms@...nel.org>
CC: <netdev@...r.kernel.org>
Subject: Re: [PATCH net] Revert "ixgbe: Manual AN-37 for troublesome link
 partners for X550 SFI"

On 5/21/2024 2:05 PM, Jacob Keller wrote:
> 
> 
> On 5/21/2024 10:12 AM, kernel.org-fo5k2w@...arbi.fr wrote:
>> If any of you have the skills to develop a patch that tries to satisfy everyone, please know that I'm always available for testing on my hardware. If Jeff also has the possibilities, it's not impossible that we could come to a consensus. All we'd have to do would be to test the behavior of our equipment in the problematic situation.
>>
> 
> I would love a solution which fixes both cases. I don't currently have
> any idea what it would be.
> 

It looks like netdev pulled the revert. Given the lack of a full
understanding of the original fix posted from Jeff, I think this is the
right decision.

>> Isn't there someone at Intel who can contribute their expertise on the underlying technical reasons for the problem (obviously level 1 OSI) in order to guide us towards a state-of-the-art solution?
>>

I did create an internal ticket here to track and try to get a
reproduction so that some of our link experts can diagnose the issue
being seen.

I hope to have news I can report on this soon.

> I guess there is the option of some sort of toggle via ethtool/otherwise
> to allow selection... But users might try to enable this when link is
> faulty and end up hitting the case where once we try the AN-37, the
> remote switch refuses to try again until a cycle.
> 

Given that we have two cases where our current understanding is a need
for mutually exclusive behavior, we (Intel) would be open to some sort
of config option, flag, or otherwise toggle to enable the Silicom folks
without breaking everything else. I don't know what the acceptance for
such an idea is with the rest of the community.

I hope that internal reproduction task above may lead to a better
understanding and possibly a fix that can resolve both cases.