On 22/01/16 13:34, Chris Wilson wrote:
On Fri, Jan 22, 2016 at 01:17:44PM +0000, Tvrtko Ursulin wrote:
On 22/01/16 13:01, Chris Wilson wrote:
On Fri, Jan 22, 2016 at 12:19:32PM +0000, Dave Gordon wrote:
In the error-handling paths of i915_gem_do_execbuffer() and
intel_crtc_page_flip(), the local pointer-to-request variables
were expected to be either valid pointers or NULL. Since
2682708 drm/i915: simplify allocation of driver-internal requests
they could also be ERR_PTR() values, so the tests need to be
updated to accommodate this case.
Signed-off-by: Dave Gordon <david.s.gordon@xxxxxxxxx>
Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
Quick quiz, name at least testcase that exercised this code?
gem_close_race did it for me, but can you explain the weird ERR_PTR
of *ffca ? :)
-54
That's odd. gem_close_race should be a mix of ENOENT, EINVAL iirc.
-Chris
Assuming that's the fault address, it will actually be the sum of the
errno mistakenly passed to i915_gem_request_cancel(), plus the offset of
'ringbuf' in the drm_i915_gem_request structure:
void i915_gem_request_cancel(struct drm_i915_gem_request *req)
{
intel_ring_reserved_space_cancel(req->ringbuf);
i915_gem_request_unreference(req);
}
As it happens, 'ringbuf' is at offset 0x38 (56), so the errno was -2,
which is the expected error -ENOENT :)
.Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
