On Tue, 16 Apr 2019 18:13:00 +0100, Dreamcat4 wrote: > [root:/sys/bus/i2c/devices] # i2cdetect 2 > WARNING! This program can confuse your I2C bus, cause data loss and worse! > I will probe file /dev/i2c-2. > I will probe address range 0x03-0x77. > Continue? [Y/n] y > 0 1 2 3 4 5 6 7 8 9 a b c d e f > 00: -- -- -- -- -- 08 -- -- -- -- -- -- -- > 10: -- -- -- -- -- -- -- -- 18 -- 1a -- -- -- -- -- > 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 30: 30 31 -- -- 34 35 UU UU -- -- -- -- -- -- -- -- > 40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- -- > 50: UU -- UU -- -- -- -- -- -- -- -- -- -- -- -- -- > 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > 70: -- -- -- -- -- -- -- -- > [root:/sys/bus/i2c/devices] # > [root:/sys/bus/i2c/devices] # cd ~ > [root:~] # ./decode-dimms.new > Cannot read /sys/bus/i2c/drivers/ee1004/2-0050/eeprom at > ./decode-dimms.new line 2358. > [root:~] 6 # > > > See that? The UU was not there before I ran those 2 commands. So it is > almost definately not something else blocking the port. Those UU are > our driver. That is the only new information here. Everything else was > same as before. This is correct, all UUs above are from the ee1004 driver. However it doesn't mean that there isn't another device on the SMBus also responding to I2C address 0x36. As long as it doesn't have a Linux driver bound to it, it won't show as UU (busy) in the output of i2cdetect. That would be stupid hardware design though, and would require extra engineering effort because the BIOS *needs* to be able to access page 0 of the SPDs. So I'm not saying it's what is happening. But as we have no other explanation at this point, all bets are off. BTW you have temperature sensors on these memory modules (I2C addresses 0x18 and 0x1a). I don't know if the DDR4 module sensors are compatible with DDR3 but if they are then maybe you can use the jc42 driver to get the readings. -- Jean Delvare SUSE L3 Support
