public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Das, Nirmoy" <nirmoy.das@linux.intel.com>
To: Matthew Auld <matthew.auld@intel.com>,
	Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Do not set cache_dirty for DGFX
Date: Wed, 2 Nov 2022 17:09:27 +0100	[thread overview]
Message-ID: <160a4d6d-76e1-3dd0-16ba-5e3134409680@linux.intel.com> (raw)
In-Reply-To: <033cbf36-cfec-d5e4-ea2b-ee59595f3b89@intel.com>


On 11/2/2022 11:36 AM, Matthew Auld wrote:
> On 02/11/2022 07:39, Das, Nirmoy wrote:
>>
>> On 11/2/2022 6:14 AM, Niranjana Vishwanathapura wrote:
>>> Currently on DG1, which do not have LLC, we hit the below
>>> warning while rebinding an userptr invalidated object.
>>>
>>> WARNING: CPU: 4 PID: 13008 at 
>>> drivers/gpu/drm/i915/gem/i915_gem_pages.c:34 
>>> __i915_gem_object_set_pages+0x296/0x2d0 [i915]
>>> ...
>>> RIP: 0010:__i915_gem_object_set_pages+0x296/0x2d0 [i915]
>>> ...
>>> Call Trace:
>>>   <TASK>
>>>   i915_gem_userptr_get_pages+0x175/0x1a0 [i915]
>>>   ____i915_gem_object_get_pages+0x32/0xb0 [i915]
>>>   i915_gem_object_userptr_submit_init+0x286/0x470 [i915]
>>>   eb_lookup_vmas+0x2ff/0xcf0 [i915]
>>>   ? __intel_wakeref_get_first+0x55/0xb0 [i915]
>>>   i915_gem_do_execbuffer+0x785/0x21d0 [i915]
>>>   i915_gem_execbuffer2_ioctl+0xe7/0x3d0 [i915]
>>>
>>> We shouldn't be setting the obj->cache_dirty for DGFX,
>>> fix it.
>>
>> With Fixes: |d70af57944 |("drm/i915/shmem: ensure flush during 
>> swap-in on non-LLC")
>>
>> Acked-by: Nirmoy Das <nirmoy.das@intel.com>
>
> Any idea why this escaped our testing in CI? Perhaps something to 
> improve.


I ran some userptr related igt tests none hit 
__i915_gem_object_release_shmem . So I think we are missing

coverage here or I/CI isn't running such test.

Niranjana, what test did you ran to hit this case WARN ?


Regards,

Nirmoy


>
> Reviewed-by: Matthew Auld <matthew.auld@intel.com>
>
>>
>>> Suggested-by: Matthew Auld<matthew.auld@intel.com>
>>> Reported-by: Niranjana 
>>> Vishwanathapura<niranjana.vishwanathapura@intel.com>
>>> Signed-off-by: Niranjana 
>>> Vishwanathapura<niranjana.vishwanathapura@intel.com>
>>> ---
>>>   drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 4 ++--
>>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c 
>>> b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
>>> index 11125c32dd35..2f7804492cd5 100644
>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
>>> @@ -369,14 +369,14 @@ __i915_gem_object_release_shmem(struct 
>>> drm_i915_gem_object *obj,
>>>         __start_cpu_write(obj);
>>>       /*
>>> -     * On non-LLC platforms, force the flush-on-acquire if this is 
>>> ever
>>> +     * On non-LLC igfx platforms, force the flush-on-acquire if 
>>> this is ever
>>>        * swapped-in. Our async flush path is not trust worthy enough 
>>> yet(and
>>>        * happens in the wrong order), and with some tricks it's 
>>> conceivable
>>>        * for userspace to change the cache-level to I915_CACHE_NONE 
>>> after the
>>>        * pages are swapped-in, and since execbuf binds the object 
>>> before doing
>>>        * the async flush, we have a race window.
>>>        */
>>> -    if (!HAS_LLC(i915))
>>> +    if (!HAS_LLC(i915) && !IS_DGFX(i915))
>>>           obj->cache_dirty = true;
>>>   }

  reply	other threads:[~2022-11-02 16:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-02  5:14 [Intel-gfx] [PATCH] drm/i915: Do not set cache_dirty for DGFX Niranjana Vishwanathapura
2022-11-02  6:21 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for " Patchwork
2022-11-02  6:45 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-11-02  7:39 ` [Intel-gfx] [PATCH] " Das, Nirmoy
2022-11-02 10:36   ` Matthew Auld
2022-11-02 16:09     ` Das, Nirmoy [this message]
2022-11-02 16:35       ` Niranjana Vishwanathapura
2022-11-02 21:59 ` Andi Shyti
2022-11-02 22:31 ` Andi Shyti

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=160a4d6d-76e1-3dd0-16ba-5e3134409680@linux.intel.com \
    --to=nirmoy.das@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.auld@intel.com \
    --cc=niranjana.vishwanathapura@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox