[Intel-gfx] [PATCH 1/1] drm/i915: Fix for nested_enable_signaling BUG_ON
John Harrison
John.C.Harrison at Intel.com
Tue Nov 28 15:38:28 UTC 2017
On 11/28/2017 1:40 AM, Chris Wilson wrote:
> Quoting John.C.Harrison at Intel.com (2017-11-28 09:10:59)
>> From: John Harrison <John.C.Harrison at Intel.com>
>>
>> The call to enable signaling was occuring after the request had been
>> sent to the GuC for execution on the hardware. That means that it is
>> possible for the request to actually complete before the code to
>> enable signaling has executed.
> No, it wasn't, unless you had modified the code. Note also we switched
> to a different scheme in upstream
> -Chris
It was as of:
commit d99c1a7aff71536e909f54709023dcc5d6b559c0
Author: Chris Wilson <chris at chris-wilson.co.uk>
Date: Thu Mar 16 12:56:18 2017 +0000
drm/i915/scheduler: emulate a scheduler for guc
The code introduced was:
+ ...
+ if (last && rq->ctx != last->ctx) {
+ ...
*+ nested_enable_signaling(last);**
* + port++;
+ }
+ ...
*+ i915_guc_submit(rq);**
*+ last = rq;
+ submit = true;
+ }
+ if (submit) {
+ i915_gem_request_assign(&port->request, last);
*+ nested_enable_signaling(last);**
*+ engine->execlist_first = rb;
+ }
+ ...
That quite definitely calls nested_enable_signaling() after calling
i915_guc_submit(). It is either called on the last request submitted for
a given context or on the last request submitted overall. But in either
case it is only called after the actual submission occurs.
Maybe that was not exactly 4.11, there might have been a few more recent
patches pulled in to this tree. It is definitely not latest upstream
though. And as I noted in the cover letter, moving to latest upstream is
not an option for them at this point.
John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20171128/7a6abe50/attachment.html>
More information about the Intel-gfx
mailing list