[PATCH] drm/ttm: fix delayed ttm_bo_cleanup_refs_and_unlock delayed handling

[Markus Trippelsdorf]

On 2013.01.17 at 13:28 -0500, Jerome Glisse wrote:
> On Thu, Jan 17, 2013 at 11:10 AM, Markus Trippelsdorf
> <markus at trippelsdorf.de> wrote:
> > On 2013.01.17 at 10:44 -0500, Jerome Glisse wrote:
> >> On Thu, Jan 17, 2013 at 3:46 AM, Markus Trippelsdorf
> >> <markus at trippelsdorf.de> wrote:
> >> > On 2013.01.16 at 19:18 -0500, Jerome Glisse wrote:
> >> >> On Wed, Jan 16, 2013 at 6:10 PM, Markus Trippelsdorf
> >> >> <markus at trippelsdorf.de> wrote:
> >> >> > On 2013.01.16 at 17:36 -0500, Alex Deucher wrote:
> >> >> >> On Tue, Jan 15, 2013 at 12:03 PM, Markus Trippelsdorf
> >> >> >> <markus at trippelsdorf.de> wrote:
> >> >> >> > On 2013.01.15 at 17:32 +0100, Markus Trippelsdorf wrote:
> >> >> >> >> On 2013.01.15 at 16:26 +0100, Michel Dänzer wrote:
> >> >> >> >> > On Die, 201301-15 at 16:23 +0100, Markus Trippelsdorf wrote:
> >> >> >> >> > > On 2013.01.15 at 15:43 +0100, Michel Dänzer wrote:
> >> >> >> >> > > > On Sam, 2013-01-05 at 11:41 +0100, Markus Trippelsdorf wrote:
> >> >> >> >> > > > > On 2012.12.20 at 14:58 +0100, Markus Trippelsdorf wrote:
> >> >> >> >> > > > > >
> >> >> >> >> > > > > > And just in case it got lost in the noise yesterday:
> >> >> >> >> > > > > > The image corruption is caused by Dave's commit:
> >> >> >> >> > > > > >
> >> >> >> >> > > > > > commit dd54fee7d440c4a9756cce2c24a50c15e4c17ccb
> >> >> >> >> > > > > > Author: Dave Airlie <airlied at redhat.com>
> >> >> >> >> > > > > > Date:   Fri Dec 14 21:04:46 2012 +1000
> >> >> >> >> > > > > >
> >> >> >> >> > > > > >     radeon: fix regression with eviction since evict caching changes
> >> >> >> >> > > > > >
> >> >> >> >> > > > > > Reverting it 'fixes' the issue.
> >> >> >> >> > > > >
> >> >> >> >> > > > > Ping.
> >> >> >> >> > > > > The issue still happens with todays Linus git tree.
> >> >> >> >> > > >
> >> >> >> >> > > > Does the corruption also occur with
> >> >> >> >> > > > dd54fee7d440c4a9756cce2c24a50c15e4c17ccb applied manually on top of
> >> >> >> >> > > > 0d0b3e7443bed6b49cb90fe7ddc4b5578a83a88d?
> >> >> >> >> > >
> >> >> >> >> > > No.
> >> >> >> >> >
> >> >> >> >> > So, can you bisect which change between those two actually introduced
> >> >> >> >> > the corruption?
> >> >> >> >
> >> >> >> > The real cause of the image corruption is:
> >> >> >> >
> >> >> >> > d025e9e2b890db679f1246037bf65bd4be512627 is the first bad commit
> >> >> >> > commit d025e9e2b890db679f1246037bf65bd4be512627
> >> >> >> > Author: Jerome Glisse <jglisse at redhat.com>
> >> >> >> > Date:   Thu Nov 29 10:35:41 2012 -0500
> >> >> >> >
> >> >> >> >     drm/radeon: do not move bo to different placement at each cs
> >> >> >> >
> >> >> >> >     The bo creation placement is where the bo will be. Instead of trying
> >> >> >> >     to move bo at each command stream let this work to another worker
> >> >> >> >     thread that will use more advance heuristic.
> >> >> >> >
> >> >> >> >     agd5f: remove leftover unused variable
> >> >> >> >
> >> >> >> >     Signed-off-by: Jerome Glisse <jglisse at redhat.com>
> >> >> >> >     Reviewed-by: Alex Deucher <alexander.deucher at amd.com>
> >> >> >> >
> >> >> >> > Reverting d025e9e2b890d on top of Linus' tree fixes the issue.
> >> >> >>
> >> >> >> Can you try this patch from Jerome:
> >> >> >> https://bugzilla.kernel.org/attachment.cgi?id=91421
> >> >> >
> >> >> > It fixes the corruption, but it degrades performance so much that it
> >> >> > takes several seconds to switch virtual desktops under xmonad. And
> >> >> > sometimes the website used for the scroll test is stuck for several
> >> >> > seconds and unscrollable during that time.
> >> >> >
> >> >> > --
> >> >> > Markus
> >> >>
> >> >> What about this patch instead :
> >> >> http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch
> >> >
> >> > This one doesn't work:
> >>
> >> Same address updated patch
> >>
> >> http://people.freedesktop.org/~glisse/0001-drm-radeon-exclude-system-placement-when-validating-.patch
> >
> > It still doesn't work unfortunately. Can you please just revert
> > d025e9e2b89 for now? Maybe it's better to wait for the next kernel
> > release for another solution.
> >
> > Jan 17 17:05:34 x4 kernel: radeon 0000:01:05.0: GPU lockup CP stall for more than 10000msec
> > Jan 17 17:05:34 x4 kernel: radeon 0000:01:05.0: GPU lockup (waiting for 0x000000000000022b last fence id 0x0000000000000224)
> > Jan 17 17:05:34 x4 kernel: [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
> > Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (7000064, 6, 4096, -12)
> > Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (7000064, 6, 4096, -12)
> > Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (7000064, 6, 4096, -12)
> > Jan 17 17:05:34 x4 kernel: radeon 0000:01:05.0: couldn't schedule ib
> > Jan 17 17:05:34 x4 kernel: [drm:radeon_cs_ib_chunk] *ERROR* Failed to schedule IB !
> > Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (7098368, 6, 4096, -12)
> > Jan 17 17:05:34 x4 kernel: [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (7278592, 2, 4096, -12)
> >
> > --
> > Markus
> 
> For 3.9 sake can you try if
> http://people.freedesktop.org/~glisse/0001-drm-radeon-keep-original-user-requested-placement-ar.patch
> 
> on top of revert d025e9e2b89 works

Yes, this combination works just fine.

-- 
Markus