[Mellanox] Add functionality to handle empty EEPROM files #20190
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
noaOrMlnx
approved these changes
Sep 8, 2024
liat-grozovik
approved these changes
Oct 6, 2024
|
@prgeor could you please provide your feedback as well? I am OK to merge it. |
prgeor
approved these changes
Oct 21, 2024
|
@qiluo-msft Can you please help merge this PR? Thanks |
|
@tshalvi is this flow relevant for 202405 only or also 202311? |
It is relevant for both 202311 and 202405 |
|
@prgeor Can you help review and merge? |
rkavitha-hcl
pushed a commit
to rkavitha-hcl/sonic-buildimage
that referenced
this pull request
Nov 15, 2024
…t#20190) - Why I did it On Mellanox platforms, it was decided that a good way to simulate an I2C stuck scenario would be to have the files representing the module's EEPROM remain empty. When these files are empty, module initialization will not complete because the read_eeprom() function gets stuck in an infinite loop (while num_bytes > 0: will never evaluate to False as the decrement operation num_bytes -= read_length has no effect). This happens because 0 bytes are always read from the EEPROM when it is empty. This PR addresses this issue. - How I did it On Mellanox platforms only, I added a validation check to ensure that if an attempt to read from the EEPROM results in 0 bytes read, the _read_eeprom() function exits and returns None. - How to verify it Simulate the empty EEPROM (can be done as described in the script below), update _get_eeprom_path() to redirect to the empty EEPROM location, config reload, and verify that not all ports are down.
bingwang-ms
added
Approved for 202405 Branch
and removed
Approved for 202405 Branch
labels
mssonicbld
pushed a commit
to mssonicbld/sonic-buildimage
that referenced
this pull request
Nov 15, 2024
…t#20190) - Why I did it On Mellanox platforms, it was decided that a good way to simulate an I2C stuck scenario would be to have the files representing the module's EEPROM remain empty. When these files are empty, module initialization will not complete because the read_eeprom() function gets stuck in an infinite loop (while num_bytes > 0: will never evaluate to False as the decrement operation num_bytes -= read_length has no effect). This happens because 0 bytes are always read from the EEPROM when it is empty. This PR addresses this issue. - How I did it On Mellanox platforms only, I added a validation check to ensure that if an attempt to read from the EEPROM results in 0 bytes read, the _read_eeprom() function exits and returns None. - How to verify it Simulate the empty EEPROM (can be done as described in the script below), update _get_eeprom_path() to redirect to the empty EEPROM location, config reload, and verify that not all ports are down.
|
Cherry-pick PR to 202405: #20819 |
mssonicbld
pushed a commit
that referenced
this pull request
Nov 15, 2024
- Why I did it On Mellanox platforms, it was decided that a good way to simulate an I2C stuck scenario would be to have the files representing the module's EEPROM remain empty. When these files are empty, module initialization will not complete because the read_eeprom() function gets stuck in an infinite loop (while num_bytes > 0: will never evaluate to False as the decrement operation num_bytes -= read_length has no effect). This happens because 0 bytes are always read from the EEPROM when it is empty. This PR addresses this issue. - How I did it On Mellanox platforms only, I added a validation check to ensure that if an attempt to read from the EEPROM results in 0 bytes read, the _read_eeprom() function exits and returns None. - How to verify it Simulate the empty EEPROM (can be done as described in the script below), update _get_eeprom_path() to redirect to the empty EEPROM location, config reload, and verify that not all ports are down.
mssonicbld
added
Included in 202405 Branch
and removed
Created PR to 202405 Branch
labels
aidan-gallagher
pushed a commit
to aidan-gallagher/sonic-buildimage
that referenced
this pull request
Nov 16, 2024
…t#20190) - Why I did it On Mellanox platforms, it was decided that a good way to simulate an I2C stuck scenario would be to have the files representing the module's EEPROM remain empty. When these files are empty, module initialization will not complete because the read_eeprom() function gets stuck in an infinite loop (while num_bytes > 0: will never evaluate to False as the decrement operation num_bytes -= read_length has no effect). This happens because 0 bytes are always read from the EEPROM when it is empty. This PR addresses this issue. - How I did it On Mellanox platforms only, I added a validation check to ensure that if an attempt to read from the EEPROM results in 0 bytes read, the _read_eeprom() function exits and returns None. - How to verify it Simulate the empty EEPROM (can be done as described in the script below), update _get_eeprom_path() to redirect to the empty EEPROM location, config reload, and verify that not all ports are down.
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.
Why I did it
On Mellanox platforms, it was decided that a good way to simulate an I2C stuck scenario would be to have the files representing the module's EEPROM remain empty. When these files are empty, module initialization will not complete because the read_eeprom() function gets stuck in an infinite loop (
while num_bytes > 0:will never evaluate to False as the decrement operationnum_bytes -= read_lengthhas no effect). This happens because 0 bytes are always read from the EEPROM when it is empty. This PR addresses this issue.Work item tracking
How I did it
On Mellanox platforms only, I added a validation check to ensure that if an attempt to read from the EEPROM results in 0 bytes read, the _read_eeprom() function exits and returns None.
How to verify it
Simulate the empty EEPROM (can be done as described in the script below), update _get_eeprom_path() to redirect to the empty EEPROM location, config reload, and verify that not all ports are down.
Which release branch to backport (provide reason below if selected)
Tested branch (Please provide the tested image version)
Description for the changelog
Link to config_db schema for YANG module changes
A picture of a cute animal (not mandatory but encouraged)