Re: [BUG] SPD5118 Intermittent MR11 Corruption During Suspend/Resume
From: Matthew Bettencourt
Date: Wed Sep 02 2026 - 14:00:11 EST
Hello Guenter
> I2C bus multiplexers only return a single data byte reflecting the
> currently
> selected bus. On writes they also accept a single byte, where a set bit
> indicates
> which of its channel(s) should be enabled. So i2cdump does not really work.
> Actually, using i2cdump might have messed it up because the writes involved
> might change the active bus... sorry, I should have mentioned before.
> In general it is not safe to use i2cdump on an unknown device. Worst case
> it can turn the hardware into a brick (seriously - I have seen that
> happen).
>
> You could try "i2cget 12 0x71" and "i2cget 12 0x73". That should return
> the active channel(s) if those are really I2C bus multiplexers. If they
> are,
> only a single bit should be set (again, i2cdump might have messed it up,
> so you might want to reboot).
No worries, the system did not brick itself haha. I rebooted and executed the i2cget commands
# i2cget 12 0x71
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will read from device file /dev/i2c-12, chip address 0x71, current data
address, using read byte.
Continue? [Y/n] y
0x1f
# i2cget 12 0x73
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will read from device file /dev/i2c-12, chip address 0x73, current data
address, using read byte.
Continue? [Y/n] y
0x1f
> so I don't have any of the AMDI0010 devices. Maybe that is the built-in
> GPU ?
I thought I had disabled the igpu in the BIOS, but I might have reset the BIOS to factory settings at some point so it might have been become enabled again. I can check the BIOS settings when I get home.
>> If it is worth while I have access to second AMD machine, PRO B850M-A
>> WIFI/7600x3d/Teamgroup 2x16GB - FLBD532G6000HC30DC01, which I can swap
>> parts from/to. Even though its a completely different system it might
>> worth it to swap parts out and see then what comes up on either system
>> to help identify what might be going on with the i2c bus devices.
>>
>
> It might be worthwhile if that system does not suffer from the same
> problem.
>
> Bus-wise I can see that you seem to have different I2C busses in your
> system. I have
Yes I can do that. I will swap the RAM kits on both systems and see what happens, checking for the sleep/resume error message with the piix4 transaction log.
Thanks,
Matthew
On 9/2/26 12:21 PM, Guenter Roeck wrote:
Hi Matthew,
On 9/2/26 08:26, Matthew Bettencourt wrote:
Hello Guenter,
Here is the i2cdump for those two 0x71 and 0x73 devices
# i2cdump -y -f 12 0x73 b
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: ff ff ff ff XX ff 12 ff 12 ff ff ff XX XX XX XX ....X.?.?...XXXX
10: XX 0f XX XX XX XX XX XX XX XX XX XX XX XX XX XX X?XXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
80: 00 e1 f9 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f .???????????????
90: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ????????????????
a0: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f .???????????????
b0: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ????????????????
c0: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f .???????????????
d0: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ????????????????
e0: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f .???????????????
f0: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ????????????????
# i2cdump -y -f 12 0x71 b
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: ff ff ff ff XX ff 57 ff 57 ff ff ff XX XX XX XX ....X.W.W...XXXX
10: XX 0f XX XX XX XX XX XX XX XX XX XX XX XX XX XX X?XXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
80: 00 0b e0 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f .???????????????
90: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ????????????????
a0: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f .???????????????
b0: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ????????????????
c0: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f .???????????????
d0: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ????????????????
e0: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f .???????????????
f0: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ????????????????
I2C bus multiplexers only return a single data byte reflecting the currently
selected bus. On writes they also accept a single byte, where a set bit indicates
which of its channel(s) should be enabled. So i2cdump does not really work.
Actually, using i2cdump might have messed it up because the writes involved
might change the active bus... sorry, I should have mentioned before.
In general it is not safe to use i2cdump on an unknown device. Worst case
it can turn the hardware into a brick (seriously - I have seen that happen).
You could try "i2cget 12 0x71" and "i2cget 12 0x73". That should return
the active channel(s) if those are really I2C bus multiplexers. If they are,
only a single bit should be set (again, i2cdump might have messed it up,
so you might want to reboot).
# ls -l /sys/bus/i2c/devices/
total 0
lrwxrwxrwx. 1 root root 0 Sep 2 10:08 12-0051 -> ../../../devices/ pci0000:00/0000:00:14.0/i2c-12/12-0051
lrwxrwxrwx. 1 root root 0 Sep 2 10:08 12-0053 -> ../../../devices/ pci0000:00/0000:00:14.0/i2c-12/12-0053
lrwxrwxrwx. 1 root root 0 Sep 2 10:08 i2c-0 -> ../../../devices/ platform/AMDI0010:00/i2c-0
lrwxrwxrwx. 1 root root 0 Sep 2 10:08 i2c-1 -> ../../../devices/ platform/AMDI0010:01/i2c-1
lrwxrwxrwx. 1 root root 0 Sep 2 10:08 i2c-10 -> ../../../devices/ pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.0/drm/ card1/card1-DP-2/i2c-10
lrwxrwxrwx. 1 root root 0 Sep 2 10:08 i2c-11 -> ../../../devices/ pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.0/drm/ card1/card1-DP-3/i2c-11
lrwxrwxrwx. 1 root root 0 Sep 2 10:08 i2c-12 -> ../../../devices/ pci0000:00/0000:00:14.0/i2c-12
lrwxrwxrwx. 1 root root 0 Sep 2 10:08 i2c-13 -> ../../../devices/ pci0000:00/0000:00:14.0/i2c-13
lrwxrwxrwx. 1 root root 0 Sep 2 10:08 i2c-14 -> ../../../devices/ pci0000:00/0000:00:14.0/i2c-14
lrwxrwxrwx. 1 root root 0 Sep 2 10:08 i2c-2 -> ../../../devices/ pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.0/i2c-2
lrwxrwxrwx. 1 root root 0 Sep 2 10:08 i2c-3 -> ../../../devices/ pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.0/i2c-3
lrwxrwxrwx. 1 root root 0 Sep 2 10:08 i2c-4 -> ../../../devices/ pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.0/i2c-4
lrwxrwxrwx. 1 root root 0 Sep 2 10:08 i2c-5 -> ../../../devices/ pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.0/i2c-5
lrwxrwxrwx. 1 root root 0 Sep 2 10:08 i2c-6 -> ../../../devices/ pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.0/i2c-6
lrwxrwxrwx. 1 root root 0 Sep 2 10:08 i2c-7 -> ../../../devices/ pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.0/i2c-7
lrwxrwxrwx. 1 root root 0 Sep 2 10:08 i2c-8 -> ../../../devices/ pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.0/i2c-8
lrwxrwxrwx. 1 root root 0 Sep 2 10:08 i2c-9 -> ../../../devices/ pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.0/drm/ card1/card1-DP-1/i2c-9
lrwxrwxrwx. 1 root root 0 Sep 2 10:08 i2c-MSFT8000:00 -> ../../../ devices/platform/AMDI0010:01/i2c-1/i2c-MSFT8000:00
If it is worth while I have access to second AMD machine, PRO B850M-A WIFI/7600x3d/Teamgroup 2x16GB - FLBD532G6000HC30DC01, which I can swap parts from/to. Even though its a completely different system it might worth it to swap parts out and see then what comes up on either system to help identify what might be going on with the i2c bus devices.
It might be worthwhile if that system does not suffer from the same problem.
Bus-wise I can see that you seem to have different I2C busses in your system. I have
lrwxrwxrwx 1 root root 0 Aug 29 16:26 0-0050 -> ../../../devices/ pci0000:00/0000:00:14.0/i2c-0/0-0050
lrwxrwxrwx 1 root root 0 Aug 29 16:26 0-0051 -> ../../../devices/ pci0000:00/0000:00:14.0/i2c-0/0-0051
lrwxrwxrwx 1 root root 0 Aug 29 16:26 0-0052 -> ../../../devices/ pci0000:00/0000:00:14.0/i2c-0/0-0052
lrwxrwxrwx 1 root root 0 Aug 29 16:26 0-0053 -> ../../../devices/ pci0000:00/0000:00:14.0/i2c-0/0-0053
lrwxrwxrwx 1 root root 0 Aug 29 16:26 i2c-0 -> ../../../devices/ pci0000:00/0000:00:14.0/i2c-0
lrwxrwxrwx 1 root root 0 Aug 29 16:26 i2c-1 -> ../../../devices/ pci0000:00/0000:00:14.0/i2c-1
lrwxrwxrwx 1 root root 0 Aug 29 16:26 i2c-2 -> ../../../devices/ pci0000:00/0000:00:14.0/i2c-2
lrwxrwxrwx 1 root root 0 Aug 29 16:26 i2c-3 -> ../../../devices/ pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.0/i2c-3
lrwxrwxrwx 1 root root 0 Aug 29 16:26 i2c-4 -> ../../../devices/ pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.0/i2c-4
lrwxrwxrwx 1 root root 0 Aug 29 16:26 i2c-5 -> ../../../devices/ pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.0/i2c-5
lrwxrwxrwx 1 root root 0 Aug 29 16:26 i2c-6 -> ../../../devices/ pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.0/i2c-6
lrwxrwxrwx 1 root root 0 Aug 29 16:26 i2c-7 -> ../../../devices/ pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:00.0/0000:03:00.0/drm/ card1/card1-DP-1/i2c-7
so I don't have any of the AMDI0010 devices. Maybe that is the built-in GPU ?
Thanks,
Guenter