error with KF560C40BBAK2-32 (2x16kit) about kfrgb

[KeyofBlueS]

You're welcome 👍

You can try geofbot's fork of OpenRGB https://gitlab.com/geofbot/OpenRGB/-/tree/fury_ddr5 (there is also a mr to upstream https://gitlab.com/CalcProgrammer1/OpenRGB/-/merge_requests/1887, but it seems it is in stall right now) and see if the detection fails there too. I'm using it and it works well.

The risk you take by commenting those lines is if addresses 0x6[0-7], 0x5[0-7] and 0x4[8-f] exist on an smbus that support Quick Command, but they ARE NOT Kingston Fury BEAST\RENEGADE DDR5 devices (model is found on step 4, the one that gives you Error: Adapter does not have I2C block read capability).
In your case you know you have two Kingston Fury BEAST RGB DDR5 in slot 2 and 4, and this match the detection on step 1 and 2. I'm not trying to convince you to risk, just want you to know how it works.

I suggest you to try to figure out the reason for that error and solve it if possible, try e.g. with your distro support resource.

Feel free to let me know how it goes.

[KeyofBlueS]

And please update the script to the latest version as it contains a fix for smbus detection.

[KeyofBlueS]

Check if i2c-dev is built into kernel:
cat /lib/modules/$(uname -r)/modules.builtin | grep i2c

In that procedure there is a mention that in some scenarios a kernel > 5.7 is required, check your kernel version with uname -a.
Also, it say that "To resolve an ACPI conflict add the acpi_enforce_resources=lax kernel parameter." Have you tried that?

Anyway, if you are willing to RISK, you can disable detection steps 3 and 4, relying only on the first two steps by commenting lines from REDACTED and from REDACTED of the (actual version 0.9.5) script.

[aschiavon91]

Oh, sorry for my misinterpretation, I was thinking that it will fry my memories or motherboard, don't ask me why this come to my mind 😆
I tested the geofbot fork, and absolutely worked! But, I don't wanna let you without answers too, so, I will make the changes, as you explained before, and run it to see if it works, I'm pretty sure that I'm using Fury BEAST RGB DDR5 in slot 2 and 4, and nothing is in slot 1 and 3, so, I guess it's safe to test.

[KeyofBlueS]

Happy that fork works for you also.
You can try those changes only if you are curious or want/need to use this script, i don't need to know if it works, but thanks for the thought.

[KeyofBlueS]

@cloudednine and everyone please, the script is now updated so commenting those lines no longer work.

You can use the undocumented option --iwanttoriskandskipmodeldetectionevenifiknowthisisstronglynotrecommended, the name says all so please don't use it recklessly, try to open an issue here first, attaching the full log (option -D).

Thanks and best regards.

[KeyofBlueS]

Hi!

The first thing that comes in my mind is that this ram kit is some new revision so maybe something changed.

• Try to run again this script after a cold boot (turn completely off the pc).

• Still after a cold boot, please post the output of:
  sudo i2cdetect 0
sudo i2cdump 0 0x49 b
sudo i2cdump 0 0x61 i
sudo i2cdump 0 0x4b b
sudo i2cdump 0 0x63 i

[aschiavon91]

yeah, I also think it's some kind of new variant.
Running the updated version of the script, right after a cold boot, also doesn't work

PCI (legacy) 
                            
- RAM in slot 2 on SMBus i2c-0 doesn't seems to be a Kingston Fury BEAST\RENEGADE DDR5!

- Kingston Fury DDR5 RAM in slot 2 not found on SMBus i2c-1.

- Kingston Fury DDR5 RAM in slot 2 not found on SMBus i2c-2.

- Please select an SMBus (or type 'quit' to exit from /home/aschiavon/bin/kfrbg.sh:
 0) i2c-0	smbus     	SMBus PIIX4 adapter port 0 at 0b00	SMBus adapter
 1) i2c-1	smbus     	SMBus PIIX4 adapter port 2 at 0b00	SMBus adapter
 2) i2c-2	smbus     	SMBus PIIX4 adapter port 1 at 0b20	SMBus adapter

Now the output of the mentioned commands

sudo i2cdetect 0                                                  
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0.
I will probe address range 0x08-0x77.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- 15 -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- 49 -- 4b -- -- -- 4f 
50: -- 51 -- 53 -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- 61 -- 63 -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --  

sudo i2cdump 0 0x49 b                                     
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x49, mode byte
Continue? [Y/n] Y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
10: 00 00 00 00 00 2c 20 00 00 04 00 05 60 00 60 60    ....., ..?.?`.``
20: cf dc 63 00 00 dc 63 b4 63 80 88 42 20 22 b4 5e    ??c..?c?c??B "?^
30: 00 00 80 00 0e 00 00 00 00 00 00 12 8a 8c 00 00    ..?.?......???..
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

sudo i2cdump 0 0x61 i
Error: Adapter does not have I2C block read capability

sudo i2cdump 0 0x4b b
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x4b, mode byte
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
10: 00 00 00 00 00 2c 20 00 00 04 00 05 60 00 60 60    ....., ..?.?`.``
20: cf dc 63 00 00 dc 63 b4 63 80 88 42 20 22 b4 5e    ??c..?c?c??B "?^
30: 00 00 80 00 0e 00 00 00 00 00 00 12 8a 8c 00 00    ..?.?......???..
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

sudo i2cdump 0 0x63 i
Error: Adapter does not have I2C block read capability

[KeyofBlueS]

This is the "detection chain":

 - lshw: check for 'vendor: Kingston' and 'product: KF5*'.
  - i2cdetect: check if addresses 0x6[0-7], 0x5[0-7] and 0x4[8-f] exist on an smbus that support Quick Command.
   - i2cdump (mode b): on address 0x4[8-f] check if registers &0x21 and &0x25 are both =78 OR =b4 and &0x27=78.
    - i2cdump (mode i): on address 0x6[0-7] check if blocks 0x02=0x46, 0x03=0x55, 0x04=0x52, 0x05=0x59, 0x07=0x10 (for BEAST) OR =0x11 (for RENEGADE).

The detection pass on step 1 and 2, but fails on step 3 and 4.

On step 3, registers &0x21 and &0x25 are not both =78 OR =b4 and &0x27=78.
In your case &0x21 and &0x25 are both =dc and &0x27=b4. I don't know why they are not as expected, let's assume a new ram revision here.

Step 4 is the real problematic one, as your system give Error: Adapter does not have I2C block read capability. Searching for this error gave little\no results. Maybe the required kernel modules aren't loaded idk... what is the output of lsmod | grep 'i2c'?

[aschiavon91]

I bought the memory kit this month, so, I also think it can be a revision or something like that.
About the i2c error, I saw it, but idk if something is wrong, I'm using openrgb with no issues.
this is the output:

$ lsmod | grep 'i2c'
i2c_algo_bit           16384  1 amdgpu
i2c_piix4              28672  0

[KeyofBlueS]

Module i2c-dev is not loaded. Follow this procedure https://gitlab.com/CalcProgrammer1/OpenRGB#smbus-access-1

[aschiavon91]

I did but it not worked, even loading it manually is not working, idk what more I can try

[aschiavon91]

using the command to check if i2c-dev is built into the kernel, I can see it!

JFYI, I'm currently using kernel 6.2.6-76060206-generic, from the PopOS repository.

I'm not sure if I wanna risk it right now, it's all brand new parts, and I barely used it, soo, maybe in the future, I will give it a try.

anyway, thanks for the help man, I really appreciate it!

[cloudednine]

Anyway, if you are willing to RISK, you can disable detection steps 3 and 4, relying only on the first two steps by commenting lines from REDACTED and from REDACTED of the (actual version 0.9.5) script.

For posterity, if it helps anyone who encounters this thread, I own the KF560C36BBEAK2-32 and I have exactly the same detection problem described in this thread.

On Arch Linux I encountered so many build dependency problems with the OpenRGB fork, I took the risk with this script. After much manual checking, commenting out exactly these lines worked very well.