On Mon, 2025-10-13 at 20:19 +0300, Ville Syrjälä wrote: > On Mon, Oct 13, 2025 at 04:52:04PM +0300, Jani Nikula wrote: > > On Thu, 18 Sep 2025, Jani Nikula <[email protected]> wrote: > > > On Tue, 16 Sep 2025, Ville Syrjälä > > > <[email protected]> wrote: > > > > For now I'd be happy if someone just nukes that bogus page > > > > alignemnt > > > > of the stride on xe, allowing i915 and xe to use the same code > > > > here. > > > > > > I hope just [1] is enough for this. > > > > > > [1] > > > https://lore.kernel.org/r/7f4972104de8b179d5724ae83892ee294d3f3fd3.1758184771.git.jani.nik...@intel.com > > > > So that regressed [2]. (Bisected internally, unfortunately not > > reported > > on the gitlab issue.) Any ideas, before I go on and resurrect this > > patch > > adding different strides for i915 and xe? > > That bisect doesn't make any real sense to me unless there's an > existing > bug in the xe code where it fails to pin (and somehow the smaller > stride > alignment makes it fail) but it still reports success to the caller.
Checked out drm-tip at 9c80ebfdd8460e69b35f5382f3e93a2a33a64e4f. Using that hash + setup where seen earlier the issue is easily reproducing. Reverted patches from the set which Jani is referring. After reverting "[PATCH v2 01/10] drm/xe/fbdev: use the same 64-byte stride alignment as i915" issue is not reproducing anymore. I couldn't reproduce the issue using latest drm-tip but it is anyways sporadic. It is seen in our CI testing with recent drm-tip as well. BR, Jouni Högander > > Unfortunately that code in xe is completely illegible due the scoped > guard mess. So it's darn near impossible to see with a visual > inspection > where it might silently fail. I think someone will need to sprinkle > debugs all over that code to track what is happening to the pin > count. >
