Re: interference on display, Intel 945GM, 32bit system, kernel next

Krzysztof Kolasa
2015-07-21T18:07:53Z

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