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)