From: Matthew Bettencourt <matthew.bettencourt@gmail.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [BUG] SPD5118 Intermittent MR11 Corruption During Suspend/Resume
Date: Wed, 2 Sep 2026 12:37:32 -0500 [thread overview]
Message-ID: <bb74ebc1-9ea6-4ab0-9443-d25f2f971e4e@gmail.com> (raw)
In-Reply-To: <56826d45-e18a-4f9e-94b0-3e6f335c4ee7@roeck-us.net>
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
>
next prev parent reply other threads:[~2026-09-02 17:37 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-30 23:21 [BUG] SPD5118 Intermittent MR11 Corruption During Suspend/Resume Matthew Bettencourt
2026-08-31 15:12 ` Guenter Roeck
2026-08-31 17:28 ` Guenter Roeck
2026-08-31 23:36 ` Matthew Bettencourt
[not found] ` <37132c40-aa82-4df1-b5ce-337601f3c085@gmail.com>
[not found] ` <3c4e9f59-5272-48cf-a4a0-eeefcba955a9@roeck-us.net>
2026-09-01 0:16 ` Matthew Bettencourt
2026-09-01 3:10 ` Guenter Roeck
2026-09-01 16:31 ` Matthew Bettencourt
2026-09-01 17:04 ` Guenter Roeck
2026-09-01 20:53 ` Matthew Bettencourt
2026-09-01 22:36 ` Guenter Roeck
2026-09-02 0:57 ` Matthew Bettencourt
2026-09-02 1:32 ` Guenter Roeck
2026-09-02 2:14 ` Matthew Bettencourt
2026-09-02 3:19 ` Guenter Roeck
2026-09-02 14:00 ` Matthew Bettencourt
2026-09-02 14:52 ` Guenter Roeck
2026-09-02 15:26 ` Matthew Bettencourt
2026-09-02 17:21 ` Guenter Roeck
2026-09-02 17:37 ` Matthew Bettencourt [this message]
2026-09-02 16:57 ` Armin Wolf
2026-09-02 17:08 ` Matthew Bettencourt
2026-09-02 17:22 ` Armin Wolf
2026-09-02 17:28 ` Matthew Bettencourt
2026-09-02 19:19 ` Armin Wolf
2026-09-02 19:25 ` Matthew Bettencourt
2026-09-02 19:31 ` Armin Wolf
2026-09-02 19:40 ` Matthew Bettencourt
2026-09-02 19:51 ` Armin Wolf
2026-09-03 18:01 ` Matthew Bettencourt
2026-09-03 18:16 ` Guenter Roeck
2026-09-03 18:25 ` Matthew Bettencourt
2026-09-03 21:05 ` Guenter Roeck
2026-09-03 22:47 ` Armin Wolf
2026-09-04 0:24 ` Matthew Bettencourt
2026-09-04 17:58 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bb74ebc1-9ea6-4ab0-9443-d25f2f971e4e@gmail.com \
--to=matthew.bettencourt@gmail.com \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.