They are not lockups. X just freezes in GEM_WAIT. The only way to
reproduce it is to apply the patches, use the computer and wait. It
looks like a fence is not signalled and the process calling GEM_WAIT
is not woken up.
Marek
On Tue, Oct 15, 2013 at 11:11 AM, Christian König
wrote:
> Mhm hard to
Mhm hard to say what's going wrong this time, but we probably need to
fix it before the final release.
Do you have a kernel backtrace from the lockups? Or at least some way to
reproduce it?
Christian.
Am 14.10.2013 21:34, schrieb Marek Olšák:
Ooops, the new problem is not so rare. It has no
Ooops, the new problem is not so rare. It has now happened to me 3
times in an hour.
Marek
On Mon, Oct 14, 2013 at 9:13 PM, Marek Olšák wrote:
> I tested this and had over 1546 lockups followed by a successful GPU
> reset. Then the kernel probably crashed (judging by the fact ssh was
> dead). St
I tested this and had over 1546 lockups followed by a successful GPU
reset. Then the kernel probably crashed (judging by the fact ssh was
dead). Still, it's pretty impressive.
There is a new problem though. The X server sometimes gets stuck in
GEM_WAIT and waits forever, even if there were no lock
On Mon, Oct 14, 2013 at 5:32 AM, Christian König
wrote:
> From: Christian König
>
> Stop leaking IB memory and scratch register space when the test fails.
>
> Signed-off-by: Christian König
Both patches applied.
Thanks!
Alex
> ---
> drivers/gpu/drm/radeon/cik.c | 3 +++
> 1 file changed, 3
