[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.2408071241160.61955@angie.orcam.me.uk>
Date: Wed, 7 Aug 2024 12:49:09 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Matthew W Carlis <mattc@...estorage.com>
cc: alex.williamson@...hat.com, Bjorn Helgaas <bhelgaas@...gle.com>,
"David S. Miller" <davem@...emloft.net>, david.abdurachmanov@...il.com,
edumazet@...gle.com, helgaas@...nel.org, kuba@...nel.org, leon@...nel.org,
linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
linux-rdma@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org, lukas@...ner.de,
mahesh@...ux.ibm.com, mika.westerberg@...ux.intel.com,
netdev@...r.kernel.org, npiggin@...il.com, oohall@...il.com,
pabeni@...hat.com, pali@...nel.org, saeedm@...dia.com, sr@...x.de,
Jim Wilson <wilson@...iptree.org>
Subject: Re: PCI: Work around PCIe link training failures
On Mon, 5 Aug 2024, Matthew W Carlis wrote:
> The most common place where we see our systems getting stuck at Gen1 is with
> device power cycling. If a device is powered on and then off quickly then the
> link will of course fail to train & the consequence here is that the port is
> forced to Gen1 forever. Does anybody know why the patch will only remove the
> forced Gen1 speed from the ASMedia device?
I know, as the author of the change.
The reason for this is safety: it's better to have a link run at 2.5GT/s
than not at all, and from the nature of the issue there is no guarantee
that if you remove the speed clamp, then the link won't go back into the
infinite retraining loop that the workaround is supposed to break.
I was only able to verify that the speed clamp is safe to lift with this
particular device, but if you hit the actual issue with any other device
and find that it is safe to remove the clamp as well, then you're welcome
to add it to the list too.
Maciej
Powered by blists - more mailing lists