Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> writes: > Quoting Mika Kuoppala (2018-06-05 19:03:57) >> There is a problem with kbl up to rev E0 where a heavy >> memory/fabric traffic from adjacent engine(s) can cause an engine >> reset to fail. This traffic can be from normal memory accesses >> or it can be from heavy polling on a semaphore wait. >> >> For engine hogging causing a fail, we already fallback to >> full reset. Which effectively stops all engines and thus >> we only add a workaround documentation. >> >> For the semaphore wait loop poll case, we add one microsecond >> poll interval to semaphore wait to guarantee bandwidth for >> the reset preration. The side effect is that we make semaphore >> completion latencies also 1us longer. >> >> v2: Let full reset handle the adjacent engine idling (Chris) >> >> References: https://bugs.freedesktop.org/show_bug.cgi?id=106684 >> References: VTHSD#2227190, HSDES#1604216706, BSID#0917 >> Signed-off-by: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx> > > Skip the RCS engine and this is; > > Reviewed-by: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> RCS engine skipped on v2, and both patches pushed. Thank you both for review. -Mika _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
