https://bugs.freedesktop.org/show_bug.cgi?id=110822
--- Comment #20 from Gobinda Joy gobinda.joy@gmail.com --- (In reply to Alex Deucher from comment #19)
(In reply to Gobinda Joy from comment #18)
What I don't get is why they are using 2 calls to get the bandwidth reading. Since both function walking the PCIe tree what's the point. Also it seems like the call to pcie_bandwidth_available() function is casing the freeze/hangs in my system. So that's counts for something.
Can you try a drm-next kernel? This code was ultimately cleaned in this patch: https://cgit.freedesktop.org/drm/drm/commit/ ?id=dbaa922b5706b1aff4572c280e15bbea2d04afe6 I don't know why pcie_bandwidth_available() is causing problems for you, it's just standard PCIE stuff.
Yes, I have tried the drm-next kernel and also tried that patch with current 5.2.0-rc4 same result boot hang. But this time I couldn't even get any log.
As little as I understand this, the difference between these two functions seems one reads the link capability (PCI_EXP_LNKCAP) other one tries to read link status (PCI_EXP_LNKSTA) and causes problem.
It could be that older UEFI BIOS like mine doesn't initialize the device properly when the link status gets accessed because newer board doesn't have this problem.
Also it could be that my board has a PLEX chip between the CPU and PCIE slots and there is no direct CPU<->PCIE slots available.
The PLEX chip is used to provide 2 x16_gen3 PCIE slot and 2 x8_gen3 PCIE slot. If all four slot gets populated first 2 slot will be downgraded to x8_gen3 slots as the 3rd/4th slot shares the bandwidth.
If the older method working fine for the newer cards too is there a reason to use pcie_bandwidth_available() function at all.
I'm way out of my league here. So don't get offended, I'm just curious.