Observation: ============ With Hawaii acceleration enabled (including drm) I just got a gpu reset that failed to recover. It happended when I closed a gwenview window after a few hours of use (window manager was cinnamon). After going black and switching off for a while, the screens (2x DVI and 1x HDMI) came back, but displayed only flickery noise (I could see where the mouse pointer would've been as a differently noisy rectangle, and could move it). I could still ssh into the machine and aquire dmesg and Xorg.0.log. Interesting messages from dmesg: [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting [drm:atom_execute_table_locked] *ERROR* atombios stuck executing C466 (len 254, WS 0, PS 4) @ 0xC490 [drm:atom_execute_table_locked] *ERROR* atombios stuck executing B9EC (len 145, WS 0, PS 8) @ 0xBA77 [drm:ci_dpm_enable] *ERROR* ci_start_dpm failed [drm:radeon_pm_resume_dpm] *ERROR* radeon: dpm resume failed Driver Stack Details: ===================== 1) Kernel: agd5f's drm-next-3.17-wip (2014-08-03), Hawaii accel enabled 2) libdrm: git (2014-08-03) 3) mesa: git (2014-08-03) 4) Xorg-server: 1.16.0 5) xf86-video-ati: git (2014-08-03 with patch to enable accel) 6) glamor: xorg-server integrated 1.0.0 7) llvm: 3.5svn (updated recently) 8) new radeon firmware files for hawaii accel Hardware Configuration: ===================== Graphics Card: Hawaii XT, Sapphire Radeon R9 290X Tri-X OC, 4GB GDDR5 Processor: Core i7-965 (LGA 1366) Mainboard: Asus P6T Deluxe RAM: 6GB
Created attachment 104027 [details] dmesg of gpu crash
Created attachment 104028 [details] Xorg.0.log of gpu crash
Does this also happen with the drm-next-3.17-rebased-on-fixes kernel branch? drm-next-3.17-wip is missing a few stability fixes compared to that.
(In reply to comment #3) > Does this also happen with the drm-next-3.17-rebased-on-fixes kernel branch? > drm-next-3.17-wip is missing a few stability fixes compared to that. Unfortunately I couldn't test with drm-next-3.17-rebased-on-fixes, because it has a bug somewhere in ata (null pointer dereference or some such thing) that prevents me from booting. Also I never reproduced the bug, it actually happened after I recompiled stuff (especially xf86-video-ati with the v3-patch for enabling hawaii accel available here: http://lists.x.org/archives/xorg-driver-ati/2014-August/026534.html ). I then couldn't get the setup where the crash happened back easily (acceleration stopped working). But I suspect it's a "random" bug that isn't really related to closing gwenview. I'm now on the brand-new current "drm-next-3.17" branch, which is based on 3.16.0 final and boots fine - and should also have all the fixes and patches (?). I'll monitor the situation for a while. Probably this bug can be disregarded unless I get more similar crashes with all the fixes applied and more information how to cause it. Sorry 'bout the noise, I though those dmesg-messages with exact atombios commands getting stuck would reveal an possibly easy-to-fix issue, but according to agd5f on irc they are only symptoms of the gpu not being able to resume correctly.
As I didn't run into this issue anymore, I'm finally closing this bug. Gwenview doesn't cause problems.
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.