Got it. I suppose that explains why it was so unreliably reproducible.. In any case, the patch is holding strong still with plenty of activity since, so it's looking good. Thak you for all of this; very instructive. On Sat, Jan 06, 2018 at 08:55:00PM +0000, Chris Wilson wrote: > Quoting Alexandru Chirvasitu (2018-01-06 18:44:29) > > Thanks! > > > > It's also a mystery to me why I never had any crashes on any of the > > other systems running on this machine running the same (unpatched) > > kernels. > > > > I'm assuming the window manager might have something to do with it: > > all of the others are on i3 and the buggy one's openbox, so perhaps > > tiling vs. stacking makes a difference? > > It just takes the right pattern of activity. The logic upon retiring a > request does try to strip the fences from all the objects listening to > the fence, but we can only do that so long as all the fences on the > object have been signaled. So for starters, it needs an object being > used by multiple timelines (different processes and/or engines) and then > retirement has to be run at just the right frequency to not see all of > those fences not to be completed. (Even more for this failure, it must > have a retired exclusive/write fence paired with active shared/read > fences.) It is that timing issue that has made it so rare, it's a > pattern that we definitely do not expose in our testing. > -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
