Re: [BUG] SPD5118 Intermittent MR11 Corruption During Suspend/Resume

[Matthew Bettencourt <matthew.bettencourt@gmail.com>]

Hello Guenter,

 >> - Do you have the latest BIOS installed on your system ?
 >>   Some statements online seem to suggest that the problem
 >>   _may_ be fixed with the latest BIOS on at least some
 >>   of the affected systems.

Yup as of Sept 3 2026 I am running the latest BIOS, 4.43. I think a new 
one is coming soonish as Asrock has started rolling out 4.50 on other 
x870 motherboards

 >> - Please boot the affected system with "usbcore.autosuspend=-1"
 >>   kernel command line parameter.
 >>   There are some claims online that this might resolve the problem.
 >>   I have no idea why that would be the case, but I guess it does
 >>   not hurt trying. Of course, if that _does_ work, we have yet another
 >>   mystery to solve.

I think we have another mystery to solve. I enabled 
"usbcore.autosuspend=-1" as a boot parameter and the errors have cleared 
up when I suspend/resume. I doubled checked this by removing 
"usbcore.autosuspend=-1" from my boot parameters and the errors came back.

 >> - Do you have memory with RGB-anything in the affected system ? If so,
 >>   is it controlled by the BIOS ? If yes, please disable the 
functionality
 >>   if that is possible.

I checked my BIOS and all RGB options are disabled.


Thanks,
Matthew
On 9/3/26 5:47 PM, Armin Wolf wrote:
> Am 03.09.26 um 23:05 schrieb Guenter Roeck:
> 
>> Hi Matthew,
>>
>> On 9/3/26 11:25, Matthew Bettencourt wrote:
>>> Hello Guenter,
>>>
>>>  > This system [MSI PRO B850M-A WIF/7600x3d] does _not_ have a 
>>> problem, or did I misunderstand the above ?
>>>
>>> That is correct. I was unable to replicate the issue with the MSI PRO 
>>> B850M-A WIF and 7600x3d. The MR11 registered never got corrupted 
>>> during sleep/resume and I never saw any piix4 errors logged when 
>>> using my piix4 driver with the additional logging enabled.
>>>
>>> I never swapped the CPUs as that was more hassle than I was willing 
>>> to do right now, but if it something that might be useful I can 
>>> probably try that at some point.
>>>
>> I don't think that would help. From all the reports I browsed through
>> so far, the common denominator seems to be that the affected systems use
>> a X870 or X870E chipset.
>>
>> Anyway, couple of ideas:
>>
>> - Do you have the latest BIOS installed on your system ?
>>   Some statements online seem to suggest that the problem
>>   _may_ be fixed with the latest BIOS on at least some
>>   of the affected systems.
>>
>> - Please boot the affected system with "usbcore.autosuspend=-1"
>>   kernel command line parameter.
>>   There are some claims online that this might resolve the problem.
>>   I have no idea why that would be the case, but I guess it does
>>   not hurt trying. Of course, if that _does_ work, we have yet another
>>   mystery to solve.
>>
>> - Do you have memory with RGB-anything in the affected system ? If so,
>>   is it controlled by the BIOS ? If yes, please disable the functionality
>>   if that is possible.
>>
>> Thanks,
>> Guenter 
> 
> According to the output of /proc/ioports, the root issue seems to be 
> that the ACPI firmware
> drives the SMBus controller and marks the affected IO ports as reserved, 
> but acpi_check_region()
> still tells the driver that the IO ports are available.
> 
> I already CCed the ACPI people to take a look at this.
> 
> Thanks,
> Armin Wolf
>