Re: [PATCH] PCI: Always lift 2.5GT/s restriction in PCIe failed link retraining

[ALOK TIWARI <alok.a.tiwari@oracle.com>]

On 3/27/2026 1:22 AM, ALOK TIWARI wrote:
> 
> 
> On 2/27/2026 3:32 AM, Maciej W. Rozycki wrote:
>> On Tue, 24 Feb 2026, Matthew W Carlis wrote:
>>
>>>>   I argue that by applying this change the issues with NVMe hot-plug 
>>>> will
>>>> be sorted while keeping the configuration working that
>>>> pcie_failed_link_retrain() is needed for.  Win-win.
>>>
>>> I don't think that what you are saying is true there is invariably 
>>> going to be
>>> some other consequence of this change.. Its hard to believe there can 
>>> be any
>>> changes to the pci drivers that won't break something.
>>
>>   You're being sarcastic, aren't you?
>>
>>   While I sympathise with your feeling, may I pretty please ask you to at
>> the very least give my fix a try in your test environment?
>>
>>>>   I note that active links are unaffected, so to say it's meddling 
>>>> with the
>>>> link on every device is I think a bit of an overstatement, and 
>>>> reports of
>>>> issues are from a few people only...
>>>
>>> There is no discrimination about which device it can be invoked on..
>>> I'm looking at a fleet of millions of hot-plug'able devices.... I 
>>> don't really
>>> know if it matters how many people report an issue, I think what 
>>> probably
>>> matters is making the right change. Initially was there any other 
>>> reports
>>> of the quirk helping with other devices besides the delock 41433?
>>
>>   No reports that I know of.  Please bear in mind that the failure 
>> mode is
>> such that you need enough knowledge of PCIe internals and the spec to
>> actually realise there is periodic link training activity taking place.
>>
>>   In the absence of the quirk for the average user there's just no
>> communication, as with a dead downstream device (and the upstream device
>> is sound as anything else plugged in, including but not limited to NVMe
>> storage, works just fine).  In the presence of the quirk the downstream
>> device just works and I expect hardly anyone can be bothered to report
>> seeing "broken device, retraining non-functional downstream link at
>> 2.5GT/s" in the log.  It's only cases like yours that bring attention to
>> the message.
>>
>>>>   What outcome would you envisage had I taken the approach from this 
>>>> update
>>>> right away with the original change?  My only fault was I have no 
>>>> use(*)
>>>> for PCIe hot-plug and did not predict the impact there.
>>>
>>> What I'm seeing now is an overall confusion about whether a link 
>>> failed to train
>>> to gen 1 or was recovered by the quirk or recovered on its own etc... 
>>> In my systems
>>> I would prefer to NEVER invoke the quirk under any circumstances 
>>> because I expect
>>> my devices to work. With the quirk it becomes more unclear about what 
>>> the cause
>>> of a link issue might have been or whether it was even a real link 
>>> issue in the
>>> first place or some weird timing..
>>
>>   I can see your point.
>>
>>   However from your description I infer this is about a test 
>> environment, a
>> development lab so to speak.  And you are a highly skilled professional
>> who has access to measurement, test, and hardware debug equipment, and 
>> are
>> therefore able to figure out stuff.  Conversely, the vast majority of
>> Linux deployments is in the field, where no sophisticated equipment is
>> available and the operator, if any, may have basic technical skills only.
>>
>>   I have been taught that in the field it is more desirable for equipment
>> to operate according to expectations rather than to strictly follow the
>> relevant specifications and consequently fail operating.  And the quirk I
>> have come up with just follows this principle, letting unqualified people
>> use their equipment (this is similar to Postel's law if you know what I
>> mean).
>>
>>   I realise that in the lab you want strict compliance as this will 
>> verify
>> interoperation of the devices you design.
>>
>>   So I think we have conflicting objectives here and I can only offer a
>> sysfs setting that will switch between the modes according to the 
>> specific
>> user's needs, as the intent is not something the kernel can figure out by
>> itself.
>>
>>   Please mind however that throughout this week and the next I'm away on
>> holiday (a proper one, as in alpine skiing), so my availability to 
>> respond
>> or work on stuff is limited.  I'll appreciate if you give my fix a try
>> meanwhile.
>>
>>    Maciej
> 
>  From my perspective, the current patch looks like a positive step and 
> seems to address the NVMe hot-plug concerns without regressing the 
> original use case.
> 
> That said, I’d really appreciate input from other maintainers on whether 
> this approach strikes the right balance between field robustness,
> 
> Given the concerns around hot-plug behavior and diagnosability, do you 
> think reverting (or partially reverting)
> the behavioral impact of the original commit: "PCI: Work around PCIe 
> link training failures"
> 
> what is best way to conclude this issue?
> 
> Thanks,
> Alok
> 

Hi Matthew,

Given your earlier concerns, do you think the right direction would be 
to (logically or partially) revert commit a89c82249c37 ("PCI: Work 
around PCIe link training failures"), or would you suggest refining the 
current approach instead?

I’d appreciate your guidance on what you think is the best way to move 
this forward.


Thanks,
Alok