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 16:49:14 +0000
From: kernel.org-fo5k2w@...arbi.fr
To: "Jacob Keller" <jacob.e.keller@...el.com>, 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"

> 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.

Thank you very much for your investment.
I hope a solution can be found for Jeff.
 
> 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.

Super. Cela va peut-être faire remonter d'autres problèmes sous-jacent dans l'implémentation de la norme.

> 
> > 
> > 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.
>

> The link is an SFP-10GBase-CX1?

As I understand it, CX1 is the name given to Twinax copper cables such as the one I used in the experiments in this thread. It's therefore a priori the right value to display for this kind of connection (instead of “10000baseT/Full”).

Thanks again for your hard work in finding a solution. You can always contact me later so that I can carry out tests if you need. The machine is at least available for 1 year for testing purposes.

Best regards,
Yohan.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ