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: Tue, 21 May 2024 17:12:14 +0000
From: kernel.org-fo5k2w@...arbi.fr
To: "Jeff Daly" <jeffd@...icom-usa.com>, "Simon Horman" <horms@...nel.org>,
 "Jacob Keller" <jacob.e.keller@...el.com>
Cc: netdev@...r.kernel.org, kernel.org-fo5k2w@...arbi.fr
Subject: Re: [PATCH net] Revert "ixgbe: Manual AN-37 for troublesome link
 partners for X550 SFI"

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.

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?

Best regards.



21 mai 2024 à 18:49 "Jeff Daly" <jeffd@...icom-usa.com> a écrit:


> 
> > 
> > -----Original Message-----
> >  From: Simon Horman <horms@...nel.org>
> >  Sent: Tuesday, May 21, 2024 12:42 PM
> >  To: Jacob Keller <jacob.e.keller@...el.com>
> >  Cc: netdev@...r.kernel.org; Jeff Daly <jeffd@...icom-usa.com>; kernel.org-
> >  fo5k2w@...arbi.fr
> >  Subject: Re: [PATCH net] Revert "ixgbe: Manual AN-37 for troublesome link
> >  partners for X550 SFI"
> >  
> >  Caution: This is an external email. Please take care when clicking links or
> >  opening attachments.
> >  
> >  
> >  On Mon, May 20, 2024 at 05:21:27PM -0700, Jacob Keller wrote:
> >  This reverts commit 565736048bd5f9888990569993c6b6bfdf6dcb6d.
> > 
> >  According to the commit, it implements a manual AN-37 for some
> >  "troublesome" Juniper MX5 switches. This appears to be a workaround
> >  for a particular switch.
> > 
> >  It has been reported that this causes a severe breakage for other
> >  switches, including a Cisco 3560CX-12PD-S.
> > 
> >  The code appears to be a workaround for a specific switch which fails
> >  to link in SFI mode. It expects to see AN-37 auto negotiation in order
> >  to link. The Cisco switch is not expecting AN-37 auto negotiation.
> >  When the device starts the manual AN-37, the Cisco switch decides that
> >  the port is confused and stops attempting to link with it. This
> >  persists until a power cycle. A simple driver unload and reload does
> >  not resolve the issue, even if loading with a version of the driver which lacks
> >  this workaround.
> > 
> >  The authors of the workaround commit have not responded with
> >  clarifications, and the result of the workaround is complete failure
> >  to connect with other switches.
> > 
> >  This appears to be a case where the driver can either "correctly" link
> >  with the Juniper MX5 switch, at the cost of bricking the link with the
> >  Cisco switch, or it can behave properly for the Cisco switch, but fail
> >  to link with the Junipir MX5 switch. I do not know enough about the
> >  standards involved to clearly determine whether either switch is at
> >  fault or behaving incorrectly. Nor do I know whether there exists some
> >  alternative fix which corrects behavior with both switches.
> > 
> >  Revert the workaround for the Juniper switch.
> > 
> >  Fixes: 565736048bd5 ("ixgbe: Manual AN-37 for troublesome link
> >  partners for X550 SFI")
> >  Link:
> >  https://lore.kernel.org/netdev/cbe874db-9ac9-42b8-afa0-88ea910e1e99@in
> >  tel.com/T/
> >  Link:
> >  https://forum.proxmox.com/threads/intel-x553-sfp-ixgbe-no-go-on-pve8.1
> >  35129/#post-612291
> >  Signed-off-by: Jacob Keller <jacob.e.keller@...el.com>
> >  Cc: Jeff Daly <jeffd@...icom-usa.com>
> >  Cc: kernel.org-fo5k2w@...arbi.fr
> >  
> >  One of those awkward situations where the only known (in this case to Jacob
> >  and me) resolution to a regression is itself a regression (for a different setup).
> >  
> >  I think that in these kind of situations it's best to go back to how things were.
> >  
> >  Reviewed-by: Simon Horman <horms@...nel.org>
> > 
> 
> In principle, I don't disagree..... However, our customer was very sensitive to having any patches/workarounds needed for their configuration be part of the upstream. Aside from maintaining our own patchset (or figuring out whether there's a patch that works for everyone) is there a better solution?
>