Re: Cache coherency issues when reading from intel Xe buffer.

["Thomas Hellström" <thomas.hellstrom@linux.intel.com>]

Hi, Jakub.

On Thu, 2025-11-13 at 12:31 +0000, Jakub Prussak wrote:
> Hello
> 
> Thank you for looking at it.
> 
> Regarding reproduction without an out-of-tree modules: the UDL module
> is producing the same artifacts.
> 
> I had a glance at the github issue. First, "new Intel devices" is
> quite
> vague. Which devices exactly?
> Devices from Metor Lake and Arrow Lake family so far. From what we
> gathered from users this includes, but is not limited to:
> 
>   *
> Intel(R) Core(TM) Ultra 9 275HX
>   *
> Intel(R) Core(TM) Ultra 7 265HX
>   *
> Intel(R) Core(TM) Ultra 5 235H
>   *
> Intel(R) Core(TM) Ultra 7 155H
>   *
> Intel(R) Core(TM) Ultra 7 265K
> 
> The problem occurs only on new hardwre, regardless of the kernel or
> our software version. When using any older processor with the same
> combination of kernel version with our product/UDL, everything
> behaves fine.

The i915 and xe driver have different approaches to ensuring coherency
on integrated devices. While the xe driver does not officially support
integrated HW prior to LNL, you could experiment to provide an
additional data point by switching a Meteor Lake device over to the xe
driver using the method described here:

https://www.phoronix.com/review/intel-i915-xe-linux-2025

If that gets rid of the issue we're in a better position to find
the culprit if it's on our side.

Thanks,
Thomas

> 
> In the attached output of lspci one can see that the driver being
> used by kernel is actually i915, but the xe module is also loaded.
> That's why we initially connected that to the xe module.
> Second, seems to me there are a lot of people having issues with
> non-Intel GPUs as well. What makes you say this is related to i915 or
> xe
> drivers?
> While the similar kind of artifacts show under non-Intel GPUs, they
> only appear with the EVDI and are not reproducible under the UDL
> module. Also the time it takes to heal and the way the artifacts heal
> on AMD devices makes us think that this is a different type of issue.
> We will be looking at that, but maybe you have any suggestions what
> to look for?
> 
> Regards
> Jakub Prussak
> ________________________________
> From: Jani Nikula <jani.nikula@linux.intel.com>
> Sent: Monday, November 10, 2025 5:48 PM
> To: Jakub Prussak <Jakub.Prussak@synaptics.com>;
> intel-xe@lists.freedesktop.org <intel-xe@lists.freedesktop.org>
> Cc: PPD-Penguins <ppdpenguins@synaptics.com>; Lucas De Marchi
> <lucas.demarchi@intel.com>; Thomas Hellström
> <thomas.hellstrom@linux.intel.com>; Rodrigo Vivi
> <rodrigo.vivi@intel.com>; Dave Airlie <airlied@redhat.com>;
> intel-gfx@lists.freedesktop.org <intel-gfx@lists.freedesktop.org>
> Subject: Re: Cache coherency issues when reading from intel Xe
> buffer.
> 
> CAUTION: Email originated externally, do not click links or open
> attachments unless you recognize the sender and know the content is
> safe.
> 
> 
> On Thu, 06 Nov 2025, Jakub Prussak <Jakub.Prussak@synaptics.com>
> wrote:
> > Hello,
> > 
> > For some time, users of DisplayLink USB-3 docking stations face
> > corruptions Ubuntu 24.04 on machines with Intel i915+Xe driver
> > (LENOVO
> > IdeaPad Pro 5 16IMH9 in our case)
> > Machines using only i915 driver are fine.
> 
> AFAICT all IdeaPad Pro 5 16IMH9 models have Meteorlake GPU, and you
> should be using i915 driver with that. The attached dmesg only
> appears
> to have the i915 driver anyway. So how's the xe driver related here?
> 
> > DisplayLink driver is using evdi kernel
> > module(
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Dis
> > playLink_evdi_blob_main_module&d=DwIBAg&c=7dfBJ8cXbWjhc0BhImu8wVIoU
> > FmBzj1s88r8EGyM0UY&r=W1EIKVsQFqx7ACp4Hsw-
> > KtUjZ5imGzUfM_7UN6O5xwk&m=JT0pLpFmiVNTCKbUp1LFei6Pu_3fQPGwh9cESk1co
> > qXMJlS_-
> > DbXDzPYP1hsvJk3&s=Q2kIS6_ZrX18OfHOYKDy3U8IxEF4rEnwgyDofnw08uA&e= )
> > that
> > works as drm output slave. It is using drm_prime exported buffers
> > from
> > i915 driver.
> 
> Mmh, can you reproduce any of this running upstream kernels without
> out-of-tree modules? It's highly unlikely anyone from our side would
> start debugging scenarios with out-of-tree modules.
> 
> > We had checked a way evdi access dma-buf exported buffer, e.g. if
> > it
> > is reading it within
> > dma_buf_begin_cpu_access/dma_buf_end_cpu_access.
> > 
> > Also, we ruled out access to the buffer before all dma_fence's on
> > drm_plane are signaled.
> > Another approach was to wait on dma_resv resv object from
> > drm_gem_object's dma_buf_attachment, again with no luck.
> > The issue is reproducible with evdi's evdi_gem_object and generic
> > drm_gem_shmem_object implementations of drm_gem_object. Corruptions
> > are visible with all compositors - XServer, Gnome/mutter, weston.
> > Other kernel module facing this issue is udl.
> > Nothing was helpful and we suspect some cache coherency issues.
> > 
> > The problem can be reproduced on the latest kernel on computers
> > with
> > new Intel devices, and a lot of our users face this problem
> > (
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Disp
> > layLink_evdi_issues_524&d=DwIBAg&c=7dfBJ8cXbWjhc0BhImu8wVIoUFmBzj1s
> > 88r8EGyM0UY&r=W1EIKVsQFqx7ACp4Hsw-
> > KtUjZ5imGzUfM_7UN6O5xwk&m=JT0pLpFmiVNTCKbUp1LFei6Pu_3fQPGwh9cESk1co
> > qXMJlS_-DbXDzPYP1hsvJk3&s=LX8y3cnAkcCfx8N45KMlHkwI031dlPc-
> > cy472qvNfwg&e= ). The way to reproduce
> > it requires installing EVDI module
> > (
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Disp
> > layLink_evdi&d=DwIBAg&c=7dfBJ8cXbWjhc0BhImu8wVIoUFmBzj1s88r8EGyM0UY
> > &r=W1EIKVsQFqx7ACp4Hsw-
> > KtUjZ5imGzUfM_7UN6O5xwk&m=JT0pLpFmiVNTCKbUp1LFei6Pu_3fQPGwh9cESk1co
> > qXMJlS_-
> > DbXDzPYP1hsvJk3&s=Z3Egg6eKXYMKqHu0gc5dsxdjsQCiVGcgbBXYY2h4vUo&e= ),
> > loading it and creating a
> > virtual screen (this can be achieved with this sample app:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_jakub-2Dprussak-2Dsynaptics_evdipp&d=DwIBAg&c=7dfBJ8cXbWjhc0BhImu8wVIoUFmBzj1s88r8EGyM0UY&r=W1EIKVsQFqx7ACp4Hsw-KtUjZ5imGzUfM_7UN6O5xwk&m=JT0pLpFmiVNTCKbUp1LFei6Pu_3fQPGwh9cESk1coqXMJlS_-DbXDzPYP1hsvJk3&s=19SbXfvkmN-YvqQgJGrJbBi7L07V81Eaq7cIhLRkQaY&e=
> >  ). Once a virtual
> > screen is created, the artifacts should be visible while moving the
> > window around on that screen (see the attached picture or user
> > reports
> > mentioned earlier). Similar issue appears with devices using UDL
> > driver on Intel platform. Attached are device information files and
> > a
> > dmesg output when reproducing this issue.
> 
> I had a glance at the github issue. First, "new Intel devices" is
> quite
> vague. Which devices exactly? 'lspci -vnn -d :*:0300'. Also we can
> see
> both i915 and xe drivers in some lsmod listings, but there's no info
> which drivers are being used with which devices. That's not
> actionable.
> 
> Second, seems to me there are a lot of people having issues with
> non-Intel GPUs as well. What makes you say this is related to i915 or
> xe
> drivers?
> 
> 
> BR,
> Jani.
> 
> 
> --
> Jani Nikula, Intel