Support Tunnel PFC/pcbb feature on Broadcom platform.
How to verify it
Tested build target, successful
make target/docker-syncd-brcm.gz
manual run those tests after installing sai binary within image 20201231.67 on 7050CX3 (TD3) T0 DUT, all passed
fib/test_fib.py
vxlan/test_vxlan_decap.py
fdb/test_fdb.py
decap/test_decap.py
pfcwd/test_pfcwd_all_port_storm.py
acl/null_route/test_null_route_helper.py
acl/test_acl.py
vlan/test_vlan.py
platform_tests/test_reboot.py
Signed-off-by: richardyu-ms <richard.yu@microsoft.com>
Why I did it
To remove the ipmihelper.py in S5248f directory to prevent the image label being marked 'dirty', due to the file being replaced by the ipmihelper.py in common folder during build.
How I did it
Remove ipmihelper.py in S5248f directory.
How to verify it
Build a broadcom image and verify that the tracked files are not modified.
Which release branch to backport (provide reason below if selected)
201811
201911
202006
202012
202106
202111
Description for the changelog
DellEMC S5248f : Remove duplicate ipmihelper.py
Link to config_db schema for YANG module changes
A picture of a cute animal (not mandatory but encouraged)
Why I did it
To fix issue #10152 for dx010.
202012 Warm upgrade causes lacp-teardown on Dx010 TOR. platform code initialize slow causing lacp timeout.
How I did it
Remove the python2 sonic platform wheel which is deprecated.
Optimize the dx010 sonic platform script to speed up the init process.
How to verify it
Check the warm reboot log, warm reboot is 8-9s faster than before.
Signed-off-by: Eric Zhu <erzhu@celestica.com>
Why I did it
To reduce the processing time of rc.local, refactoring s6100 platform initialization.
Fixing [warm-upgrade][202012] Slow DELL platform init in rc.local causes lacp-teardown #10150
How I did it
On branch 202012-s6100-rclocalChanges to be committed: (use "git restore --staged <file>..." to unstage)
modified: ../../../../files/image_config/platform/rc.local
modified: ../debian/platform-modules-s6100.install
modified: scripts/fast-reboot_plugin
modified: scripts/s6100_platform.sh
renamed: scripts/s6100_i2c_enumeration.sh -> scripts/s6100_platform_startup.sh
renamed: systemd/s6100-i2c-enumerate.service -> systemd/s6100-platform-startup.service
Support saiserver v2 with python3 and thrift 0.13.0 (Cherry-picked from master #9509)
add variables to support the saiserverv2
build different thrift in saithrift depends on saiserver version
build differernt versions of saiserver
make the saiserver and saiserver docker with version number
test done:
build two different versions of sasiserver in local build environment
Co-authored-by: Richard.Yu <richard.yu@microsoft.com>
Fixes#10020
Why I did it
The platform api for parsing syseeprom information read from STATE DB has issue
with parsing the value part that has whitespace in the middle. The current
code assumes that the value part does not have whitespace. So everything after
the whitespace will be ignored. The syseeprom values returned from platform
API do not match the output of "show platform syseeprom".
How I did it
This change improved the regular expression for parsing syseeprom values to
accommodate whitespaces in the value.
How to verify it
Locally updated the code on a dx010 device. Call the platform API:
```
>>> import sonic_platform
>>> platform = sonic_platform.platform.Platform()
>>> chassis = platform.get_chassis()
>>> chassis.get_system_eeprom_info()
{'0x21': 'DX010', '0x22': 'R0872-F0020-02', '0x23': 'DX010B2F030A27BY200002', '0x24': '00:E0:EC:E7:71:0F', '0x25': '11/03/2020 21:22:56', '0x26': '3', '0x27': 'Seastone', '0x28': 'RANGELEY', '0x29': '2014.08', '0x2A': '131', '0x2B': 'CELESTICA', '0x2C': 'THA', '0x2D': 'Celestica', '0x2E': '1.0.5', '0x2F': 'LB', '0xFD': '', '0xFE': '0xAAB39BDB'}
```
Signed-off-by: Xin Wang <xiwang5@microsoft.com>
Generate the sai.profile base on the brcm j2 file if the sai.profile
is not existing in the dut mounted folder.
Change the supervisor service configuration accordingly.
Testing done:
Add the script and config in dut
saiservice server can start automatically with [systemctl start saiserver]
Signed-off-by: richardyu-ms <richard.yu@microsoft.com>
Why I did it
Arista did not update db with eeprom info. Previous PR had issues that were reverted.
How I did it
Had Arista eeprom class inherit the class that has method to update db. Updated platform API methods for Arista 202012.
How to verify it
In redis-cli the keys and values can be seen. Can use sonic-mgmt testing to verify behavior, and see the chassis platform API methods have not regressed.
1. CS00012211718 [4.3] Pfcwd getting continuously triggered/restored when pause frames are sent continuously to both queues of a port (TD2/Th/Th2/TD3) MSFT Default
Preliminary tests look fine. BGP neighbors were all up with proper routes programmed
interfaces are all up
Manually ran the following test cases on 7050CX3 (TD3) T0 DUT and all passed:
```
fib/test_fib.py
vxlan/test_vxlan_decap.py
fdb/test_fdb.py
decap/test_decap.py
ipfwd/test_dip_sip.py
ipfwd/test_dir_bcast.py
acl/test_acl.py
vlan/test_vlan.py
platform_tests/test_reboot.py
```
This is to pick up BRCM SAI 4.3.5.1-7 fixes which contains the following fixes:
1. CS00012209390: SONIC-50037, Used SAI_SWITCH_ATTR_QOS_DSCP_TO_TC_MAP as a default decap map for IPinIP tunnels.
2. CS00012212995: SONIC-50948 SAI_API_QUEUE:_brcm_sai_cosq_stat_get:1353 egress Min limit get failed with error Invalid parameter
3. SONIC-51583: Fixed acl group member creation failure with priority of -1
4. CS00012215744:SONIC-51395 [TH, TH2] WB 3.5 to 4.3 fails at APPLY_VIEW while setting SAI_PORT_ATTR_EGRESS_ACL
5. SONIC-51638: SDK-249337 ERROR: AddressSanitizer: heap-buffer-overflow in _tlv_print_array
Preliminary tests look fine. BGP neighbors were all up with proper routes programmed
interfaces are all up
Manually ran the following test cases on 7050CX3 (TD3) T0 DUT and all passed:
```
fib/test_fib.py
vxlan/test_vxlan_decap.py
fdb/test_fdb.py
decap/test_decap.py
ipfwd/test_dip_sip.py
ipfwd/test_dir_bcast.py
acl/test_acl.py
vlan/test_vlan.py
platform_tests/test_reboot.py
```
This is to pick up BRCM SAI 4.3.5.1-6 fixes which contains the following fixes:
1. CS00012213351 SONIC-50679: [TH, TH2] Warm-reboot from 3.5 to 4.3 fails due to null objects discovered
2. CS00012182162: SONIC-49805 TD3 MMU config profile optimization changes
3. CS00012210826:SONIC-50205/760c60fc: Should read MMU_INTFI_MMU_PORT_TO_MMU_QUEUES_FC_BKP for TH3
Preliminary tests looks fine. BGP neighbors were all up with proper routes programmed
interfaces are all up
Manually ran the following test cases on 7050CX3 (TD3) T0 DUT and all passed:
```
fib/test_fib.py
vxlan/test_vxlan_decap.py
fdb/test_fdb.py
decap/test_decap.py
ipfwd/test_dip_sip.py
ipfwd/test_dir_bcast.py
acl/test_acl.py
vlan/test_vlan.py
platform_tests/test_reboot.py
```
Co-authored-by: Zhi Yuan (Carl) Zhao <zyzhao@arista.com>
Why I did it
The previous PR #8914 was reverted due to crashing the 202012 syseepromd.
How I did it
Tested the 202012 image with change and fixed the disparity between master and 202012.
How to verify it
Run the built image on the dut and syseepromd will not crash, and in redis-cli can fetch the eeprom information.
Why I did it
Sujin noticed that Arista eeprom platform API cannot update the redis database. Although Arista and Guohan believe that database update logic should be part of the daemon, it is easy enough to implement the fix for Arista for now.
How I did it
Made Arista eeprom platform API inherit from TlvInfoDecoder, then write Arista's own visit_eeprom method.
Co-authored-by: Zhi Yuan (Carl) Zhao <zyzhao@arista.com>
Why I did it
Vaibhav Dahiya notified me that invalid fan speed policy was expecting an error raised in sonic-mgmt testing, but it was not raised.
This change will fix test_platform_info.py::test_thermal_control_load_invalid_value_json
How I did it
Add in the suggested code chunk to Arista platform submodule to raise ValueError when an invalid fan speed is set in thermal policy.
How to verify it
Vaibhav Dahiya has verified it through sonic-mgmt testing.
Co-authored-by: Zhi Yuan (Carl) Zhao <zyzhao@arista.com>
Why I did it
To monitor the SSD health condition in DellEMC S6100 platform post upgrade.
A daemon is introduced to monitor the SSD every one hour.
To check for SSD status at boot time and at the time of cold-reboot.
All these changes are supported only for newer SSD firmware.
Porting changes from 201911 branch
Added a platform_reboot_pre_check script to prevent cold-reboot based on SSD status.
Depends on Azure/sonic-utilities#1788
DO NOT MERGE UNTIL ABOVE PR IS MERGED
How I did it
On branch s6100_ssd_202012
Changes to be committed:
(use "git restore --staged ..." to unstage)
modified: platform/broadcom/sonic-platform-modules-dell/debian/platform-modules-s6100.install
new file: platform/broadcom/sonic-platform-modules-dell/s6100/scripts/iSMART_64
new file: platform/broadcom/sonic-platform-modules-dell/s6100/scripts/platform_reboot_pre_check
modified: platform/broadcom/sonic-platform-modules-dell/s6100/scripts/s6100_platform.sh
new file: platform/broadcom/sonic-platform-modules-dell/s6100/scripts/s6100_ssd_mon.sh
new file: platform/broadcom/sonic-platform-modules-dell/s6100/scripts/s6100_ssd_upgrade_status.sh
new file: platform/broadcom/sonic-platform-modules-dell/s6100/scripts/soft-reboot_plugin
new file: platform/broadcom/sonic-platform-modules-dell/s6100/systemd/s6100-ssd-monitor.service
new file: platform/broadcom/sonic-platform-modules-dell/s6100/systemd/s6100-ssd-monitor.timer
new file: platform/broadcom/sonic-platform-modules-dell/s6100/systemd/s6100-ssd-upgrade-status.service
Why I did it
Power cycle test case fails for Z9332f in sonic-mgmt framework(#8605).
How I did it
Modified the platform API to return expected strings.
How to verify it
Power cycle the device and verify the reboot reason.
Run sonic-mgmt test_reboot script.
To enable saiserver docker on different platforms, it needs different configuration files. make the saiserver docker mount them in hwsku folder.
Co-authored-by: Ubuntu <richardyu@richardyu-ubuntu-vm0.trsxrdzozv2e1czsze2t05vqzh.ix.internal.cloudapp.net>
