After updating to trixie on a desktop PC amd64, I found the following during boot on the screen:
“ee1004 0-0056: Failed to select page 0 (-6)”

There's the context in the dmesg:

[    8.161199] IPMI message handler: version 39.2
[    8.328811] input: PC Speaker as /devices/platform/pcspkr/input/input5
[    8.360453] ee1004 0-0056: Failed to select page 0 (-6)
[    8.360515] ee1004 0-0056: 512 byte EE1004-compliant SPD EEPROM, read-only
[    8.513263] ipmi device interface

Any hint on what exactly failed? Or any high-level description of what failed, in plain terms? With the prior kernel 6.1.0-37-amd64, there was no such message.

According to `dmidecode -t memory`, the PC has two 16 GB DDR4 modules from Samsung, each working at 2933 MT/s and with voltage 1.2 V, and the error-correction type is single-bit ECC.

Gratefully

Now tested with two equal 32 GB RDIMMs Samsung M393A4K40CB2-CVF installed in DIMM_A1 and DIMM_C1 on ASUS WS C422 PRO/SE with BIOS 4801 with kernel 6.12.101+deb13-amd64. The SPD EEPROM is detected and the ee1004 driver is bound to it, but the driver's attempt to select page 0 fails with -ENXIO. Consequently, the driver's sysfs eeprom attribute cannot be read, and decode-dimms fails. Here is the excerpt from boot time:

[    8.550652] ipmi_si: Trying ACPI-specified kcs state machine at i/o address 0xca2, slave address 0x20, irq 0
[    8.596883] input: PC Speaker as /devices/platform/pcspkr/input/input5
[    8.608418] ee1004 0-0056: Failed to select page 0 (-6)
[    8.608532] ee1004 0-0056: 512 byte EE1004-compliant SPD EEPROM, read-only
[    8.774836] videodev: Linux video capture interface: v2.00

# decode-dimms
Cannot read /sys/bus/i2c/drivers/ee1004/0-0056/eeprom at /usr/bin/decode-dimms line 2455.

The SPD device is instantiated at 0x56:

# dmesg | grep "i2c"| head -1
[    3.138736] i2c i2c-0: Successfully instantiated SPD at 0x56


The device at 0x56 is claimed by ee1004 (“UU” below):

# i2cdetect -y 0
      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         08 -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- UU UU -- -- -- -- -- -- -- --
40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- UU -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Direct access to the page-selection addresses 0x36/0x37 fails:

# i2cget -f -y 0 0x36
Error: Read failed
# i2cget -f -y 0 0x37
Error: Read failed

i2cdump returns 0xff for every byte, although the device is claimed by ee1004:

# i2cdump -f -y 0 0x56
No size specified (using byte-data access)
      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................


Could this be related to the way ee1004 attempts to select the SPD page on this particular I2C adapter/controller? In particular, “Failed to select page 0 (-6)” appears to occur before the actual SPD contents can be read.

The SMBus adapter is as follows:

# readlink -f /sys/bus/i2c/devices/i2c-0
/sys/devices/pci0000:00/0000:00:1f.4/i2c-0
# lspci -nn -s 00:1f.4
00:1f.4 SMBus [0c05]: Intel Corporation 200 Series/Z370 Chipset Family SMBus Controller [8086:a2a3]

Gratefully,
Alma

Hi Alma,

It is unusual for the EEPROM to live at address 0x56. The valid address
range is 0x50-0x57 but they are usually populated in order, so if you
installed your memory modules following the recommended order, they
would show at 0x50 and either 0x51, 0x52 or 0x54.

I see that your motherboard has 8 memory slots, so it is possible that
the whole address range is used, however, considering that you
installed 2 memory sticks and only one address in the range responded
to the probe, I am reasonably certain that the device at address 0x56
is NOT your memory's SPD EEPROM.

I have some SMBus development experience with Asus server boards and my
bet is that the SPD EEPROMs are not connected directly, but instead are
behind an I2C multiplexer. The first set of memory modules would be on
a first segment behind the multiplexer, at addresses 0x50-0x53, and the
other set of memory modules would be on a second segment behind the
multiplexer, also at addresses 0x50-0x53.

I believe this is an incorrect detection and the ee1004 driver should
not bind to address 0x56 on i2c-0 in the first place.

Please try unloading the ee1004 driver, then running i2cdetect again.
If addresses 0x36 and 0x37 do not show on the map, this would confirm
my theory.

According to page 1-5 of my motherboard manual, dated 2019-10-28, the slots DIMM_A1 and DIMM_C1 should be used when installing two modules (and indeed, they are used as per `dmidecode -t memory` and from what I recall).

Here we go:

# modprobe -r ee1004 && i2cdetect -y 0 && modprobe ee1004
      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         08 -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- 56 -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

What next?

This confirms my guess that the device at 0x56 is not an SPD EEPROM.
Next steps would be as follows:

* Short term, you want to blacklist the ee1004 driver on your system.
  It is not a good idea to load a driver which binds to the wrong
  device.

* Still short term, we should look into the ee1004 auto-detection logic
  and see it it can be made more reliable.

* Mid term, we may want to add a kernel option to disable automatic
  probing of SPD EEPROMs. I seem to recall some proposals but it looks
  like they never made it into the upstream kernel. I'm not sure if
  this should be a system-wide switch (handled by the i2c core) or a
  per-driver setting (e.g. a new flag in i2c-i801's disable_features
  parameter).

* Still mid term, we probably want to blacklist SPD probing explicitly
  for your motherboard (we'll need to know the contents of
  /sys/devices/virtual/dmi/id/board_vendor and
  /sys/devices/virtual/dmi/id/board_name on your system). Maybe this
  can be implemented as an empty entry in mux_dmi_table (as in, we know
  the board requires multiplexing, but we don't know yet to implement
  it on that board).

* Long term, we need the hardware vendor to provide technical
  information about the board so that we can implement SMBus
  multiplexing support in the i2c-i801 driver (if that's really how
  things are implemented on your board - that's only a guess from me at
  this point). Asus provided information about their Z8 series long ago
  and I was able to add support for it back then. It would be wonderful
  if they could provide similar information about the WS C422 PRO/SE so
  that a kernel developer can add support.

Awesome!

Below, I'll comment on whatever I can meaningfully comment.

Here we go, following https://wiki.debian.org/KernelModuleBlacklisting:

$ echo "blacklist ee1004" | sudo tee /etc/modprobe.d/ee1004.conf
blacklist ee1004
$ sudo depmod -ae
depmod: WARNING: -e needs -E or -F
$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.12.107+deb13-amd64

Can the above warning be ignored?

Here we go:

$ cat /sys/devices/virtual/dmi/id/board_vendor
ASUSTeK COMPUTER INC.
$ cat /sys/devices/virtual/dmi/id/board_name
WS C422 PRO_SE

The user manuals for the board lie at https://www.asus.com/de/motherboards-components/motherboards/workstation/ws-c422-pro-se/helpdesk_manual?model2Name=WS-C422-PRO-SE .

As for anything deeper, it would be better if you, as a developer, contacted them directly. (In fact, the last time I actually succeeded in issuing a ticket was a long time ago, before the warranty ran out.) An ASUS support contact form lies at https://www.asus.com/support/product/contactus/services/questionform .

Concerning Debian #1110749: Now tested on a different computer with the same motherboard but 2 × 16 GB Samsung M393A2K43DB3-CWE, installed into DIMM_A1 and DIMM_C1. The outcome is the same.

I think yes. AFAIK that depmod step isn't needed and the wiki should be
fixed.

Does that help?

If the above is confirmed to help, I think we have everything to
implement a quirk with the same effect as blacklisting manually.

Best regards
Uwe

Here we go (after many reboots):

$ cat /etc/modprobe.d/ee1004.conf
blacklist ee1004
$ lsmod | grep ee1004
$ sudo dmesg | egrep "i2c|ee1004"
$ sudo decode-dimms
No EEPROM found, try loading the eeprom, at24 or or ee1004 module
$ sudo i2cdetect -y 0
      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         08 -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- 56 -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
$


It helps in the sense that the error messages are gone. Is doesn't help in the sense that I still don't know how to programmatically read SPD-EEPROM of the modules installed on my system.

Alma

$ cat /etc/modprobe.d/ee1004.conf
blacklist ee1004
$ lsmod | grep ee1004
$ sudo dmesg | egrep "i2c|ee1004"
$ sudo decode-dimms
No EEPROM found, try loading the eeprom, at24 or or ee1004 module
$ sudo i2cdetect -y 0
      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         08 -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- 56 -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
$


It helps in the sense that the error message “ee1004 0-0056: Failed to select page 0 (-6)” is gone. It doesn't help in the sense that I still don't know how to programmatically read SPD-EEPROM of the modules installed on my system.

Alma