port_config.ini for HWSKU Arista-7050CX3-32S-C32 has missing speed column and duplicated lanes.
The incorrect speed causes issues in Orchagent RESTARTCHECK as the below task remains as the remaining item during swss shutdown.
BRCM SDK 6.5.21 includes firmware updates (premier cancun) for TD3 platforms. The firmware update is required on TD3 platforms, which is packaged with BCMSAI 4.3.0.10.
**- How I did it**
Updated BCM config with a new variable that specifies the firmware package path. SDK uses this path to locate firmware packages and load during cold boot.
**- How to verify it**
bsv
BRCM SAI ver: [4.3.0.10], OCP SAI ver: [1.7.1], SDK ver: [sdk-6.5.21] CANCUN ver: [5.3.3]
drivshell>
admin@str2-7050cx3-acs-02:~$ bcmsh
Press Enter to show prompt.
Press Ctrl+C to exit.
NOTICE: Only one bcmsh or bcmcmd can connect to the shell at same time.
drivshell>cancun stat
cancun stat
UNIT0 CANCUN:
CIH: LOADED
Ver: 06.06.01
CMH: LOADED
Ver: 06.06.01
SDK Ver: 06.05.21
CCH: LOADED
Ver: 06.06.01
SDK Ver: 06.05.21
CEH: LOADED
Ver: 06.06.01
SDK Ver: 06.05.21
drivshell>
- Why I did it
platform.json and hwsku.json files are required for a feature called Dynamic Port Breakout
- How I did it
Created capability files according to platform specification SN4600C
- How to verify it
Full qualification requires bugs fixes reported under sonic-buildimage
NOTE: breakout to 4 is currently not available as of missing functionality in DPB implementation.
Signed-off-by: Vadym Hlushko <vadymh@nvidia.com>
- Why I did it
platform.json and hwsku.json files are required for a feature called Dynamic Port Breakout
- How I did it
Created capability files according to platform specification SN4410
- How to verify it
Full qualification requires bugs fixes reported under sonic-buildimage
Signed-off-by: Vadym Hlushko <vadymh@nvidia.com>
- Why I did it
platform.json and hwsku.json files are required for a feature called Dynamic Port Breakout
- How I did it
Created capability files according to platform specification SN3700
- How to verify it
Full qualification requires bugs fixes reported under sonic-buildimage
Signed-off-by: Vadym Hlushko <vadymh@nvidia.com>
- Why I did it
platform.json and hwsku.json files are required for a feature called Dynamic Port Breakout
- How I did it
Created capability files according to platform specification SN2410
- How to verify it
Full qualification requires bugs fixes reported under sonic-buildimage
NOTE: breakout to 4 is currently not available as of missing functionality in DPB implementation.
Signed-off-by: Vadym Hlushko <vadymh@nvidia.com>
- Why I did it
platform.json and hwsku.json files are required for a feature called Dynamic Port Breakout
- How I did it
Created capability files according to platform specification SN2100
- How to verify it
Full qualification requires bugs fixes reported under sonic-buildimage
Signed-off-by: Vadym Hlushko <vadymh@nvidia.com>
- Why I did it
platform.json and hwsku.json files are required for a feature called Dynamic Port Breakout
- How I did it
Created capability files according to platform specification SN2010
- How to verify it
Full qualification requires bugs fixes reported under sonic-buildimage
Signed-off-by: Vadym Hlushko <vadymh@nvidia.com>
- Why I did it
platform.json and hwsku.json files are required for a feature called Dynamic Port Breakout
- How I did it
Created capability files according to platform specification SN3800
- How to verify it
Full qualification requires bugs fixes reported under sonic-buildimage
Signed-off-by: Vadym Hlushko <vadymh@nvidia.com>
[DPB] added capability files for SN2700 platform
- Why I did it
platform.json and hwsku.json files are required for a feature called Dynamic Port Breakout
- How I did it
Created capability files according to platform specification SN2700
- How to verify it
Full qualification requires bugs fixes reported under sonic-buildimage
NOTE: breakout to 4 is currently not available as of missing functionality in DPB implementation.
Signed-off-by: Vadym Hlushko <vadymh@nvidia.com>
**- Why I did it**
- The thermalctld daemon on the Pmon docker requires support from the thermal manager API.
**- How I did it**
- 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
In order to build up device hierachy, PSU and module thermals are no longer child of chassis. PSU thermal belongs to PSU objects and SFP thermals belong to SFP object now. Need align this change in platform.json. Move thermal objects to correct parent device
fix platform driver breakage due to python3 upgrade and fix load minigraph errors with config load_minigraph -y
**- How I did it**
added python3-smbus to the pmon docker template since the previous was python2 specific
fixed additional "ord" python2 specific code
fixed the jinja templates used by qos reload - the template logic required data to be parsed
**- How to verify it**
run "show platform XXX" commands and verify output
run "sudo config load_minigraph -y" and verify configuration
run "show interfaces XXX" and verify output
Co-authored-by: Carl Keene <keene@nokia.com>
Y* profile is the name pattern for p4 programs that developed for the current platform. The difference between them is features enabled and resource reservation.
For this platform, it is expected to work on any Y profile. but after the latest changes, the first Y profile is always used.
Prevent system-healthd from service from failing at boot time due to missing configuration.
Also adds basic support for healthd.
The following caveat exists with this placeholder configuration:
- No PSU monitoring (sensors/fans)
- No ASIC temperature monitoring
- Why I did it
The sai.profile file in kvm images overrides the warmboot file with path /var/cache/sai_warmboot.bin. Since the directory /var/cache is not mounted in syncd, it will be cleared in an image upgrade, the warm-reboot image upgrade will fail if the file is put in the directory.
Fix#6183
- How I did it
Remove the path that overrides the default path. The warmboot file path will then be the default value /var/warmboot/sai-warmboot.bin. Since /var/warmboot/ is mounted by /host/warmboot/ in the host, it could survive an image upgrade.
- How to verify it
Tested warm reboot upgrading kvm image locally.
**- Why I did it**
To support dynamic buffer calculation.
This PR also depends on the following PRs for sub modules
- [sonic-swss: [buffermgr/bufferorch] Support dynamic buffer calculation #1338](https://github.com/Azure/sonic-swss/pull/1338)
- [sonic-swss-common: Dynamic buffer calculation #361](https://github.com/Azure/sonic-swss-common/pull/361)
- [sonic-utilities: Support dynamic buffer calculation #973](https://github.com/Azure/sonic-utilities/pull/973)
**- How I did it**
1. Introduce field `buffer_model` in `DEVICE_METADATA|localhost` to represent which buffer model is running in the system currently:
- `dynamic` for the dynamic buffer calculation model
- `traditional` for the traditional model in which the `pg_profile_lookup.ini` is used
2. Add the tables required for the feature:
- ASIC_TABLE in platform/\<vendor\>/asic_table.j2
- PERIPHERAL_TABLE in platform/\<vendor\>/peripheral_table.j2
- PORT_PERIPHERAL_TABLE on a per-platform basis in device/\<vendor\>/\<platform\>/port_peripheral_config.j2 for each platform with gearbox installed.
- DEFAULT_LOSSLESS_BUFFER_PARAMETER and LOSSLESS_TRAFFIC_PATTERN in files/build_templates/buffers_config.j2
- Add lossless PGs (3-4) for each port in files/build_templates/buffers_config.j2
3. Copy the newly introduced j2 files into the image and rendering them when the system starts
4. Update the CLI options for buffermgrd so that it can start with dynamic mode
5. Fetches the ASIC vendor name in orchagent:
- fetch the vendor name when creates the docker and pass it as a docker environment variable
- `buffermgrd` can use this passed-in variable
6. Clear buffer related tables from STATE_DB when swss docker starts
7. Update the src/sonic-config-engine/tests/sample_output/buffers-dell6100.json according to the buffer_config.j2
8. Remove buffer pool sizes for ingress pools and egress_lossy_pool
Update the buffer settings for dynamic buffer calculation
python2 is end of life and SONiC is going to support python3. This PR is going to support:
1. Mellanox SONiC platform API python3 support
2. Install both python2 and python3 verson of Mellanox SONiC platform API or pmon and host side
platform.json is needed for sonic-mgmt testing. Also in the future it will be used as part of dynamic port breakout.
Also removed the folder symlink for BlackhawkDD because it has a different platform.json than BlackhawkO.
Co-authored-by: Zhi Yuan Carl Zhao <zyzhao@arista.com>
Fixes#6126.
There is a bug in getting the path of voltage, current and power. The
list object is directly converted to string to format the file path. As
a result, read_txt_file will get None value and a WARNING will be
recorded. This commit fix the issue.
Signed-off-by: bingwang <bingwang@microsoft.com>
Current support for the 7060PX4-32 and 7060DX4 was broken.
With this change, ports are now linking fine.
Co-authored-by: Zhi Yuan Carl Zhao <zyzhao@arista.com>
Rename chip name dps1900-i2c-X-58 to pmbus-i2c-X-58 in sensors.conf for Arista 7170 due to latest updates for Arista driver submodules #5686. After these updates adapter dps1900 was renamed and sensors.conf file is not applied properly. Issue was observed started from BFN SONiC image 16.
Signed-off-by: Nazar Tkachuk <nazarx.tkachuk@intel.com>
Submodule updates include the following commits:
* src/sonic-utilities 9dc58ea...f9eb739 (18):
> Remove unnecessary calls to str.encode() now that the package is Python 3; Fix deprecation warning (#1260)
> [generate_dump] Ignoring file/directory not found Errors (#1201)
> Fixed porstat rate and util issues (#1140)
> fix error: interface counters is mismatch after warm-reboot (#1099)
> Remove unnecessary calls to str.decode() now that the package is Python 3 (#1255)
> [acl-loader] Make list sorting compliant with Python 3 (#1257)
> Replace hard-coded fast-reboot with variable. And some typo corrections (#1254)
> [configlet][portconfig] Remove calls to dict.has_key() which is not available in Python 3 (#1247)
> Remove unnecessary conversions to list() and calls to dict.keys() (#1243)
> Clean up LGTM alerts (#1239)
> Add 'requests' as install dependency in setup.py (#1240)
> Convert to Python 3 (#1128)
> Fix mock SonicV2Connector in python3: use decode_responses mode so caller code will be the same as python2 (#1238)
> [tests] Do not trim from PATH if we did not append to it; Clean up/fix shebangs in scripts (#1233)
> Updates to bgp config and show commands with BGP_INTERNAL_NEIGHBOR table (#1224)
> [cli]: NAT show commands newline issue after migrated to Python3 (#1204)
> [doc]: Update Command-Reference.md (#1231)
> Added 'import sys' in feature.py file (#1232)
* src/sonic-py-swsssdk 9d9f0c6...1664be9 (2):
> Fix: no need to decode() after redis client scan, so it will work for both python2 and python3 (#96)
> FieldValueMap `contains`(`in`) will also work when migrated to libswsscommon(C++ with SWIG wrapper) (#94)
- Also fix Python 3-related issues:
- Use integer (floor) division in config_samples.py (sonic-config-engine)
- Replace print statement with print function in eeprom.py plugin for x86_64-kvm_x86_64-r0 platform
- Update all platform plugins to be compatible with both Python 2 and Python 3
- Remove shebangs from plugins files which are not intended to be executable
- Replace tabs with spaces in Python plugin files and fix alignment, because Python 3 is more strict
- Remove trailing whitespace from plugins files
Fix 259 alerts reported by the LGTM tool:
- 245 for Unused import
- 7 for Testing equality to None
- 5 for Duplicate key in dict literal
- 1 for Module is imported more than once
- 1 for Unused local variable
**- Why I did it**
We were building a custom version of Supervisor because I had added patches to prevent hangs and crashes if the system clock ever rolled backward. Those changes were merged into the upstream Supervisor repo as of version 3.4.0 (http://supervisord.org/changes.html#id9), therefore, we should be able to simply install the vanilla package via pip. This will also allow us to easily move to Python 3, as Python 3 support was added in version 4.0.0.
**- How I did it**
- Remove Makefiles and patches for building supervisor package from source
- Install Python 3 supervisor package version 4.2.1 in Buster base container
- Also install Python 3 version of supervisord-dependent-startup in Buster base container
- Debian package installed binary in `/usr/bin/`, but pip package installs in `/usr/local/bin/`, so rather than update all absolute paths, I changed all references to simply call `supervisord` and let the system PATH find the executable to prevent future need for changes just in case we ever need to switch back to build a Debian package, then we won't need to modify these again.
- Install Python 2 supervisor package >= 3.4.0 in Stretch and Jessie base containers
Need A mmu configuration to get the device going without generating lots of warnings.
Similar to dummy MMU configuration for Arista-7050CX3-32S-C32, this configuration will need to be updated with correct numbers. This MMU configuration is copied from 7060 comparable hwsku.
Signed-off-by: Ying Xie <ying.xie@microsoft.com>
This change introduces PDDF which is described here: https://github.com/Azure/SONiC/pull/536
Most of the platform bring up effort goes in developing the platform device drivers, SONiC platform APIs and validating them. Typically each platform vendor writes their own drivers and platform APIs which is very tailor made to that platform. This involves writing code, building, installing it on the target platform devices and testing. Many of the details of the platform are hard coded into these drivers, from the HW spec. They go through this cycle repetitively till everything works fine, and is validated before upstreaming the code.
PDDF aims to make this platform driver and platform APIs development process much simpler by providing a data driven development framework. This is enabled by:
JSON descriptor files for platform data
Generic data-driven drivers for various devices
Generic SONiC platform APIs
Vendor specific extensions for customisation and extensibility
Signed-off-by: Fuzail Khan <fuzail.khan@broadcom.com>
* [Juniper] Platform bug fixes / improvements
This patch set introduces the following changes for
the two platforms.
- QFX5210
- Fixes a driver bug related to reboot notifier
- Disable pcied
- Introduces a wrapper script for fast / warm reboots
for unloading the driver containing reboot handler
- Support for PSM4 optics in media_settings
- QFX5200
- BCM configuration file updates
- Bug fixes for EM policy
- Fixes a driver bug related to reboot notifier
- Introduces a wrapper script for fast / warm reboots
for unloading the driver containing reboot handler
- Disable pcied
- Support for PSM4 optics
Signed-off-by: Ciju Rajan K <crajank@juniper.net>
Treat devices that are ToRRouters (ToRRouters and BackEndToRRouters) the same when rendering templates
Except for BackEndToRRouters belonging to a storage cluster, since these devices have extra sub-interfaces created
Treat devices that are LeafRouters (LeafRouters and BackEndLeafRouters) the same when rendering templates
Signed-off-by: Lawrence Lee <lawlee@microsoft.com>
- Why I did it
On Arista-7050CX3-32S-C32, there are constant stream of errors like following.
Nov 3 21:56:24.415190 str2-7050cx3-acs-06 NOTICE swss#orchagent: :- registerInWdDb: No lossless TC found on port Ethernet68
Which causes:
loganalyzer to claim test failed.
leaving the system without MMU configuration. Which couldn't be good for any IO test.
- How I did it
Added these MMU configuraions are copied from another platform and guaranteed to be incorrect for hwsku Arista-7050CX3-32S-C32.
Adding them so that we have A MMU configuration and the system won't throw a whole bunch of errors and leave MMU unconfigured. The correct MMU configuration will come later.
This configuration is definitely not suitable for testing system performance or QoS behavior.
Signed-off-by: Ying Xie ying.xie@microsoft.com
- How to verify it
Test will have chance to pass. Ran a few test that would fail otherwise.
