Skip to content

[Mellanox] Add functionality to handle empty EEPROM files #25

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

Closed
wants to merge 1 commit into from

Conversation

tshalvi
Copy link
Owner

@tshalvi tshalvi commented Sep 5, 2024

Why I did it

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.

Work item tracking
  • Microsoft ADO (number only):

How I did it

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.

cd /
mkdir -p path_to_empty_files_folder
cd path_to_empty_files_folder

for i in $(seq 1 300); do
    mkdir -p $i
    touch $i/data
done

mkdir -p 0/i2c-0x50
touch 0/i2c-0x50/data
mkdir -p 0/i2c-0x51
touch 0/i2c-0x51/data

Which release branch to backport (provide reason below if selected)

  • 201811
  • 201911
  • 202006
  • 202012
  • 202106
  • 202111
  • 202205
  • 202211
  • 202305

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)

@tshalvi tshalvi closed this Feb 16, 2025
tshalvi pushed a commit that referenced this pull request Mar 12, 2025
…tically (sonic-net#733)

#### Why I did it
src/sonic-sairedis
```
* c29f53d - (HEAD -> 202412, origin/HEAD, origin/202412) Optimize counter initialization by reducing the number of bulk counter poll calls and communication between swss/sairedis (#25) (9 hours ago) [mssonicbld]
```
#### How I did it
#### How to verify it
#### Description for the changelog
tshalvi pushed a commit that referenced this pull request Mar 12, 2025
…tomatically (sonic-net#761)

#### Why I did it
src/sonic-linux-kernel
```
* b905a55 - (HEAD -> 202412, origin/HEAD, origin/202412) [code sync] Merge code from sonic-net/sonic-linux-kernel:202411 to 202412 (#25) (21 hours ago) [mssonicbld]
```
#### How I did it
#### How to verify it
#### Description for the changelog
tshalvi pushed a commit that referenced this pull request Mar 12, 2025
…omatically (sonic-net#780)

#### Why I did it
src/sonic-swss-common
```
* c84a342 - (HEAD -> 202412, origin/HEAD, origin/202412) [FC] remove FLEX_COUNTER_DELAY_STATUS_FIELD (sonic-net#982) (#25) (20 hours ago) [mssonicbld]
```
#### How I did it
#### How to verify it
#### Description for the changelog
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants