Standby worked flawlessly on my BARTS (radeon/r600). With the TONGA (amdgpu/radeonsi) the system is not able to recover after the standby. Seems like a hard-lockup. I put my system into standby by doing: echo mem > /sys/power/state I tried both kernel 4.4-rc7 and the 4.5-drm-next branch.
Does it work any better with the latest code in: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.5-wip
(In reply to Alex Deucher from comment #1) > Does it work any better with the latest code in: > http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.5-wip Yes, there are improvements: When I go into standby in a virtual terminal it can recover, but still writing the following error to dmesg: kernel: PM: resume of devices complete after 6591.636 msecs kernel: Restarting tasks ... done. kernel: amdgpu 0000:01:00.0: GPU fault detected: 147 0x0f080008 kernel: amdgpu 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x001001E1 kernel: amdgpu 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x02000008 kernel: VM fault (0x08, vmid 1) at page 1049057, read from 'TC2' (0x54433200) (0) When I switch back to X11 the system locks up, but unlike before I still can execute SysRq. This is a major improvement to the drm-next-4.5 branch!
I tried standby again by accident and it seems to work just fine now. I am using drm-next on commit d8e0cae645504a787b05abfb91afee8cd7fa1701, kernel 4.4.0-rc6-gd8e0cae. Did my change some stuff on my bios by accident (IOMMU?) or did you fix it in the recent kernel?
This has been fixed in kernel 4.5-rc2.
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.