-
Notifications
You must be signed in to change notification settings - Fork 156
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Skip loading media config from media_settings.json for fast-reboot #221
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
yxieca
reviewed
Nov 3, 2021
yxieca
requested changes
Nov 3, 2021
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as commented.
yxieca
reviewed
Nov 8, 2021
prgeor
reviewed
Nov 9, 2021
prgeor
previously approved these changes
Nov 10, 2021
yxieca
previously approved these changes
Nov 10, 2021
prgeor
reviewed
Nov 10, 2021
prgeor
approved these changes
Nov 10, 2021
vdahiya12
pushed a commit
to vdahiya12/sonic-platform-daemons
that referenced
this pull request
Apr 4, 2022
…ic-net#221) Description Add retry reading/setting mux status to simulated y-cable driver Motivation and Context When DUT is rebooted, xcvrd may call the simulated y-cable driver to get mux direction before the mgmt interface is up. The simulated y-cable driver needs to send HTTP request to mux simulator server to read mux status. It has dependency on the mgmt interface. So, this could result in below error: Oct 16 03:15:44.029933 sonic-dut ERR pmon#xcvrd[34]: y_cable_port 1: GET http://192.168.1.33:8082/mux/vms21-6/0 for physical_port 1 failed with URLError(OSError(113, 'No route to host')) Oct 16 03:15:44.030306 sonic-dut ERR pmon#xcvrd[34]: Error: Could not establish the active side for Y cable port Ethernet0 to perform read_y_cable update state db This would cause other problem and may result in same interface on both upper tor and lower tor remains in "standby" state. The fix is to add retry to the simulated y-cable driver for reading or setting mux status. The retry interval is 1 second. Retry timeout is 30 seconds. How Has This Been Tested? * The issue can be reliably reproduced on a 7260 dualtor testbed after run the test_acl::TestAclWithReboot cases. With this fix, the issue cannot be reproduced. * Tested the config mux mode active command with or without icmp responder. * Tested updating mux status by call mux simulator API to see if the new status is reflected to DUTs. Signed-off-by: Xin Wang <xiwang5@microsoft.com>
vdahiya12
pushed a commit
to vdahiya12/sonic-platform-daemons
that referenced
this pull request
Apr 4, 2022
PR sonic-net#221 added retry logic to the simualted y_cable driver and introduced typos. This change is to fix the typos. Signed-off-by: Xin Wang <xiwang5@microsoft.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Changes to skip loading media_settings.json in case of fast-reboot
Motivation and Context
During fast-reboot, delayed serdes programming done after transceiver detection results in additional interface flap and traffic loss exceeding the required 30s (Issue: sonic-net/sonic-buildimage#9165). This is addressed by making a backup of media settings from appdb during fast-reboot (sonic-net/sonic-utilities#1910) and loading this to redis after the switch boots up (sonic-net/sonic-buildimage#9166). Configuration of serdes triggered by reading media_settings.json file is skipped in this PR
How Has This Been Tested?
Verified by running advanced_reboot/test_advanced_reboot.py::test_fast_reboot and ensured that the test passes.
Verified TRANSCEIVER_INFO in stateDB, SERDES objects in asicdb after bootup
Also tested coldboot and ensured no side effects.
Additional Information (Optional)