Is it platform specific
generic
Importance or Severity
Medium
Description of the bug
Lately, a code for monitoring the performances of optical transceivers was added. (doc/platform_api/CMIS_Diagnostic_Monitoring_Overview_in_SONiC.md).
This monitoring is done only for CMIS optical transceivers.
And in other cases, we raise Not Implemented Error. e.g. in xcvc_api - https://github.com/sonic-net/sonic-platform-common/blob/master/sonic_platform_base/sonic_xcvr/api/xcvr_api.py#L309
There are cases where we won't use CMIS transceivers, but others like SFF.
When we are starting all services (reboot/reload), we get the following log error:
ERR pmon#SfpStateUpdateTask[30]: Failed to get VDM thresholds for port 66
ERR pmon#SfpStateUpdateTask[30]: Failed to get VDM thresholds for port 65
Looking at the code, as the transceivers connected in ports 65 and 66 are using Sff8472Api, which inherits from xcvr_api (link above) we shold expect to see this error - https://github.com/sonic-net/sonic-platform-daemons/blob/master/sonic-xcvrd/xcvrd/dom/utilities/vdm/utils.py#L41
The severity of the log needs to be changed, as this is expected in case it is not CMIS transceiver.
@mihirpat1 is aware and will update the code soon.
Steps to Reproduce
reboot/reload in a switch with non-CMIS transceivers, and the error will be printed in syslog.
Actual Behavior and Expected Behavior
I suggest to have different log severity or remove the error log, as this is expected.
Relevant log output
ERR pmon#SfpStateUpdateTask[30]: Failed to get VDM thresholds for port 66
ERR pmon#SfpStateUpdateTask[30]: Failed to get VDM thresholds for port 65
Output of show version, show techsupport
SONiC Software Version: SONiC.202412_RC.49-00e266852_Internal
SONiC OS Version: 12
Distribution: Debian 12.10
Kernel: 6.1.0-29-2-amd64
Build commit: 00e266852
Build date: Wed Apr 2 09:48:56 UTC 2025
Built by: sw-r2d2-bot@r-build-sonic-ci03-243
Platform: x86_64-nvidia_sn5640-r0
HwSKU: Mellanox-SN5640-C448O16
ASIC: mellanox
ASIC Count: 1
Serial Number: MT251160509J
Model Number: MSN5640
Hardware Revision: A4
Uptime: 09:05:57 up 2:26, 2 users, load average: 2.00, 2.18, 2.14
Date: Thu 03 Apr 2025 09:05:57
Docker images:
REPOSITORY TAG IMAGE ID SIZE
docker-orchagent 202412_RC.49-00e266852_Internal ad4e91285622 354MB
docker-orchagent latest ad4e91285622 354MB
docker-fpm-frr 202412_RC.49-00e266852_Internal 84bccd6478c0 376MB
docker-fpm-frr latest 84bccd6478c0 376MB
docker-nat 202412_RC.49-00e266852_Internal f78a077f7eab 344MB
docker-nat latest f78a077f7eab 344MB
docker-macsec latest 3d9def87f54f 344MB
docker-sflow 202412_RC.49-00e266852_Internal 9dd5c6b7b3d2 343MB
docker-sflow latest 9dd5c6b7b3d2 343MB
docker-teamd 202412_RC.49-00e266852_Internal 7835bea0af06 342MB
docker-teamd latest 7835bea0af06 342MB
docker-sonic-bmp 202412_RC.49-00e266852_Internal d76677baf0e1 313MB
docker-sonic-bmp latest d76677baf0e1 313MB
docker-dhcp-relay latest 268b3d487ec5 321MB
docker-platform-monitor 202412_RC.49-00e266852_Internal f1f2758168a3 433MB
docker-platform-monitor latest f1f2758168a3 433MB
docker-dhcp-server latest e1a9d5ebb482 335MB
docker-snmp 202412_RC.49-00e266852_Internal dad9475739e0 356MB
docker-snmp latest dad9475739e0 356MB
docker-syncd-mlnx 202412_RC.49-00e266852_Internal 683b9f6c90b8 799MB
docker-syncd-mlnx latest 683b9f6c90b8 799MB
docker-sonic-mgmt-framework 202412_RC.49-00e266852_Internal 11c83074049e 399MB
docker-sonic-mgmt-framework latest 11c83074049e 399MB
docker-router-advertiser 202412_RC.49-00e266852_Internal 17b2c5bab598 312MB
docker-router-advertiser latest 17b2c5bab598 312MB
docker-sonic-restapi 202412_RC.49-00e266852_Internal 3842cae25b26 331MB
docker-sonic-restapi latest 3842cae25b26 331MB
docker-mux 202412_RC.49-00e266852_Internal c79383418ea6 364MB
docker-mux latest c79383418ea6 364MB
docker-lldp 202412_RC.49-00e266852_Internal 4cd1006aaf61 358MB
docker-lldp latest 4cd1006aaf61 358MB
docker-eventd 202412_RC.49-00e266852_Internal 4aaf10242dd2 312MB
docker-eventd latest 4aaf10242dd2 312MB
docker-database 202412_RC.49-00e266852_Internal 229899d02b21 321MB
docker-database latest 229899d02b21 321MB
docker-sonic-gnmi 202412_RC.49-00e266852_Internal 8e807d6168ad 401MB
docker-sonic-gnmi latest 8e807d6168ad 401MB
urm.nvidia.com/sw-nbu-sws-sonic-docker/sonic-wjh 2.0.2-202412-005 d423802db8c4 430MB
Attach files (if any)
No response
Is it platform specific
generic
Importance or Severity
Medium
Description of the bug
Lately, a code for monitoring the performances of optical transceivers was added. (doc/platform_api/CMIS_Diagnostic_Monitoring_Overview_in_SONiC.md).
This monitoring is done only for CMIS optical transceivers.
And in other cases, we raise Not Implemented Error. e.g. in xcvc_api - https://github.com/sonic-net/sonic-platform-common/blob/master/sonic_platform_base/sonic_xcvr/api/xcvr_api.py#L309
There are cases where we won't use CMIS transceivers, but others like SFF.
When we are starting all services (reboot/reload), we get the following log error:
ERR pmon#SfpStateUpdateTask[30]: Failed to get VDM thresholds for port 66
ERR pmon#SfpStateUpdateTask[30]: Failed to get VDM thresholds for port 65
Looking at the code, as the transceivers connected in ports 65 and 66 are using Sff8472Api, which inherits from xcvr_api (link above) we shold expect to see this error - https://github.com/sonic-net/sonic-platform-daemons/blob/master/sonic-xcvrd/xcvrd/dom/utilities/vdm/utils.py#L41
The severity of the log needs to be changed, as this is expected in case it is not CMIS transceiver.
@mihirpat1 is aware and will update the code soon.
Steps to Reproduce
reboot/reload in a switch with non-CMIS transceivers, and the error will be printed in syslog.
Actual Behavior and Expected Behavior
I suggest to have different log severity or remove the error log, as this is expected.
Relevant log output
Output of
show version,show techsupportAttach files (if any)
No response