Re: [Intel-gfx] [CI 10/21] drm/i915: Mark up all locked waiters

2016-09-23 Thread ch...@chris-wilson.co.uk 
On Thu, Sep 22, 2016 at 04:05:51PM -0300, Paulo Zanoni wrote:
> Em Qua, 2016-09-14 às 09:40 +0100, ch...@chris-wilson.co.uk escreveu:
> > On Tue, Sep 13, 2016 at 03:21:48PM +0300, Mika Kuoppala wrote:
> > > 
> > > Mika Kuoppala  writes:
> > > > 
> > > > "Zanoni, Paulo R"  writes:
> > > > > 
> > > > > > 
> > > > > > +#if IS_ENABLED(CONFIG_LOCKDEP)
> > > > > > +   GEM_BUG_ON(!!lockdep_is_held(>i915-
> > > > > > >drm.struct_mutex)
> > > > > > !=
> > > > > > +      !!(flags & I915_WAIT_LOCKED));
> > > > > > +#endif
> > > > > 
> > > > > I'm hitting this on my SKL. It usually happens right after the
> > > > > login,
> > > > > when I click the terminal icon on the toolbar in order to open
> > > > > it (on
> > > > > Cinnamon). When it doesn't happen at that time, I just open a
> > > > > browser
> > > > > and browse for like 30 seconds until it happens.
> > > > > 
> > > > > I did manual reverts of this series up to this patch and
> > > > > obviously the
> > > > > problem goes away (no more GEM_BUG_ON to hit). I didn't try to
> > > > > do a
> > > > > real bisect to check if this is the first bad commit or if it's
> > > > > something later on the series. It could even be an older
> > > > > problem that
> > > > > just got exposed by the new BUG(). I'm available to test
> > > > > patches, just
> > > > > send them to me.
> > > > 
> > > > No patches yet but there is a comment on 
> > > > intel_prepare_plane_fb() that says that it must be called with
> > > > mutex
> > > > held.
> > > > 
> > > > Quite likely the new GEM_BUG_ON catches this not being true.
> > > > 
> > > 
> > > As Chris pointed out in irc, its about the reverse. Waiting
> > > with mutex when you shouldn't.
> > 
> > Fwiw, the fix is now on the list.
> 
> Can you please tell us which patch it is? I see we still have this
> problem.

https://patchwork.freedesktop.org/series/12703/

Note that the problem is only shown when you enable the BUG_ON. The
impact otherwise is very low.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [CI 10/21] drm/i915: Mark up all locked waiters

2016-09-22 Thread Paulo Zanoni 
Em Qua, 2016-09-14 às 09:40 +0100, ch...@chris-wilson.co.uk escreveu:
> On Tue, Sep 13, 2016 at 03:21:48PM +0300, Mika Kuoppala wrote:
> > 
> > Mika Kuoppala  writes:
> > > 
> > > "Zanoni, Paulo R"  writes:
> > > > 
> > > > > 
> > > > > +#if IS_ENABLED(CONFIG_LOCKDEP)
> > > > > + GEM_BUG_ON(!!lockdep_is_held(>i915-
> > > > > >drm.struct_mutex)
> > > > > !=
> > > > > +    !!(flags & I915_WAIT_LOCKED));
> > > > > +#endif
> > > > 
> > > > I'm hitting this on my SKL. It usually happens right after the
> > > > login,
> > > > when I click the terminal icon on the toolbar in order to open
> > > > it (on
> > > > Cinnamon). When it doesn't happen at that time, I just open a
> > > > browser
> > > > and browse for like 30 seconds until it happens.
> > > > 
> > > > I did manual reverts of this series up to this patch and
> > > > obviously the
> > > > problem goes away (no more GEM_BUG_ON to hit). I didn't try to
> > > > do a
> > > > real bisect to check if this is the first bad commit or if it's
> > > > something later on the series. It could even be an older
> > > > problem that
> > > > just got exposed by the new BUG(). I'm available to test
> > > > patches, just
> > > > send them to me.
> > > 
> > > No patches yet but there is a comment on 
> > > intel_prepare_plane_fb() that says that it must be called with
> > > mutex
> > > held.
> > > 
> > > Quite likely the new GEM_BUG_ON catches this not being true.
> > > 
> > 
> > As Chris pointed out in irc, its about the reverse. Waiting
> > with mutex when you shouldn't.
> 
> Fwiw, the fix is now on the list.

Can you please tell us which patch it is? I see we still have this
problem.

Thanks,
Paulo

> -Chris
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [CI 10/21] drm/i915: Mark up all locked waiters

2016-09-14 Thread ch...@chris-wilson.co.uk 
On Tue, Sep 13, 2016 at 03:21:48PM +0300, Mika Kuoppala wrote:
> Mika Kuoppala  writes:
> > "Zanoni, Paulo R"  writes:
> >>> +#if IS_ENABLED(CONFIG_LOCKDEP)
> >>> + GEM_BUG_ON(!!lockdep_is_held(>i915->drm.struct_mutex)
> >>> !=
> >>> +    !!(flags & I915_WAIT_LOCKED));
> >>> +#endif
> >>
> >> I'm hitting this on my SKL. It usually happens right after the login,
> >> when I click the terminal icon on the toolbar in order to open it (on
> >> Cinnamon). When it doesn't happen at that time, I just open a browser
> >> and browse for like 30 seconds until it happens.
> >>
> >> I did manual reverts of this series up to this patch and obviously the
> >> problem goes away (no more GEM_BUG_ON to hit). I didn't try to do a
> >> real bisect to check if this is the first bad commit or if it's
> >> something later on the series. It could even be an older problem that
> >> just got exposed by the new BUG(). I'm available to test patches, just
> >> send them to me.
> >
> > No patches yet but there is a comment on 
> > intel_prepare_plane_fb() that says that it must be called with mutex
> > held.
> >
> > Quite likely the new GEM_BUG_ON catches this not being true.
> >
> 
> As Chris pointed out in irc, its about the reverse. Waiting
> with mutex when you shouldn't.

Fwiw, the fix is now on the list.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [CI 10/21] drm/i915: Mark up all locked waiters

2016-09-13 Thread Mika Kuoppala 
Mika Kuoppala  writes:

> "Zanoni, Paulo R"  writes:
>
>> Hi
>>
>> Em Sex, 2016-09-09 às 14:11 +0100, Chris Wilson escreveu:
>>> In the next patch we want to handle reset directly by a locked waiter
>>> in
>>> order to avoid issues with returning before the reset is handled. To
>>> handle the reset, we must first know whether we hold the
>>> struct_mutex.
>>> If we do not hold the struct_mtuex we can not perform the reset, but
>>> we do
>>> not block the reset worker either (and so we can just continue to
>>> wait for
>>> request completion) - otherwise we must relinquish the mutex.
>>> 
>>> Signed-off-by: Chris Wilson 
>>> Reviewed-by: Mika Kuoppala 
>>> ---
>>>  drivers/gpu/drm/i915/i915_debugfs.c  |  4 +++-
>>>  drivers/gpu/drm/i915/i915_gem.c  |  7 +--
>>>  drivers/gpu/drm/i915/i915_gem_evict.c|  8 ++--
>>>  drivers/gpu/drm/i915/i915_gem_gtt.c  |  2 +-
>>>  drivers/gpu/drm/i915/i915_gem_request.c  | 15 ---
>>>  drivers/gpu/drm/i915/i915_gem_request.h  | 11 ---
>>>  drivers/gpu/drm/i915/i915_gem_shrinker.c |  2 +-
>>>  drivers/gpu/drm/i915/intel_ringbuffer.c  |  3 ++-
>>>  8 files changed, 38 insertions(+), 14 deletions(-)
>>> 
>>> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
>>> b/drivers/gpu/drm/i915/i915_debugfs.c
>>> index 620e7daa133b..64702cc68e3a 100644
>>> --- a/drivers/gpu/drm/i915/i915_debugfs.c
>>> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
>>> @@ -4803,7 +4803,9 @@ i915_drop_caches_set(void *data, u64 val)
>>>     return ret;
>>>  
>>>     if (val & DROP_ACTIVE) {
>>> -   ret = i915_gem_wait_for_idle(dev_priv,
>>> I915_WAIT_INTERRUPTIBLE);
>>> +   ret = i915_gem_wait_for_idle(dev_priv,
>>> +    I915_WAIT_INTERRUPTIBLE
>>> |
>>> +    I915_WAIT_LOCKED);
>>>     if (ret)
>>>     goto unlock;
>>>     }
>>> diff --git a/drivers/gpu/drm/i915/i915_gem.c
>>> b/drivers/gpu/drm/i915/i915_gem.c
>>> index 4617250c3000..23069a2d2850 100644
>>> --- a/drivers/gpu/drm/i915/i915_gem.c
>>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>>> @@ -2802,7 +2802,8 @@ __i915_gem_object_sync(struct
>>> drm_i915_gem_request *to,
>>>  
>>>     if (!i915.semaphores) {
>>>     ret = i915_wait_request(from,
>>> -   from->i915-
>>> >mm.interruptible,
>>> +   from->i915->mm.interruptible 
>>> |
>>> +   I915_WAIT_LOCKED,
>>>     NULL,
>>>     NO_WAITBOOST);
>>>     if (ret)
>>> @@ -4304,7 +4305,9 @@ int i915_gem_suspend(struct drm_device *dev)
>>>     if (ret)
>>>     goto err;
>>>  
>>> -   ret = i915_gem_wait_for_idle(dev_priv,
>>> I915_WAIT_INTERRUPTIBLE);
>>> +   ret = i915_gem_wait_for_idle(dev_priv,
>>> +    I915_WAIT_INTERRUPTIBLE |
>>> +    I915_WAIT_LOCKED);
>>>     if (ret)
>>>     goto err;
>>>  
>>> diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
>>> b/drivers/gpu/drm/i915/i915_gem_evict.c
>>> index 103085246975..5b6f81c1dbca 100644
>>> --- a/drivers/gpu/drm/i915/i915_gem_evict.c
>>> +++ b/drivers/gpu/drm/i915/i915_gem_evict.c
>>> @@ -170,7 +170,9 @@ search_again:
>>>     if (ret)
>>>     return ret;
>>>  
>>> -   ret = i915_gem_wait_for_idle(dev_priv,
>>> I915_WAIT_INTERRUPTIBLE);
>>> +   ret = i915_gem_wait_for_idle(dev_priv,
>>> +    I915_WAIT_INTERRUPTIBLE |
>>> +    I915_WAIT_LOCKED);
>>>     if (ret)
>>>     return ret;
>>>  
>>> @@ -275,7 +277,9 @@ int i915_gem_evict_vm(struct i915_address_space
>>> *vm, bool do_idle)
>>>     return ret;
>>>     }
>>>  
>>> -   ret = i915_gem_wait_for_idle(dev_priv,
>>> I915_WAIT_INTERRUPTIBLE);
>>> +   ret = i915_gem_wait_for_idle(dev_priv,
>>> +    I915_WAIT_INTERRUPTIBLE
>>> |
>>> +    I915_WAIT_LOCKED);
>>>     if (ret)
>>>     return ret;
>>>  
>>> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
>>> b/drivers/gpu/drm/i915/i915_gem_gtt.c
>>> index 9bcac52b8268..f3c6876da521 100644
>>> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
>>> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
>>> @@ -2683,7 +2683,7 @@ void i915_gem_gtt_finish_object(struct
>>> drm_i915_gem_object *obj)
>>>     struct i915_ggtt *ggtt = _priv->ggtt;
>>>  
>>>     if (unlikely(ggtt->do_idle_maps)) {
>>> -   if (i915_gem_wait_for_idle(dev_priv, 0)) {
>>> +   if (i915_gem_wait_for_idle(dev_priv,
>>> I915_WAIT_LOCKED)) {
>>>     DRM_ERROR("Failed to wait for idle; VT'd may
>>> hang.\n");
>>>     /* Wait a bit, in hopes it avoids the hang
>>>

Re: [Intel-gfx] [CI 10/21] drm/i915: Mark up all locked waiters

2016-09-13 Thread Mika Kuoppala 
"Zanoni, Paulo R"  writes:

> Hi
>
> Em Sex, 2016-09-09 às 14:11 +0100, Chris Wilson escreveu:
>> In the next patch we want to handle reset directly by a locked waiter
>> in
>> order to avoid issues with returning before the reset is handled. To
>> handle the reset, we must first know whether we hold the
>> struct_mutex.
>> If we do not hold the struct_mtuex we can not perform the reset, but
>> we do
>> not block the reset worker either (and so we can just continue to
>> wait for
>> request completion) - otherwise we must relinquish the mutex.
>> 
>> Signed-off-by: Chris Wilson 
>> Reviewed-by: Mika Kuoppala 
>> ---
>>  drivers/gpu/drm/i915/i915_debugfs.c  |  4 +++-
>>  drivers/gpu/drm/i915/i915_gem.c  |  7 +--
>>  drivers/gpu/drm/i915/i915_gem_evict.c|  8 ++--
>>  drivers/gpu/drm/i915/i915_gem_gtt.c  |  2 +-
>>  drivers/gpu/drm/i915/i915_gem_request.c  | 15 ---
>>  drivers/gpu/drm/i915/i915_gem_request.h  | 11 ---
>>  drivers/gpu/drm/i915/i915_gem_shrinker.c |  2 +-
>>  drivers/gpu/drm/i915/intel_ringbuffer.c  |  3 ++-
>>  8 files changed, 38 insertions(+), 14 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
>> b/drivers/gpu/drm/i915/i915_debugfs.c
>> index 620e7daa133b..64702cc68e3a 100644
>> --- a/drivers/gpu/drm/i915/i915_debugfs.c
>> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
>> @@ -4803,7 +4803,9 @@ i915_drop_caches_set(void *data, u64 val)
>>  return ret;
>>  
>>  if (val & DROP_ACTIVE) {
>> -ret = i915_gem_wait_for_idle(dev_priv,
>> I915_WAIT_INTERRUPTIBLE);
>> +ret = i915_gem_wait_for_idle(dev_priv,
>> + I915_WAIT_INTERRUPTIBLE
>> |
>> + I915_WAIT_LOCKED);
>>  if (ret)
>>  goto unlock;
>>  }
>> diff --git a/drivers/gpu/drm/i915/i915_gem.c
>> b/drivers/gpu/drm/i915/i915_gem.c
>> index 4617250c3000..23069a2d2850 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.c
>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>> @@ -2802,7 +2802,8 @@ __i915_gem_object_sync(struct
>> drm_i915_gem_request *to,
>>  
>>  if (!i915.semaphores) {
>>  ret = i915_wait_request(from,
>> -from->i915-
>> >mm.interruptible,
>> +from->i915->mm.interruptible 
>> |
>> +I915_WAIT_LOCKED,
>>  NULL,
>>  NO_WAITBOOST);
>>  if (ret)
>> @@ -4304,7 +4305,9 @@ int i915_gem_suspend(struct drm_device *dev)
>>  if (ret)
>>  goto err;
>>  
>> -ret = i915_gem_wait_for_idle(dev_priv,
>> I915_WAIT_INTERRUPTIBLE);
>> +ret = i915_gem_wait_for_idle(dev_priv,
>> + I915_WAIT_INTERRUPTIBLE |
>> + I915_WAIT_LOCKED);
>>  if (ret)
>>  goto err;
>>  
>> diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
>> b/drivers/gpu/drm/i915/i915_gem_evict.c
>> index 103085246975..5b6f81c1dbca 100644
>> --- a/drivers/gpu/drm/i915/i915_gem_evict.c
>> +++ b/drivers/gpu/drm/i915/i915_gem_evict.c
>> @@ -170,7 +170,9 @@ search_again:
>>  if (ret)
>>  return ret;
>>  
>> -ret = i915_gem_wait_for_idle(dev_priv,
>> I915_WAIT_INTERRUPTIBLE);
>> +ret = i915_gem_wait_for_idle(dev_priv,
>> + I915_WAIT_INTERRUPTIBLE |
>> + I915_WAIT_LOCKED);
>>  if (ret)
>>  return ret;
>>  
>> @@ -275,7 +277,9 @@ int i915_gem_evict_vm(struct i915_address_space
>> *vm, bool do_idle)
>>  return ret;
>>  }
>>  
>> -ret = i915_gem_wait_for_idle(dev_priv,
>> I915_WAIT_INTERRUPTIBLE);
>> +ret = i915_gem_wait_for_idle(dev_priv,
>> + I915_WAIT_INTERRUPTIBLE
>> |
>> + I915_WAIT_LOCKED);
>>  if (ret)
>>  return ret;
>>  
>> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
>> b/drivers/gpu/drm/i915/i915_gem_gtt.c
>> index 9bcac52b8268..f3c6876da521 100644
>> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
>> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
>> @@ -2683,7 +2683,7 @@ void i915_gem_gtt_finish_object(struct
>> drm_i915_gem_object *obj)
>>  struct i915_ggtt *ggtt = _priv->ggtt;
>>  
>>  if (unlikely(ggtt->do_idle_maps)) {
>> -if (i915_gem_wait_for_idle(dev_priv, 0)) {
>> +if (i915_gem_wait_for_idle(dev_priv,
>> I915_WAIT_LOCKED)) {
>>  DRM_ERROR("Failed to wait for idle; VT'd may
>> hang.\n");
>>  /* Wait a bit, in hopes it avoids the hang
>> */
>>  udelay(10);
>> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
>>

Re: [Intel-gfx] [CI 10/21] drm/i915: Mark up all locked waiters

2016-09-12 Thread Zanoni, Paulo R 
Hi

Em Sex, 2016-09-09 às 14:11 +0100, Chris Wilson escreveu:
> In the next patch we want to handle reset directly by a locked waiter
> in
> order to avoid issues with returning before the reset is handled. To
> handle the reset, we must first know whether we hold the
> struct_mutex.
> If we do not hold the struct_mtuex we can not perform the reset, but
> we do
> not block the reset worker either (and so we can just continue to
> wait for
> request completion) - otherwise we must relinquish the mutex.
> 
> Signed-off-by: Chris Wilson 
> Reviewed-by: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c  |  4 +++-
>  drivers/gpu/drm/i915/i915_gem.c  |  7 +--
>  drivers/gpu/drm/i915/i915_gem_evict.c|  8 ++--
>  drivers/gpu/drm/i915/i915_gem_gtt.c  |  2 +-
>  drivers/gpu/drm/i915/i915_gem_request.c  | 15 ---
>  drivers/gpu/drm/i915/i915_gem_request.h  | 11 ---
>  drivers/gpu/drm/i915/i915_gem_shrinker.c |  2 +-
>  drivers/gpu/drm/i915/intel_ringbuffer.c  |  3 ++-
>  8 files changed, 38 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 620e7daa133b..64702cc68e3a 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4803,7 +4803,9 @@ i915_drop_caches_set(void *data, u64 val)
>   return ret;
>  
>   if (val & DROP_ACTIVE) {
> - ret = i915_gem_wait_for_idle(dev_priv,
> I915_WAIT_INTERRUPTIBLE);
> + ret = i915_gem_wait_for_idle(dev_priv,
> +  I915_WAIT_INTERRUPTIBLE
> |
> +  I915_WAIT_LOCKED);
>   if (ret)
>   goto unlock;
>   }
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c
> index 4617250c3000..23069a2d2850 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2802,7 +2802,8 @@ __i915_gem_object_sync(struct
> drm_i915_gem_request *to,
>  
>   if (!i915.semaphores) {
>   ret = i915_wait_request(from,
> - from->i915-
> >mm.interruptible,
> + from->i915->mm.interruptible 
> |
> + I915_WAIT_LOCKED,
>   NULL,
>   NO_WAITBOOST);
>   if (ret)
> @@ -4304,7 +4305,9 @@ int i915_gem_suspend(struct drm_device *dev)
>   if (ret)
>   goto err;
>  
> - ret = i915_gem_wait_for_idle(dev_priv,
> I915_WAIT_INTERRUPTIBLE);
> + ret = i915_gem_wait_for_idle(dev_priv,
> +  I915_WAIT_INTERRUPTIBLE |
> +  I915_WAIT_LOCKED);
>   if (ret)
>   goto err;
>  
> diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
> b/drivers/gpu/drm/i915/i915_gem_evict.c
> index 103085246975..5b6f81c1dbca 100644
> --- a/drivers/gpu/drm/i915/i915_gem_evict.c
> +++ b/drivers/gpu/drm/i915/i915_gem_evict.c
> @@ -170,7 +170,9 @@ search_again:
>   if (ret)
>   return ret;
>  
> - ret = i915_gem_wait_for_idle(dev_priv,
> I915_WAIT_INTERRUPTIBLE);
> + ret = i915_gem_wait_for_idle(dev_priv,
> +  I915_WAIT_INTERRUPTIBLE |
> +  I915_WAIT_LOCKED);
>   if (ret)
>   return ret;
>  
> @@ -275,7 +277,9 @@ int i915_gem_evict_vm(struct i915_address_space
> *vm, bool do_idle)
>   return ret;
>   }
>  
> - ret = i915_gem_wait_for_idle(dev_priv,
> I915_WAIT_INTERRUPTIBLE);
> + ret = i915_gem_wait_for_idle(dev_priv,
> +  I915_WAIT_INTERRUPTIBLE
> |
> +  I915_WAIT_LOCKED);
>   if (ret)
>   return ret;
>  
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 9bcac52b8268..f3c6876da521 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -2683,7 +2683,7 @@ void i915_gem_gtt_finish_object(struct
> drm_i915_gem_object *obj)
>   struct i915_ggtt *ggtt = _priv->ggtt;
>  
>   if (unlikely(ggtt->do_idle_maps)) {
> - if (i915_gem_wait_for_idle(dev_priv, 0)) {
> + if (i915_gem_wait_for_idle(dev_priv,
> I915_WAIT_LOCKED)) {
>   DRM_ERROR("Failed to wait for idle; VT'd may
> hang.\n");
>   /* Wait a bit, in hopes it avoids the hang
> */
>   udelay(10);
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
> b/drivers/gpu/drm/i915/i915_gem_request.c
> index f4c15f319d08..5f89801e6a16 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.c
> +++