Hi Janusz, > When running on a Cherryview, or on a Broxton with VTD enabled, pinning of > a VMA to GGTT is now committed asynchronously. You could also mention previously discovered lockdep issues on those platforms. I think that would make it easier to link this commit to the previous one in this series, since there is no mention of Cherryview nor Broxton in the code.
> That may defer further > processing of resources that depend on that VMA. As a consequence, a 10ms > delay in a multithreaded migrate test case may occur too short and still > incomplete threads may be interrupted, and the test case may fail with > -ERESTARTSYS or -EINTR error code returned by any of those threads. > > Extend the delay to empiricaly determined 100ms on affected platforms. empiricaly -> empirically > > Signed-off-by: Janusz Krzysztofik <[email protected]> > --- > drivers/gpu/drm/i915/gt/selftest_migrate.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gt/selftest_migrate.c > b/drivers/gpu/drm/i915/gt/selftest_migrate.c > index 54bc447efce0b..cde755751a0ba 100644 > --- a/drivers/gpu/drm/i915/gt/selftest_migrate.c > +++ b/drivers/gpu/drm/i915/gt/selftest_migrate.c > @@ -710,7 +710,8 @@ static int threaded_migrate(struct intel_migrate *migrate, > thread[i].tsk = tsk; > } > > - msleep(10 * n_cpus); /* start all threads before we kthread_stop() */ > + /* start all threads before we kthread_stop() */ > + msleep((intel_vm_no_concurrent_access_wa(migrate->context->vm->i915) ? > 100 : 10) * n_cpus); Hmm, I wonder if having 100 ms delay for all platofms would noticeably affect our testing (to have more uniformity here), but on the other hand 10 ms was established here for a reason in the past, so it should be fine. > > for (i = 0; i < n_cpus; ++i) { > struct task_struct *tsk = thread[i].tsk; > -- > 2.51.0 > -- Best Regards, Krzysztof
