Created attachment 142851 [details]
Dell Latitude E7470, "Skylake GT2 [HD Graphics 520]".
With kernels later than linux-4.4 (have not checked when it started), dmesg is flooded with messages like this:
[drm:gen8_irq_handler [i915]] *ERROR* Fault errors on pipe A: 0x00000080
# dmesg | grep -cw 0x00000080
This happens when the system is booted as Xen dom0. IMO everything is working fine, no issues to report beside the flooding of syslog. The used desktop environment makes no difference, nor makes the used version of SLE or Leap or Tumbleweed any difference.
The actual things I want to see fixed are:
What is bit (1 << 3)? There is no constant defined for this issue.
Why do DRM_ERROR() and related helpers not use printk_ratelimited()?
The use can not do anything about the issue anyway, other than reporting it, so a single message would be fine.
And if you feel like it: what needs to be done to get this driver fixed for a Xen dom0?
Created attachment 142852 [details]
Created attachment 142853 [details]
It is actually gen#9, I thouhht it is gen#8:
It seems GEN9_PIPE_PLANE1_FLIP_DONE is set. If that is the case, what does that mean?
Reporter, Can you reproduce the issue using drm-tip (https://cgit.freedesktop.org/drm-tip).
If problem exists with latest drm-tip, set kernel parameters drm.debug=0x1e log_buf_len=4M and reboot.
Latest kernel is 4.20.
Created attachment 142894 [details]
Created attachment 142895 [details]
not drm-tip.git, but close enough. With "log_buf_len=128M drm.debug=0x1e"
Created attachment 142923 [details]
same kernel, non-dom0
(In reply to olaf from comment #7)
> Created attachment 142923 [details]
> same kernel, non-dom0
Sorry for the delay, It would good to check if this error still appears on latest drmtip (https://cgit.freedesktop.org/drm-tip)..
Created attachment 143495 [details]
Was any work done to address the issue?
> Was any work done to address the issue?
Not that I am aware of. Anyway thanks for sending the latest dmesg, this might help in investigating the issue.
I don't see anything about vt-d in the boot log, but I'm tempted to blame it anyway.
You could try something like this:
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 453af7438e67..5b4cd1dfd787 100644
@@ -2593,6 +2593,7 @@ static inline unsigned int i915_sg_segment_size(void)
static inline bool intel_vtd_active(void)
+ return true;
Yes, enforcing "intel_iommu_gfx_mapped" helps.
Created attachment 143509 [details]
drm-tip: 2019y-02m-28d-23h-15m-49s UTC
(In reply to Ville Syrjala from comment #11)
> I don't see anything about vt-d in the boot log, but I'm tempted to blame it
> You could try something like this:
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> index 453af7438e67..5b4cd1dfd787 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2593,6 +2593,7 @@ static inline unsigned int i915_sg_segment_size(void)
> static inline bool intel_vtd_active(void)
> + return true;
> #ifdef CONFIG_INTEL_IOMMU
> if (intel_iommu_gfx_mapped)
> return true;
(In reply to olaf from comment #12)
> Yes, enforcing "intel_iommu_gfx_mapped" helps.
@Ville, what are the next steps here?