Quoting Andi Shyti (2019-09-29 21:25:54) > Hi Chris, > > > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c > > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c > > @@ -1186,6 +1186,21 @@ static void execlists_submit_ports(struct intel_engine_cs *engine) > > /* we need to manually load the submit queue */ > > if (execlists->ctrl_reg) > > writel(EL_CTRL_LOAD, execlists->ctrl_reg); > > + > > + /* > > + * Now this is evil magic. > > + * > > + * Adding the same udelay() to process_csb before we clear > > + * execlists->pending (that is after we receive the HW ack for this > > + * submit and before we can submit again) does not relieve the symptoms > > + * (machine lockup). So is the active difference here the wait under > > + * the irq-off spinlock? That gives more credance to the theory that > > + * the issue is interrupt delivery. Also note that we still rely on > > + * disabling RPS, again that seems like an issue with simultaneous > > + * GT interrupts being delivered to the same CPU. > > + */ > > + if (IS_TIGERLAKE(engine->i915)) > > + udelay(250); > > you want a delay of 250us. Two questions: > > 1. why 250? Magic. Purely first random number. > 2. is there any good reason for using 'udelay' for sleeping 250us > (that is quite a long time) and not 'usleep'? We are inside interrupt context. That this trick worked much better inside interrupt context than out makes me suspect interrupt delivery so much more. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
