Re: [PATCH 1/2] drm/radeon/kms: fix indirect buffer management V2

[Ladislav K. <L....@sh...>]

On Mon, 15 Feb 2010 21:36:13 +0100, Jerome Glisse <jg...@re...>
wrote:
> There is 3 different distinct states for an indirect buffer (IB) :
>   1- free with no fence
>   2- free with a fence
>   3- non free (fence doesn't matter)
> Previous code mixed case 2 & 3 in a single one leading to possible
> catastrophique failure. This patch rework the handling and properly
> separate each case. So when you get ib we set the ib as non free and
> fence status doesn't matter. Fence become active (ie has a meaning
> for the ib code) once the ib is scheduled or free. This patch also
> get rid of the alloc bitmap as it was overkill, we know go through
> IB pool list like in a ring buffer as the oldest IB is the first
> one the will be free.
> 
> Fix :
> https://bugs.freedesktop.org/show_bug.cgi?id=26438
> and likely other bugs.
> 
> V2 remove the scheduled list, it's useless now, fix free ib scanning

Hi,

thank you very much for your fix. It seems I get no more hard lockups. But
I have quite a lot of radeon_fence_signaled warnings just after X start.
See attachment

I use kernel-2.6.git from Linus with merged drm-radeon-testing.
xf86-video-ati git and mesa git. Running KDE 4.4.0 on Gentoo with OpenGL
composting turned on.

What could be the issue?

Best regards,

-- 
Ladislav Kunc