[Bug 110822] [Bisected]Booting with kernel version 5.1.0 or higher on RX 580 hangs

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=110822

--- Comment #20 from Gobinda Joy <gobinda.joy at 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20190613/b2c555be/attachment.html>