Re: [Bug 221606] r8169: PCIe AER errors and recovery failure after recent driver changes

Re: [Bug 221606] r8169: PCIe AER errors and recovery failure after recent driver changes

[Heiner Kallweit]

On 03.06.2026 09:44, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=221606
> 
> --- Comment #2 from lasse@lgb.dk ---
> Commit 9ab94a32af704fa9c873094283ae8744a07baf25 (r8169: enable LTR support)
> seems to be the issue. Running the commit before this doesn't give me any AER
> errors and everything seems to behave normally.
> 
Bisecting the reported issue points to one of your commits.
Could you please check with the user?

RE: [Bug 221606] r8169: PCIe AER errors and recovery failure after recent driver changes

[Javen]

>On 03.06.2026 09:44, bugzilla-daemon@kernel.org wrote:
>> https://bugzilla.kernel.org/show_bug.cgi?id=221606
>>
>> --- Comment #2 from lasse@lgb.dk ---
>> Commit 9ab94a32af704fa9c873094283ae8744a07baf25 (r8169: enable LTR
>> support) seems to be the issue. Running the commit before this doesn't
>> give me any AER errors and everything seems to behave normally.
>>
>Bisecting the reported issue points to one of your commits.
>Could you please check with the user?

Hi, Heiner, Lasse

Thanks for reporting this issue.

Currently, we haven't received any similar reports from our customers, and I am unable to reproduce this AER error on my local test platforms.

Could you please provide some more detailed information? The full dmesg log will help me check the exact AER error messages and the boot context. Also the output of sudo lspci -vvv. I need this to check the exact platform information, PCIe topology, and the LTR/ASPM capabilities of both your Root Port and the Realtek NIC.

While reviewing the initialization flow, I noticed a potential logic contradiction. If rtl_aspm_is_safe(tp) returns false, the driver disables L1 at the PCIe core level, but tp->aspm_manageable might still be set to true. This could cause the driver to incorrectly enable ASPM/LTR in the MAC registers later, creating a hardware state mismatch (PCIe L1 disabled, but MAC LTR enabled) which usually leads to AER.

Could you please test if the following patch fixes the AER error on your side?

-	if (enable && tp->aspm_manageable) {
+	if (enable && tp->aspm_manageable && rtl_aspm_is_safe(tp)) {

Thanks,
BRs,
Javen

Re: [Bug 221606] r8169: PCIe AER errors and recovery failure after recent driver changes

[Heiner Kallweit]

On 04.06.2026 11:01, Javen wrote:
>> On 03.06.2026 09:44, bugzilla-daemon@kernel.org wrote:
>>> https://bugzilla.kernel.org/show_bug.cgi?id=221606
>>>
>>> --- Comment #2 from lasse@lgb.dk ---
>>> Commit 9ab94a32af704fa9c873094283ae8744a07baf25 (r8169: enable LTR
>>> support) seems to be the issue. Running the commit before this doesn't
>>> give me any AER errors and everything seems to behave normally.
>>>
>> Bisecting the reported issue points to one of your commits.
>> Could you please check with the user?
> 
> Hi, Heiner, Lasse
> 
> Thanks for reporting this issue.
> 
> Currently, we haven't received any similar reports from our customers, and I am unable to reproduce this AER error on my local test platforms.
> 
> Could you please provide some more detailed information? The full dmesg log will help me check the exact AER error messages and the boot context. Also the output of sudo lspci -vvv. I need this to check the exact platform information, PCIe topology, and the LTR/ASPM capabilities of both your Root Port and the Realtek NIC.
> 
> While reviewing the initialization flow, I noticed a potential logic contradiction. If rtl_aspm_is_safe(tp) returns false, the driver disables L1 at the PCIe core level, but tp->aspm_manageable might still be set to true. This could cause the driver to incorrectly enable ASPM/LTR in the MAC registers later, creating a hardware state mismatch (PCIe L1 disabled, but MAC LTR enabled) which usually leads to AER.

rtl_aspm_is_safe() just changes the default and doesn't disable L1 at driver load.
Note that even if L1 gets disabled at driver load, the user can still re-enable L1
using standard PCI sysfs attributes (w/o r8169 driver being notified).
Therefore driver must not make any assumption on state of L1.

The hardware state mismatch you mention should be prevented by the hardware itself.
PCI standard registers in the chip know whether L1 is enabled, and chip should
prevent any unsafe PCIe bus activity (independent of ASPM/LTR setting).

> 
> Could you please test if the following patch fixes the AER error on your side?
> 
> -	if (enable && tp->aspm_manageable) {
> +	if (enable && tp->aspm_manageable && rtl_aspm_is_safe(tp)) {
> 
> Thanks,
> BRs,
> Javen