Commen=
t # 50
on bug 78453<=
/a>
from Christian K=C3=B6nig
(In reply to comment #=
47)
> When using the radeon.lockup_timeout=3D0 eglinfo=
(and every other egl apps)
> never finishes, probably waiting for a fence, but I still can switch t=
ty.
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, t=
here
> is probably others issues introduced after hawaii commit as suggested)=
That's why I suggested to work over the network, trying to debug gfx hardwa=
re
while the hardware is in use (e.g. it's your output device for debug messag=
es)
is usually pointless.
> The radeon_fence_info are the same between sever=
al 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=3D3 on the kernel command li=
ne
(keep in mind that this can take a while and will probably crash as well).<=
/pre>