There were some new commits pushed to fdo today, it seems that whatever the issue was, it's now fixed. No bisect needed after all. Thanks again! On Thu, Oct 6, 2016 at 10:38 AM, Jeremy Newton <alexjnewt at gmail.com> wrote: > Fair enough, I'll bisect and see what happens. > > Thanks for your help! > > On Thu, Oct 6, 2016 at 10:12 AM, StDenis, Tom <Tom.StDenis at amd.com> wrote: > >> Hi Jeremy, >> >> >> Nothing between the UVD PG patch and the tip of stg-4.7 seems to be that >> relevant to 480. >> >> >> If 8f877a8 is stable best you can do is bisect (shouldn't take long) with >> cold boots in between. I too run Fedora 24 + GNOME and have good >> performance with Carrizo, Stoney, FIJI and Tonga (with the 5dw patch >> reverted) on the tip of stg-4.7. I have yet to test a polaris asic >> though... >> >> >> Tom >> >> >> ------------------------------ >> *From:* Jeremy Newton <alexjnewt at gmail.com> >> *Sent:* Thursday, October 6, 2016 10:07 >> *To:* StDenis, Tom >> *Cc:* amd-gfx at lists.freedesktop.org >> *Subject:* Re: Issue with amd-staging-4.7 on rx480 >> >> I apologise if what I said was unclear. When I mean I reverted back to 8f877a8, >> I mean I did a hard reset to this commit, i.e. reverting all >> commits/changes after this one. Basically I reverted the following >> commits: e3bb40f, 32ba038, 6892173, 55a9ab5, 4760300, 8ee519 >> 6, 381c90a, 5ae6bd0, 9a846b4, 042f89f, and 78d1842. I just skimmed it >> last night, so I can't say for sure where the issue is, but I'm assuming >> it's one of the drm/amdgpu commits, i.e. excluding commits9a846b4, 042f89f, >> and 78d1842. >> >> I have only tested based on a snapshot at 8f877a8 and another snapshot >> at 78d1842. The latter caused the issue, while the former seems fine. I >> just discovered this last night, but I'll do some builds tonight to bisect >> the issue if need be. >> >> Commit 6691270 on the other hand doesn't appear cause my issues. And >> lastly, I rarely do warm boots on my machine, so all of my tests have been >> cold boots. >> >> Thanks, >> Jeremy >> >> On Thu, Oct 6, 2016 at 9:41 AM, StDenis, Tom <Tom.StDenis at amd.com> wrote: >> >>> If I read this correctly you reverted the commit which enables UVD PG on >>> Tonga? I can't see how that impacts Polaris at all. >>> >>> >>> If I had to guess it's a dGPU state issue. I've had on occasion to >>> resort to cold reboots to bisect the kernel because the GPU firmware can >>> get into states that aren't 100% resolved by a warm reboot. >>> >>> >>> There is a known bad commit which was reverted by Christian which I >>> guess isn't out on fdo yet. https://cgit.freedesktop.org/ >>> ~agd5f/linux/commit/?h=amd-staging-4.7&id=6691270952b6909218 >>> c520dcc71a342070c96874 that commit seems to break dGPU support. >>> >>> >>> Cheers, >>> >>> Tom >>> >>> >>> ------------------------------ >>> *From:* amd-gfx <amd-gfx-bounces at lists.freedesktop.org> on behalf of >>> Jeremy Newton <alexjnewt at gmail.com> >>> *Sent:* Wednesday, October 5, 2016 22:54 >>> *To:* amd-gfx at lists.freedesktop.org >>> *Subject:* Issue with amd-staging-4.7 on rx480 >>> >>> Hello, >>> >>> I'm currently regularly building and using the amd-staging-4.7 linux >>> branch, which can be found here: >>> >>> https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-4.7 >>> >>> It seems that one of the commits pushed on 2016-10-03 broke something, >>> and I just wanted to give the devs a heads up in case no one noticed. I'm >>> guessing it was caused by one of the commits in the range of e3bb40f all >>> the way up to 78d1842. >>> >>> I'm using an RX480, polaris10. The issue seems to have two symptoms: >>> - Plymouth (the boot splash screen) seems to get visually corrupted or >>> just blacked out. >>> - After login, the screen just remains black until I hard reset. >>> >>> Reverting back to 8f877a8 seems to fix it. I'm using Fedora 24 with >>> GNOME. As well, I haven't had time to bisect, but I can do so if desired. >>> >>> Thanks! >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20161006/67269a00/attachment.html>
