[Bug 81644] Random crashes on RadeonSI with Chromium.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Comment # 41 on bug 81644 from
Created attachment 104076 [details]
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


You are receiving this mail because:
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux