<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - [HAWAII] Get acceleration working" href="https://bugs.freedesktop.org/show_bug.cgi?id=78453#c50">Comment # 50</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - [HAWAII] Get acceleration working" href="https://bugs.freedesktop.org/show_bug.cgi?id=78453">bug 78453</a> from <a class="email" href="mailto:deathsimple@vodafone.de" title="Christian König <deathsimple@vodafone.de>"> Christian König</a> <pre>(In reply to <a href="show_bug.cgi?id=78453#c47">comment #47</a>) > When using the radeon.lockup_timeout=0 eglinfo (and every other egl apps) > never finishes, probably waiting for a fence, but I still can switch tty. That was expected, it probably just waits forever for some results. > That's with kernel 3.12+ (otoh with 3.14.3 if I try to run a egl app, I have > garbage on display and my monitor shutdown, and is never brought up, there > is probably others issues introduced after hawaii commit as suggested) That's why I suggested to work over the network, trying to debug gfx hardware while the hardware is in use (e.g. it's your output device for debug messages) is usually pointless. > The radeon_fence_info are the same between several run. Yeah, and the values are pretty interesting: --- ring 0 --- Last signaled fence 0x0000000000000001 Last emitted 0x0000000000000002 ... Last sync to ring 3 0x0000000000000009 --- ring 3 --- Last signaled fence 0x0000000000000001 Last emitted 0x0000000000000009 Ring 0 is the 3D engine, ring 3 is the DMA engine. What we see here is that we submitted some commands to the DMA engine which then got stuck. The 3D engine is just waiting for the DMA to continue as well. Try to load the radeon module with radeon.test=3 on the kernel command line (keep in mind that this can take a while and will probably crash as well).</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>