Created attachment 118407 [details] trinity_wakeup.log Dear Devs, ive got this really annoying issue with multiple boards: - ASRock FM2A75 Pro4 - ASRock A88M-HD+ - ASUS A78M-E The simptome is the same in every board, but just with A8-7800K Trinity(ARUBA). I've also tested with A10-7700K Kaveri(GCN1.1), but there was no problems at all. So I put the PC to S3 sleep, than wake it up. The monitor which uses DVI connector, works perfectly, but the HDMI one is mostly black,stays at sleep, doesnt displays information(out of range, etc), but sometimes a really flickering screen comes in for a few momements than disappears. I hope its still a non-listed bug, I've checked multiple reports, but doesnt find thisone. Look at the attachments, dmesg log added. Thanks
Please attach your xorg log and dmesg output.
Created attachment 118413 [details] dmesg.full
Created attachment 118414 [details] dmesg
Created attachment 118415 [details] xorg.0.log
I've updated the post.
Update: The same behavior, if the first monitor connected to Displayport(+HDMI adapter). Partedmagic dmesg and Xorg also added.
Created attachment 118727 [details] pmagic.dmesg
Created attachment 118728 [details] pmagic.xorg
Dear Alex, i'm having also a video. Should i upload it, or are the dmesg and xorg logs enough?
The logs are enough.
update: the same behavior if i connect the hdmi cable after boot.
Created attachment 119409 [details] dmesg_afterboot
Created attachment 119410 [details] xorg_afterboot
Seems like the bug is only exist when i manually take the computer to S3. After delayed sleep, it wakes perfectly. Any ideas?
Dear Alex! I used a Llano based desktop in the past months, but now i switched back to Trinity. This issue is still exist, and really annoying. Do you have any idea to fix it? Thanks
Hi there! Seems like the bug is gone, I'm using Arch with 4.5.5-1-ck. Do you know about any kind of fix merged into mainline?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/645.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.