<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - Random radeonsi crashes"
href="https://bugs.freedesktop.org/show_bug.cgi?id=79980#c125">Comment # 125</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW --- - Random radeonsi crashes"
href="https://bugs.freedesktop.org/show_bug.cgi?id=79980">bug 79980</a>
from <span class="vcard"><a class="email" href="mailto:deathsimple@vodafone.de" title="Christian König <deathsimple@vodafone.de>"> <span class="fn">Christian König</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=79980#c124">comment #124</a>)
<span class="quote">> I can very quickly, almost deterministically, hang the GPU (radeonsi, Cape
> Verde) with the following command:
>
> > LIBGL_ALWAYS_SOFTWARE=1 mpv --fs --vo=opengl:sw /path/to/some_video
>
> this works on both 3.16.0 and 3.17rc3. Try seeking, it often happens
> directly after a seek. In most cases, the hang is unrecoverable and crashes
> the kernel after some "atombios stuck in a loop" messages. Very strange
> indeed, software rendered glxgears doesn't cause this.
>
> Can anyone verify? A somewhat reliable test case might be a good start to
> finally fixing this.</span >
Well this is interesting, so you're saying that using software rendering on the
client side can crash the GPU? That only leaves glamor and maybe the compositor
as the only one using the hardware driver.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>