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]
Message-ID: <ZIV6L+pIUvZ1tip4@shredder>
Date: Sun, 11 Jun 2023 10:39:27 +0300
From: Ido Schimmel <idosch@...dia.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: mkubecek@...e.cz, danieller@...dia.com, netdev@...r.kernel.org,
	vladyslavt@...dia.com, linux@...linux.org.uk, andrew@...n.ch
Subject: Re: [PATCH ethtool-next] sff-8636: report LOL / LOS / Tx Fault

On Thu, Jun 08, 2023 at 05:44:00PM -0700, Jakub Kicinski wrote:
> Report whether Loss of Lock, of Signal and Tx Faults were detected.
> Print "None" in case no lane has the problem, and per-lane "Yes" /
> "No"  if at least one of the lanes reports true.
      ^ double space

> 
> Signed-off-by: Jakub Kicinski <kuba@...nel.org>
> ---
> I was asked if "Linux reports" this information.
> I'm not very confident on the merits, I'm going by the spec.
> If it makes sense I'll send a similar patch for CMIS.

I have two AOC connected to each other. When both are up:

# ethtool -m swp13 | grep "Rx loss of signal" -A 4
        Rx loss of signal                         : None
        Tx loss of signal                         : None
        Rx loss of lock                           : None
        Tx loss of lock                           : None
        Tx adaptive eq fault                      : None

When I bring the other side down:

# ip link set dev swp14 down
# ethtool -m swp13 | grep "Rx loss of signal" -A 4
        Rx loss of signal                         : [ Yes, Yes, Yes, Yes ]
        Tx loss of signal                         : None
        Rx loss of lock                           : [ Yes, Yes, Yes, Yes ]
        Tx loss of lock                           : None
        Tx adaptive eq fault                      : None

When I bring the interface itself down:

# ip link set dev swp13 down
# ethtool -m swp13 | grep "Rx loss of signal" -A 4
        Rx loss of signal                         : [ Yes, Yes, Yes, Yes ]
        Tx loss of signal                         : [ Yes, Yes, Yes, Yes ]
        Rx loss of lock                           : [ Yes, Yes, Yes, Yes ]
        Tx loss of lock                           : [ Yes, Yes, Yes, Yes ]
        Tx adaptive eq fault                      : [ Yes, Yes, Yes, Yes ]

And I don't see these fields on PC:

# ethtool -m swp3 | grep "Rx loss of signal" -A 4

See one comment below.

[...]

> diff --git a/qsfp.h b/qsfp.h
> index aabf09fdc623..b4a0ffe06da1 100644
> --- a/qsfp.h
> +++ b/qsfp.h
> @@ -55,6 +55,8 @@
>  #define	 SFF8636_TX2_FAULT_AW	(1 << 1)
>  #define	 SFF8636_TX1_FAULT_AW	(1 << 0)
>  
> +#define	SFF8636_LOL_AW_OFFSET	0x05
> +
>  /* Module Monitor Interrupt Flags - 6-8 */
>  #define	SFF8636_TEMP_AW_OFFSET	0x06
>  #define	 SFF8636_TEMP_HALARM_STATUS		(1 << 7)
> @@ -525,9 +527,15 @@
>  /*  56h-5Fh reserved */
>  
>  #define	 SFF8636_OPTION_2_OFFSET	0xC1
> +/* Tx input equalizers auto-adaptive */
> +#define	  SFF8636_O2_TX_EQ_AUTO		(1 << 3)
>  /* Rx output amplitude */
>  #define	  SFF8636_O2_RX_OUTPUT_AMP	(1 << 0)
>  #define	 SFF8636_OPTION_3_OFFSET	0xC2
> +/* Rx CDR Loss of Lock */
> +#define	  SFF8636_O3_RX_LOL		(1 << 5)
> +/* Tx CDR Loss of Lock */
> +#define	  SFF8636_O3_TX_LOL		(1 << 4)

I'm looking at revision 2.10a and bit 4 is Rx while bit 5 is Tx.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ