Why I did it
start pcie-check.service after config-setup.service since pcie_util depends on device_info which is available with config db metadata.
How I did it
Add config-setup.service as a dependency of pcie-check.service
How to verify it
Upon reboot, check if the pcie-check.sh throws the platform api error which is dependent on DEVICE_METADATA
Why I did it
Enable redistribution of static routes
How I did it
Enable redistribution of static routes when the first route is added to STATIC_ROUTE table of Config_DB and disable the redistribution when the last route is removed from STATIC_ROUTE table.
#### Why I did it
Add initial support of SN4800 platform for Mellanox ASIC simulation device.
NOTE: This is work in progress and not full support of the platform.
#### How I did it
Add new folders for SN4800 with zero ports based on SN4700 Spectrum-3 switch.
This PR updates the following commits in sonic-platform-daemons
e60804c [xcvrd] add support for logging mux_metrics events into state DB (#185)
807b304 [psud] Add PSU Hardware Revision to Redis STATE_DB (#179)
d0be634 [muxcable] Remove Xcvrd Sleep (#174)
cc3803f [thermalctld] Enable stopping thermal manager (#180)
665fcd9 [xcvrd] Fix crash for QSFP DD media (#181)
cdabd09 [xcvrd] Change the y_cable presence logic to use "mux_cable" table as identifier from Config DB (#176)
4be4306 [xcvrd] Enhance Media Settings (#177)
Signed-off-by: vaibhav-dahiya <vdahiya@microsoft.com>
Why I did it
Skip to use the web proxy when the packages have been in the proxy server.
For sai packages or the other packages, we will upload the the proxy server directly, the reproducible will skip to check the site, not necessary to change the version files.
[config]Static routes to config_db (#1534)
[DPB]: Shut down interface before dynamic port breakout (#1303)
[vlan] remove dhcp-relay as dhcp-relay commands will come as a plugin (#1378)
Add 'default' option for sFlow. (#1606)
[Command-Reference.md] Document new SNMP show and config commands (#1600)
Signed-off-by: Shlomi Bitton <shlomibi@nvidia.com>
1213d61 [thermal_manager_base] Add a stop function to thermal manager (#187)
a95834b [DeviceBase] Added hardware revision number to generic device properties (#184)
f4901a0 [voqinbandif]To support inband port as front panel port (#159)
#### Why I did it
Improve readability of `show environment` output.
#### How I did it
In all sensors.conf, give the customized labels according to HW specifications for each model.
Signed-off-by: Sean Wu <sean_wu@edge-core.com>
- Why I did it
Add initial support of SN4800 platform .
NOTE: This is work in progress and not full support of the platform.
- How I did it
Add new folders for SN4800 with zero ports based on SN4700 Spectrum-3 switch.
- How to verify it
Simulator device was tested. See #7448
Add support for Accton as9726-32d platform
This pull request is based on as9716-32d, so I reference as9716-32d to create new model: as9726-32d.
This module do not need led driver to control led, FPGA can handle it.
I also implement API2.0(sonic_platform) for this model, CPLD driver, PSU driver, Fan driver to control these HW behavior.
#### Why I did it
Fix https://github.com/Azure/sonic-telemetry/issues/71
#### How I did it
Added memory limit for telemetry docker.
Historical docker memory usage shows telemetry docker consuming 150-200MB memory. Adding some extra buffer.
Why I did it
Fix issues below.
#7133#6602
So, remove the dps200 driver from the platform-specific driver.
Then, add the dps200 module driver to the Linux kernel tree.
How I did it
Remove the dps200 driver from the platform-specific driver and add the dps200 module driver to the Linux kernel.
How to verify it
Build an image with Azure/sonic-linux-kernel#207
Then, install to the Haliburton.
To include PortChannel as Vlan Member (in addition to the already existing physical port)
Signed-off-by: Arthi Sivanantham <arthi_sivanantham@dell.com>
Why I did it
Finding running containers through "docker ps" breaks when kubernetes deploys container, as the names are mangled.
How I did it
The data is is available from FEATURE table, which takes care of kubernetes deployment too.
How to verify it
Deploy a feature via kubernetes and don't expect error from container_check.
LED_PROC_INIT_SOC variable was incorrectly referenced as LED_SOC_INIT_SOC. Introduced in #5483
Rather than fixing the typo, I decided to simplify the script, removing the need for the conditional altogether by moving the bcmcmd call inside the conditional which checks for the presence of LED_SOC_INIT_SOC.
Includes below commits
9a88cb6 2021-05-06 | [sonic_installer] dont fail package migration (#1591) [Stepan Blyshchak]
615e531 2021-05-05 | [show][config] Add new snmp commands (#1347) [Travis Van Duyn]
fff4051 2021-05-05 | Fixing serial number read to get from DB if it is populated (#1580) [Sudharsan Dhamal Gopalarathnam]
be974bf 2021-05-05 | [neighbor_advertiser] Use existing tunnel if present for creating tunnel mappings (#1589) [Sumukha Tumkur Vani]
9492eab 2021-05-04 | Use swsscommon instead of swsssdk (#1510) [Andriy Yurkiv]
0f4988b 2021-05-04 | Add pg-drop script to sonic filesystem (#1583) [Andriy Yurkiv]
cbe2159 2021-05-04 | [vnet] Add "vnet_route_check" script (#1300) [Volodymyr Samotiy]
9120766 2021-05-03 | Relax the install_requires, no need to exact version as long as there are no broken changes with future versions (#1530) [Qi Luo]
2e09b22 2021-05-03 | Handle the new db version which mellanox_buffer_migrator isn't interested (#1566) [Stephen Sun]
fuser support is required since new cisco hardware watchdog plugin uses them to check anyone else use's /dev/watchdogX resource. The actual validation happens in the platform code, but the package is required for pmon container. Currently the /dev/watchdogX is being used by cisco platform-monitor service. Cisco chassis level watchdog plugin uses "fuser" to claim the watchdog release from platform-monitor service.
Fix following crash in `show version`:
```
Traceback (most recent call last):
File "/usr/local/bin/decode-syseeprom", line 32, in instantiate_eeprom_object
eeprom = sonic_platform.platform.Platform().get_chassis().get_eeprom()
AttributeError: module 'sonic_platform' has no attribute 'platform'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/bin/decode-syseeprom", line 262, in <module>
sys.exit(main())
File "/usr/local/bin/decode-syseeprom", line 244, in main
print_serial(use_db)
File "/usr/local/bin/decode-syseeprom", line 169, in print_serial
eeprom = instantiate_eeprom_object()
File "/usr/local/bin/decode-syseeprom", line 34, in instantiate_eeprom_object
log.log_error('Failed to obtain EEPROM object due to {}'.format(repr(e)))
NameError: name 'log' is not defined
```
Signed-off-by: pettershao-ragilenetworks <pettershao@ragilenetworks.com>
9a88cb6 [sonic_installer] dont fail package migration (#1591)
615e531 [show][config] Add new snmp commands (#1347)
fff4051 Fixing serial number read to get from DB if it is populated (#1580)
be974bf [neighbor_advertiser] Use existing tunnel if present for creating tunnel mappings (#1589)
9492eab Use swsscommon instead of swsssdk (#1510)
0f4988b Add pg-drop script to sonic filesystem (#1583)
cbe2159 [vnet] Add "vnet_route_check" script (#1300)
9120766 Relax the install_requires, no need to exact version as long as there are no broken changes with future versions (#1530)
2e09b22 Handle the new db version which mellanox_buffer_migrator isn't interested (#1566)
Platform library changes
- Fix the use of /proc/modules during testing, fixes#7463
- Add `libsfp-eeprom.so` build to read/write xcvr eeproms in C
- Add some more reboot-cause information
- Write down temperature hw thresholds to the sensors
- Report software thresholds through platform api
- Writ `port_name sysfs` file of optoe`
- Tests enhancements
- Fix dependency issues for chassis provisioning
Platform configuration changes
- Add `pcie.yaml` configuration for a few platforms
- Mount `libsfp-eeprom.so` inside `pmon`
- Fix `Arista-7050SX3-48C8` and `Arista-7050SX3-48YC8' platform and hwsku
- Miscellaneous fixes
Co-authored-by: Boyang Yu <byu@arista.com>
Co-authored-by: Zhi Yuan Carl Zhao <zyzhao@arista.com>
https://github.com/mbj4668/pyang/blob/master/pyang/repository.py#L93 throws an exception with pip 21.1
add ietf yang model explicitly to the build process fix the test failure.
tests/test_sonic_yang_models.py .F [ 66%]
tests/yang_model_tests/test_yang_model.py . [100%]
Failed: pyang -f tree ./yang-models/*.yang > ./yang-models/sonic_yang_tree
----------------------------- Captured stderr call -----------------------------
./yang-models/sonic-acl.yang:8: error: module "ietf-inet-types" not found in search path
./yang-models/sonic-device_metadata.yang:8: error: module "ietf-yang-types" not found in search path
Signed-off-by: Guohan Lu <lguohan@gmail.com>
Originally, SFP modules were always accessed from platform daemons, and arbitrary SFP modules can be accessed in the daemon. So all SFP modules were initialized in one shot once one of the following chassis APIs called
- get_all_sfps
- get_sfp_numbers
- get_sfp
Recently, we noticed that SFP modules can also be accessed from CLI, eg. the latest refactor of `sfputil`.
In this case, only one SFP module is accessed in the chassis object's life cycle.
To initialize all SFP modules in one shot is waste of time and causes the CLI to take much more time to finish.
So we would like to optimize the initialization flow by introducing a two-phase initialization approach:
- Partial initialization, which means the `chassis._sfp_list` has been initialized with proper length and all elements being `None`
- Full initialization, which means all elements in `chassis._sfp_list` are created
If the relevant function is called,
- `get_sfp`, only partial initialization will be done, and then the specific SFP module is initialized.
- `get_all_sfps` or `get_num_sfps`, full initialization will be done, which means all SFP modules are initialized.
Signed-off-by: Stephen Sun <stephens@nvidia.com>
#### Why I did it
MSN4700 A1/A0 used different sensor chip but keep the existing platform name *x86_64-mlnx_msn4700-r0*, this is a workaround to replace the sensor conf on MSN4700 A1/A0
#### How I did it
Use a shell script to get the sensor conf path and copy that files to /etc/sensors.d/sensors.conf
#### Why I did it
400G media EEPROM and DOM information are not populated properly in DellEMC Z9332f platform.
#### How I did it
Handled QSFP_DD, QSFP28/QSFP+, SFP+ accordingly based on media type detected.
- Why I did it
Updated FW to xx.2008.2526 version.
Fixed issues:
1. Spectrum-2, Spectrum-3 | sFlow | High CPU load and high on fully loaded switch.
2. Spectrum-2, Spectrum-3 | Fine grain LAG | in rare cases doesn’t update the right entry
- How I did it
Updated submodule pointer and version in a Makefile.
- How to verify it
Full regression and bugs validation
Signed-off-by: Shlomi Bitton <shlomibi@nvidia.com>
