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 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®