On 11/11/2015 01:07 AM, Chris Wilson wrote:
On Tue, Nov 10, 2015 at 03:27:36PM -0800, yu.dai@xxxxxxxxx wrote:
> From: Alex Dai <yu.dai@xxxxxxxxx>
>
> We keep a copy of GuC fw in a GEM obj. However its content is lost
> if the GEM obj is swapped (igt/gem_evict_*). Therefore, the later
> fw loading during GPU reset will fail. Mark the obj dirty after
> copying data into the pages. So its content will be kept during
> swapped out.
>
> Signed-off-by: Alex Dai <yu.dai@xxxxxxxxx>
> ---
> drivers/gpu/drm/i915/i915_gem.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index f1e3fde..3b15167 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -5199,6 +5199,7 @@ i915_gem_object_create_from_data(struct drm_device *dev,
> i915_gem_object_pin_pages(obj);
> sg = obj->pages;
> bytes = sg_copy_from_buffer(sg->sgl, sg->nents, (void *)data, size);
> + obj->dirty = 1;
That's one way of doing it, but atypical for our CPU access to the pages.
The root cause is still that sg_copy_from_buffer() isn't calling
set_page_dirty() and so there will be other places in the kernel that
fall foul of it. Also, not that we could have written this to not require
the whole object to be pinned at once as well.
I would prefer this to be fixed in sg_copy_from_buffer() for the reason
that all callers are susceptible to this bug.
-Chris
Makes sense. I will keep this as it for now. We want to set this GEM obj
dirty too in addition of marking each page dirty. A change in
sg_copy_buffer will have big impact on kernel though.
Thanks,
Alex
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
