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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 12 Aug 2022 17:45:26 +0200 From: Stefan Mahr <dac922@....de> To: "Russell King (Oracle)" <linux@...linux.org.uk> Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH] net: sfp: reset fault retry counter on successful reinitialisation > On Fri, Aug 12, 2022 at 03:04:38PM +0200, Stefan Mahr wrote: >> This patch resets the fault retry counter to the default value, if the >> module reinitialisation was successful. Otherwise without resetting >> the counter, five (N_FAULT/N_FAULT_INIT) single TX_FAULT events will >> deactivate the module persistently. > > This is intentional - if a module keeps asserting its TX_FAULT status, > then there is something wrong with it, and for an optical module it > means that the laser is overloading (producing more output than it > should.) That is a safety issue. Yes, this behaviour is not changed by the patch. When TX_FAULT is true persistently for 5 retries, the module will still be disabled. > > So, if the module keeps indicating that its laser is misbehaving the > only right thing to do is to shut it down permanently, and have > someone investigate. > > What issue are you seeing that needs a different behaviour? > In my case two different SFP modules (1000Base-BX) indicate short TX_FAULT events for less than one second and only one per week - sometimes more, sometimes less. So the idea was to reset the counter if reinitialisation was successful, so rare single TX_FAULT events can be ignored. However, you are right: If a module reports TX_FAULT several times, something serious may be wrong.
Powered by blists - more mailing lists