- Why I did it
The thermalctld daemon on the Pmon docker requires support from the thermal manager API
- How I did it
Cherry picked from : cfda77b
Removed the old function for detecting a faulty fan.
Removed the old function for detecting excess temperature.
Implement thermal_manager APIs based on ThermalManagerBase
Implement thermal_conditions APIs based on ThermalPolicyConditionBase
Implement thermal_actions APIs based on ThermalPolicyActionBase
Implement thermal_info APIs based on ThermalPolicyInfoBase
Add thermal_policy.json
- How to verify it
Check the fan speed during temperature changes.
Examine events that will occur after the temperature has exceeded the threshold.
Check for events that will occur after the fan is removed or the fan is not working properly.
- Which release branch to backport (provide reason below if selected)
202012
It can be that service is not enabled but UnitFilePreset=enabled (case
for Application Extension):
```
Loaded: loaded (/lib/systemd/system/cpu-report.service; disabled; vendor preset: enabled)
```
This makes existing logic skip enabling the service.
Signed-off-by: Stepan Blyschak <stepanb@nvidia.com>
- Why I did it
to prevent python exception error when executing warm-reboot command on mellanox simulator platform
- How I did it
return None on the watchdog python script on cases that watchdog file is not exist
- How to verify it
warm-reboot is running well without the python error. error message will appear on log on these cases.
in order to avoid this error message we can simulate the watchdog on mellanox simulator platform
- Removed the old function for detecting a faulty fan.
- Removed the old function for detecting excess temperature.
- Implement thermal_manager APIs based on ThermalManagerBase
- Implement thermal_conditions APIs based on ThermalPolicyConditionBase
- Implement thermal_actions APIs based on ThermalPolicyActionBase
- Implement thermal_info APIs based on ThermalPolicyInfoBase
- Add thermal_policy.json
Backport #7944
#### Why I did it
The current logic generates 'VLAN_SUB_INTERFACE' table if the device type is backend and cluster name contains 'str'. This is not a reliable method to determine a storage backend device
#### How I did it
Updated the logic to generate 'VLAN_SUB_INTERFACE' table if any of the following conditions hold true
1. device is of type backend and ResourceType attribute is None
2. device is of type backend and ResourceType attribute contains "Storage"
3. device is of type backend and graph contains "Subinterface" section
Also updated the logic to set "is_storage_device" to True
1. for Backend, if any of the above conditions hold true
2. for Frontend, if ResourceType attribute contains "Storage"
#### How to verify it
Added new tests to verify the code changes and built sonic_config_engine-1.0-py3-none-any.whl successfully
Why I did it
Allows users to host their own local docker registries and utilize them via the REGISTRY_SERVER and REGISTRY_PORT environmental variables
How I did it
Only set REGISTRY_SERVER and REGISTRY_PORT in rules/config if they are unset.
How to verify it
Export environmental variables REGISTRY_SERVER and REGISTRY_PORT to an alternative docker registry. Export the environmental variable ENABLE_DOCKER_BASE_PULL to y.
Ensure the required sonic-slave docker images are not present locally, but are available in the docker registry
Execute make init and make configure
Confirm that the appropriate docker images were pulled from the appropriate docker registry, and not built locally
Update:
> 2ca493b 2021-07-13 create sniffer folder if not exist (Azure/sonic-utilities#1659)
> 1695104 2021-07-07 [show priority-group drop counters] Remove backup with cached PG drop counters after 'config reload' (Azure/sonic-utilities#1679)
> e99a3c5 2021-07-07 [show][config] support for interface alias for muxcable commands (Azure/sonic-utilities#1699)
Why I did it
To determine the revision of the pcie.yaml to be used based on BIOS version in DellEMC S6100 platform.
Depends on: Azure/sonic-platform-common#195
How I did it
Added two revisions of pcie.yaml pcie_1.yaml and pcie_2.yaml
Included a platform-specific Pcie class to provide the revision of the pcie.yaml to be used by pcieutil/pcied.
How to verify it
Execute pcieutil check (Azure/sonic-utilities#1672) command and verify the list of PCIe devices displayed.
Logs: UT_logs.txt
Use udevadm to trigger the udev rules on the first boot
How to verify:
- Connect C0 with E1031;
- Install or upgrade the sonic os to 202012 branch;
- When access to sonic check if /dev/C0-1 to /dev/C0-48 are existed.
Currently hostcfgd is implemented in a way each feature which is enabled/disabled triggering execution of systemctl enable/unmask commands which eventually trigger 'systemctl daemon-reload' command.
Each call like this cost 0.6s and overall add a overhead of ~12 seconds of CPU time.
This change will verify the desired state of a feature and the current state of this feature on systemd and trigger a system call only when must.
What is changed: Check each feature status on systemd before executing a system call to enable and reload the systemctl daemon.
How to verify: Build an image with this change and observe less system calls are executed.
#### Why I did it
Following the discussion in another PR https://github.com/Azure/sonic-buildimage/pull/7708#discussion_r642933510 , since there will be multi subfolders under **/var/log/mellanox**, so we agreed to only mount this folder and the subfolders will be created afterward on demand.
#### How I did it
during the syncd docker creation, only mount folder **/var/log/mellanox**
#### How to verify it
build an Mellanox image and verify the related folder on the host and docker side.
Why I did it
Static route configuration should not depend on BGP_ASN. Remove the dependency on BGP_ASN for StaticRouteMgr.
Fix#8027
How I did it
Check if BGP_ASN field before configuring static route redistribution and wait until BGP_ASN is available to enable static route redistribution.
How to verify it
Add unit test to cover the scenario and verify the functionality on a virtual switch.
Update FW version to 2008.3218, fixing the following issues:
- 50G/100G links that are operationally down before warm-reboot are not coming up after warm-reboot
- 50G/100G links with admin shut / no shut commands are not coming up after warm-reboot
Signed-off-by: Dror Prital <drorp@nvidia.com>
dash doesn't support += operation to append to a variable's value. Use KDUMP_CMDLINE_APPEND="${KDUMP_CMDLINE_APPEND} " instead
The below error message is seen when a reboot is issued.
[ 342.439096] kdump-tools[13655]: /etc/init.d/kdump-tools: 117: /etc/default/kdump-tools: KDUMP_CMDLINE_APPEND+= panic=10 debug hpet=disable pcie_port=compat pci=nommconf sonic_platform=x86_64-accton_as7326_56x-r0: not found
#### Why I did it
ethtool can be used to query and change settings such as speed, auto- negotiation and checksum offload on many network devices, especially Ethernet devices.
#### How I did it
add package extension to docker-platform-monitor/Dockerfile.j2
#### Why I did it
The libpci library provides portable access to configuration registers of devices connected to the PCI bus.
#### How I did it
update dockers/docker-platform-monitor/Dockerfile.j2
- Changes and new features:
1. Added support in SN4600C systems for new module Finisar ET7402-CWDM4 (100G CWDM4 QSFP28 1310nm SM 2KM).
2. Added support for new module MMS1W50-HM (2km transceiver FR4) for 200GbE
3. Improved performance of "per-port-buffer" counters
4. Added support for Kernel 5.10
- Bug fix:
On rare occasions (0.5%), in SN4600C systems, when using 100GbE NRZ mode and Fastboot flow, the link up time may take up to 10 seconds
Signed-off-by: Dror Prital <drorp@nvidia.com>
