* new platform api, chassis part
* Inject mlnx mlx libs to platform monitor
* address the review comments
* remove some confusing naming.
* Adjust the minor cause to a more human-readable way when rebooted by firmware
* address review comments
* expose host dir /host/reboot-cause to pmon docker so that the reboot causing by user command can be identified
* 1. Revert "expose host dir /host/reboot-cause to pmon docker so that the reboot causing by user command can be identified"
Since the only hardware-causing reboot should be handled by get_reboot_cause and the logic of handling reboot cause is about to move to the host side, no need to mount this dir to pmon docker.
This reverts commit 3feb96869d.
2. adjust log output by using sonic_daemon_base.daemon_base.Logger.
3. remove the logic of verifying /host/reboot-cause/ files.
4. fix typo.
* implement get_firmware_version and adjust the interfaces regarding components' version retrieving according to the Azure/sonic-platform-common#34
* Added debug symbols to many debug dockers.
* For debug images *only*:
1) Archive source files into debug image
2) Archived source is copied into /src
3) Created an empty dir /debug
4) Mount both /src as ro & /debug as rw into every docker
5) Login banner will give some details on /src & /debug
6) Devs can copy core file into /debug and view it from inside a container.
7) Dev may create all gdb logs and other data directly into /debug.
* Dropped redundant REDIS_TOOLS per review comments.
* Added debug symbols to frr package and hence FRR based BGP docker.
* 1) Moved dbg_files.sh to scripts/
2) Src directories to archive are now collected from individual Makefiles.
3) Added few more debug symbols
4) Added few more debug dockers.
Here after no more changes except per review comments.
To debug:
Install required version of debug image in Switch or VM.
Copy core file into /debug of host
Get into Docker
gdb /usr/bin/<daemon> -c /debug/<your core file>
set directory /src/... <-- inside gdb to get the source
For non-in-depth debugging:
Download corresponding debug Docker image (docker-...-dbg.gz) to your VM
Load the image
Run image with entrypoint as 'bash' with dir containing core mapped in.
Run gdb on the core.
* sonic-device-data: update SAI config checker for Broadcom TD3 and TH3
The following properties have been approved by the Broadcom chip arch team:
l3_alpm_ipv6_128b_bkt_rsvd
ifp_inports_support_enable
pll_bypass
dpr_clock_frequency
device_clock_frequency
port_flex_enable
mmu_port_num_mc_queue
serdes_core_rx_polarity_flip_physical{<PORT>}
serdes_core_tx_polarity_flip_physical{<PORT>}
Signed-off-by: Dante (Kuo-Jung) Su <dante.su@broadcom.com>
Change-Id: I1c6239cddfb0582a9298e671d792a32f79e4f006
* [ARISTA] adding 7060_cs32s to eMMC exclusions
Following PR 2774 we added the 7060-cx32s according to the guidelines of
PR 2780
This adds the 7060-cx32s to the list f devices that mount /var/log as a
tmpfs to mitigate eMMC wearout
Signed-off-by: Michel Moriniaux <m.moriniaux@criteo.com>
* [ARISTA] adding 7060_cs32s to eMMC exclusions
Following PR 2774 we added the 7060-cx32s according to the guidelines of
PR 2780
This adds the 7060-cx32s to the list f devices that mount /var/log as a
tmpfs to mitigate eMMC wearout
Signed-off-by: Michel Moriniaux <m.moriniaux@criteo.com>
* Switch Vendor: DellEMC
* Switch SKU: s5232F
* ASIC Vendor: Broadcom
* Swich ASIC: Trident3
* Port Configuration: 32x100G
* SONiC Image: sonic-broadcom.bin
* LED support for s5232f
* Changes Include ipmitool implementation for platform_sensors script is inclued in pmon startup
* Added 100G,25G,10G configruation ( 100G is default).
* fix fast reboot compatibility
We should handle both cases for backward-compatible with 201803:
- fast-reboot
- SONIC_BOOT_TYPE=fast-reboot
* handle review comments
* add a comment that getBootType code snippet is shared between two files
- What I did
Added Daemon to Log LPC bus degradation in Intel C2000 processor. Intel Rangeley C2000 processors with revision less than or equal to 2 have issue where LPC bus degrades over time in some processors. To identify the problem and to notify the issue, a daemon has been added which will log on encountering the issue.
- How I did it
Added a daemon which validates the CPLD scratch(0x102) and SMF scratch(0x202) registers by writing and reading values on regular polling intervals (300 seconds). If there is a discrepancy between read and write, a critical log will be thrown.
- How to verify it
The infra is verify by simulating the issue where between write and read, the value in register is modified and the log appearance is checked.
- Description for the changelog
Added Daemon to identify LPC bus degradation issue and notify using syslog in Dell S6100 and Z9100 platforms. This daemon will only run on processors with revision less than or equal to 2.
* Update sonic-quagga submodule
* Port some patches from sonic-quagga
* Fix Makefile
* Another patch
* Uncomment bgp test
* Downport Nikos's patch
* Add a patch to alleviate the vendor issue
* use patch instead of stg
to include update in mellanox PFCWD lua script
matching new SAI
sonic-swss:
407d048 [mellanox] convert logic to use quanta in pfc_detect_mellanox.lua (#930)
67c0940 [test]: Skip test_clear in test_watermark (#937)
c72c34f Enable Vnet/Vxlan VS test (#935)
4c771d0 add incCrmAclUsedCounter and decCrmAclUsedCounter for SAI_ACL_BIND_POINT_TYPE_SWITCH case. (#899)
825c0cb [vs]: Fix bitmap VNET virtual switch test (#936)
4577b40 Add buffer pool watermark support (#853)
4a67378 Add support of VXLAN tunnel removal (#931)
Signed-off-by: Stepan Blyschak <stepanb@mellanox.com>
* [build]: wait 60 seconds for docker engine to start
On some platforms, it can take more than 1 second for docker
engine to start.
Signed-off-by: Guohan Lu <gulv@microsoft.com>
- create a dockerfile-marcros.j2 file with all common operations
written as j2 macro
- use single dockerfile instruction for COPY and RUN commands
when possible to improve build time
- reorganize dockerfile instructions to make more cache friendly
(in case someday we will remove --no-cache to build docker images)
Signed-off-by: Stepan Blyschak <stepanb@mellanox.com>
Some kernels are built with overlayfs as a builtin and not a module.
For these the check via lsmod currently fails.
This improvement now checks the kernel configuration for the
CONFIG_OVERLAY_FS entry. Depending on the OS and kernel version the
build configuration can be in multiple places.
- What I did
During boot/reload time, wait in a loop to check for bcm initialization.
Break the loop, once sdk is ready to process the 'bcmcmd' request (or) loop count reached the maximum value.
- How I did it
In the existing implementation during syncd start process will sleep for a fixed time (3 secs)
for sdk initialization to happen. But the time taken for sdk initialization is varying for different platforms.
To fix this issue, the syncd start process wait in a loop and check whether sdk is ready to process 'bcmcmd' command.
- How to verify it
Check for syncd process status and interface status.
Check for syslogs and no failures related to syncd should be present.
