Re: [Bug 220110] probably thunderbolt or pci leads to pci usage counter underflow

[Mario Limonciello <mario.limonciello@amd.com>]

On 5/13/2025 2:45 PM, Bjorn Helgaas wrote:
>  From Denis's report at https://bugzilla.kernel.org/show_bug.cgi?id=220110:
> 
>> I am having problems with my laptop that has a thunderbolt
>> controller to which I connected an AMD 6750XT.
>>
>> The topology of my system is described in this bug:
>> https://gitlab.freedesktop.org/drm/amd/-/issues/4014 yet I don't
>> know if this is related or not.
>>
>> I experienced PC attempting to enter s2idle while playing a YT
>> video; PC has become totally unresponsive to input in any
>> keyboard/mouse and power button after turning off screens attached
>> to the AMD card (the built-in screen was off already).
>>
>>  From a look at the logs it appears one uncorrectible AER pci error
>> triggered a pci root reset, and that comes with a bug where the
>> usage counter assumes a wrong value; this in turn seems to cause all
>> sorts of weird bugs.
>>
>> That however is my interpretation of the attached log, that might be
>> very wrong.
>>
>> This is the first time I experience this bug in a year with this
>> laptop and I don't know how easy it is to reproduce.
>>
>> The kernel has been compiled from sources and it has
>>
>>    [PATCH v2] PCI: Explicitly put devices into D0 when initializing
>>    [PATCH v4] PCI/PM: Put devices to low power state on shutdown
>>
>> as I am helping testing things. I find unlikely any of those might
>> cause these issues especially "PCI: Explicitly put devices into D0
>> when initializing" that has been there for a few weeks now.
>>
>> Thanks in advice to whoever will help me.

 From the logs the system didn't actually enter s2idle, but because of 
the failure to recover after AER he lost the external GPU.

I don't expect that "PCI/PM: Put devices to low power state on shutdown" 
has anything to do with this issue.  This should only affect system 
shutdown.  (Tangentially related comment; we have another version of 
this on the linux-pm list now that is more generic [1]).

How readily can this be reproduced?  Can you try to reproduce once more?
Can this reproduce on an unpatched kernel?

To confirm if "PCI: Explicitly put devices into D0 when initializing" is 
the cause can you compare the PCI state of all devices from sysfs with 
and without the patch in place after bootup?  Basically run this in 
patched kernel and unpatched kernel and let's compare.

$ grep -v foo /sys/bus/pci/devices/*/power_state


[1] 
https://lore.kernel.org/linux-pm/20250512212628.2539193-1-superm1@kernel.org/T/#u