output as expected, but nothing failed.I have tested this again on our boards with eeprom and otheris working fine for us.
sensors, this
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
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 ?
There are transfers to other devices as well.
Our board has multiple power monitors, eeprom and other misc devices that
are accessed through the same driver and are working fine.
Do you also test writes which are not 1 byte long ?
Yes, like for eeprom 1 page (16 bytes) is written.
i=$(expr $i + 1)different bus numbers (as a result of mux), but going into same XIIC adapter.
echo "$i"
done
Stress test - 2:
Two i2c scripts running in parallel with commands as shown above with
This is also working fine.
Could it be the i2c-dev serializes each of those transfers , so no race can be
triggered ?
Yes, that is true because all our tests are going through the i2c-core only
and there is a lock at adapter level in the core.
It has to be reproducible through the i2c standard interface, which is not
happening at our setup.
I can take your patches that are targeted for this issue, rebase, test
and send them.