On Wed, Jan 18, 2017 at 09:36:55AM -0800, David Daney wrote: > On 01/18/2017 06:22 AM, Bjorn Helgaas wrote: > The tricky thing here is assigning the blame for failure in link training. > In the case in question we spent many months analysing the analog properties > of the bus and examining/decoding analog scope captures of the failures > before credibly assigning blame to the other guy. Usually what happens is > the device vendor accurately claims that their device works flawlessly in > conjunction with certain Intel root ports, so the problem must be fixed in > the root port of the failing system. If you have a black list, you may be > disabling ASPM in systems where it can work without failures. So what we need is not a table of just devices, but a combination of devices... iow, "when root A and endpoint B are combined, retrains need to be avoided." -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
