On 7/20/21 4:19 PM, Raviteja Narayanam wrote:

Hi,

[...]

quoted

quoted

I have tested this again on our boards with eeprom and other sensors, this

is working fine for us.

Can you share details of how those tests were performed ?

Stress test - 1:
Heavy ethernet traffic running in the background.
I2c commands script (like below) running. We can see visible stutter in the output as expected, but nothing failed.

i=0
while [ 1 ]
do
		i2ctransfer -y -f 2 w1@0X54 0X00 r31@0X54
		i2ctransfer -y -f 2 w1@0X54 0X00 r32@0X54
		i2ctransfer -y -f 2 w1@0X54 0X00 r255@0X54
		i2ctransfer -y -f 2 w1@0X54 0X00 r273@0X54
                              i2ctransfer -y -f 2 w1@0X54 0X00 r1@0X54

Could it be that you never see the problem because you always talk to 
one single device ?

Do you also test writes which are not 1 byte long ?

         i=$(expr $i + 1)
         echo "$i"
done

Stress test - 2:
Two i2c scripts running in parallel with commands as shown above with different bus numbers (as a result of mux), but going into same XIIC adapter.
This is also working fine.

Could it be the i2c-dev serializes each of those transfers , so no race 
can be triggered ?

Stress test - 3:
Two i2c scripts running in parallel with same commands in separate terminals. This is also working fine.

 From your log, the race condition is occurring at boot time during i2c clients registration. I am starting a similar test at my setup
to reproduce this issue at boot time.

Thank you