| Message ID | 20150721140312.GN16722@phenom.ffwll.local (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 21.07.2015 16:03, Daniel Vetter wrote: > On Tue, Jul 21, 2015 at 02:48:21PM +0200, Krzysztof Kolasa wrote: >> On 21.07.2015 11:43, Chris Wilson wrote: >>> On Tue, Jul 21, 2015 at 11:07:20AM +0200, Daniel Vetter wrote: >>>> On Tue, Jul 21, 2015 at 10:58:50AM +0200, Krzysztof Kolasa wrote: >>>>> On 21.07.2015 10:41, Daniel Vetter wrote: >>>>>> I meant whether you can reset the bad commit and it's immediate parent >>>>>> extensively to make sure the bisect is really correct. gpu's occasionally >>>>>> take a while to hang themselves, so could be that the bisect was >>>>>> mislead somewhere. >>>>> Again I will bisect, more testing good sections. >>>>> >>>>> At the moment on my old laptop, the latest official, properly working kernel is 4.1.2 >>>> You don't need to redo the full bisect, only retest the bad and the parent >>>> of the bad extensively. That's enough to confirm the bisect result for >>>> sure. >>> The bisection is misleading. It's a missing write-barrier. >>> -Chris >>> >> tested again: >> >> # good: [cd102a687beed1042824d5fa81c6ba8bfe78e6a4] drm/i915: Remove misleading comment around bind_to_vm >> git bisect good cd102a687beed1042824d5fa81c6ba8bfe78e6a4 >> # bad: [0875546c5318c85c13d07014af5350e9000bc9e9] drm/i915: Fix up the vma aliasing ppgtt binding >> git bisect bad 0875546c5318c85c13d07014af5350e9000bc9e9 >> # first bad commit: [0875546c5318c85c13d07014af5350e9000bc9e9] drm/i915: Fix up the vma aliasing ppgtt binding >> >> >> Screen does not lie :) first bad is BAD, good is GOOD >> >> on commit cd102a687beed10, computer worked steadily (with a large number of windows, applications) about an hour and stopped the tests, everything was OK >> >> on commit 0875546c5318c85, after about one minute, the screen gone mad > Suprising. Can you try out the below patch, it should disable the active > ingredient of the offending. On older kernels just remove the if > (bind_flags) before the call to ->bind_vma - the point is to call > ->bind_vma unconditionally. > -Daniel > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c > index cc133c700686..1227cd69c624 100644 > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c > @@ -2908,9 +2908,6 @@ int i915_vma_bind(struct i915_vma *vma, enum i915_cache_level cache_level, > else > bind_flags &= ~vma->bound; > > - if (bind_flags == 0) > - return 0; > - > if (vma->bound == 0 && vma->vm->allocate_va_range) { > trace_i915_va_alloc(vma->vm, > vma->node.start, I tested the patch and did not help ... Krzysztof
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index cc133c700686..1227cd69c624 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -2908,9 +2908,6 @@ int i915_vma_bind(struct i915_vma *vma, enum i915_cache_level cache_level, else bind_flags &= ~vma->bound; - if (bind_flags == 0) - return 0; - if (vma->bound == 0 && vma->vm->allocate_va_range) { trace_i915_va_alloc(vma->vm, vma->node.start,