https://bugs.freedesktop.org/show_bug.cgi?id=81644
--- Comment #41 from jackdachef@gmail.com --- Created attachment 104076 --> https://bugs.freedesktop.org/attachment.cgi?id=104076&action=edit dmesg-output after 25 minute hardware-accelerated html5 video crash, no hardlock this time (Magic SYSRQ works), screen corruption (screen subdivided horizontally into ~18 parts)
kernel running with drm-next-3.17-rebased-on-fixes applied on top of 3.16-rc6
latest commit: author Christian König christian.koenig@amd.com 2014-07-28 11:30:12 (GMT) committer Alex Deucher alexander.deucher@amd.com 2014-08-04 21:45:53 (GMT) commit fa783807977da98da35590fd1d5efdfd4f33fd59 (patch) tree 0f1573ae770843228930a0f278a82eb5d482a4c5 parent 5fc6854683aad9ae8b711cbe0d824c11b4aad66c (diff) drm/radeon: allow userptr write access under certain conditions
several hours of pushing and trying to get X/system lockup with firefox (hardware acceleration enabled) and watching & opening up large jpg images - showed that at least that issue was resolved (Bug #81612 )
Then now proceeded to re-test HTML5 video with hardware acceleration (hardware acceleration disabled was seemingly stable so far)
the funny thing: each of the last 3 test attempts after pretty much exactly 25 minutes it tends to lock up X
reproducer: chromium 38.0.2107.3 (previous versions should also work), but this one has more options disabled which should rule out other crash/instability triggers,
youtube.com , keywords: movie trailers 2014
watching random movie trailers with preferrably 1080p (some only available in 720p)
result: screen content locks up, mouse still movable for a short time & sound continuing, the screen turning black - (box locking up/hardlock - this time *not*) - this time: (in total 2) attempts to salvage via Magic SYSRQ + k
screen flickers, another Magic SYSRQ + k
screen turns on again, mentioned screen corruption (screen subdivided horizontally into ~18 parts) with mostly white and green color in the shape of tiles
took a photo, if needed
so we got a *clear* improvement: the box does *not* hardlock anymore, Magic SYSRQ key works again and screen attempts to recover with Magic SYSRQ + k,
but it's not successful yet
hope the information of dmesg helps with further adding some ideas on how to solve this
added the following patchset (patches 2-7) on top of that kernel https://lkml.org/lkml/2014/8/3/120 ([PATCH 0/7] locking/rwsem: enable reader opt-spinning & writer respin ), not sure if that might increase stability
Cheers