Please boot with drm.deubug=0xe passed to the kernel cmdline and attach the resulting dmesg.

Also output from intel_watermark (from igt-gpu-tools) when the problem is visible could be helpful.

Created attachment 143239 [details]
dmesg drm.debug=0xe

Created attachment 143240 [details]
intel_watermark with issue

Created attachment 143241 [details]
intel_watermark without issue

(In reply to Ville Syrjala from comment #1)
> Please boot with drm.deubug=0xe passed to the kernel cmdline and attach the
> resulting dmesg.
> 
> Also output from intel_watermark (from igt-gpu-tools) when the problem is
> visible could be helpful.

Thanks. Please see the new information attached.

All the numbers look very much correct :/

Does the corruption go away if you start X (or whatever) that enables the hardware cursor? The watermark dumps at least seemed to be w/o the cursor.

I see the BIOS is pretty old. Can you try to update it?

Let's also try to figure out which watermark level is the problem.
Please do these tests with drm-tip because it might not work with an older kernel.

First let's rule out LP3:
# echo '12 4 16 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency
# echo '12 4 16 0' > /sys/kernel/debug/dri/0/i915_cur_wm_latency
$ xset dpms force off ; xset dpms force on
Still corrupted?

Then LP2:
# echo '12 4 0 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency
# echo '12 4 0 0' > /sys/kernel/debug/dri/0/i915_cur_wm_latency
$ xset dpms force off ; xset dpms force on
Still corrupted?

And finally LP1:
# echo '12 0 0 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency
# echo '12 0 0 0' > /sys/kernel/debug/dri/0/i915_cur_wm_latency
$ xset dpms force off ; xset dpms force on
Still corrupted?

(In reply to Ville Syrjala from comment #6)
> All the numbers look very much correct :/
> 
> Does the corruption go away if you start X (or whatever) that enables the
> hardware cursor? The watermark dumps at least seemed to be w/o the cursor.

The corruption is present since boot-time, and stays there when the X starts. Sometimes it disappears (e.g., in response to a window/desktop switch), but in a non-deterministic way and the corruption comes back later.

> I see the BIOS is pretty old. Can you try to update it?

I will try in the next days, but from a first look it seems all updates require Windows (which I've not on this system).

> Let's also try to figure out which watermark level is the problem.
> Please do these tests with drm-tip because it might not work with an older
> kernel.
> 
> First let's rule out LP3:
> # echo '12 4 16 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency
> # echo '12 4 16 0' > /sys/kernel/debug/dri/0/i915_cur_wm_latency
> $ xset dpms force off ; xset dpms force on
> Still corrupted?

Yes

> Then LP2:
> # echo '12 4 0 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency
> # echo '12 4 0 0' > /sys/kernel/debug/dri/0/i915_cur_wm_latency
> $ xset dpms force off ; xset dpms force on
> Still corrupted?

Yes

> And finally LP1:
> # echo '12 0 0 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency
> # echo '12 0 0 0' > /sys/kernel/debug/dri/0/i915_cur_wm_latency
> $ xset dpms force off ; xset dpms force on
> Still corrupted?

No, the corruption is gone. Switching windows, desktops, focus etc seems to work fine. And it doesn't re-appear after > 10 mins.

(In reply to Andrea from comment #7)
> (In reply to Ville Syrjala from comment #6)
> > All the numbers look very much correct :/
> > 
> > Does the corruption go away if you start X (or whatever) that enables the
> > hardware cursor? The watermark dumps at least seemed to be w/o the cursor.
> 
> The corruption is present since boot-time, and stays there when the X
> starts. Sometimes it disappears (e.g., in response to a window/desktop
> switch), but in a non-deterministic way and the corruption comes back later.
> 
> > I see the BIOS is pretty old. Can you try to update it?
> 
> I will try in the next days, but from a first look it seems all updates
> require Windows (which I've not on this system).

Dunno if this is the right one, but some T431s seems to have ISOs available for BIOS update:
https://download.lenovo.com/pccbbs/mobiles/ghuj20us.iso

> 
> > Let's also try to figure out which watermark level is the problem.
> > Please do these tests with drm-tip because it might not work with an older
> > kernel.
> > 
> > First let's rule out LP3:
> > # echo '12 4 16 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency
> > # echo '12 4 16 0' > /sys/kernel/debug/dri/0/i915_cur_wm_latency
> > $ xset dpms force off ; xset dpms force on
> > Still corrupted?
> 
> Yes
> 
> > Then LP2:
> > # echo '12 4 0 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency
> > # echo '12 4 0 0' > /sys/kernel/debug/dri/0/i915_cur_wm_latency
> > $ xset dpms force off ; xset dpms force on
> > Still corrupted?
> 
> Yes
> 
> > And finally LP1:
> > # echo '12 0 0 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency
> > # echo '12 0 0 0' > /sys/kernel/debug/dri/0/i915_cur_wm_latency
> > $ xset dpms force off ; xset dpms force on
> > Still corrupted?
> 
> No, the corruption is gone. Switching windows, desktops, focus etc seems to
> work fine. And it doesn't re-appear after > 10 mins.

Hmm. That machine seems very broken when even LP1 doesn't work.

(In reply to Ville Syrjala from comment #8)
> (In reply to Andrea from comment #7)
> > (In reply to Ville Syrjala from comment #6)
> > > All the numbers look very much correct :/
> > > 
> > > Does the corruption go away if you start X (or whatever) that enables the
> > > hardware cursor? The watermark dumps at least seemed to be w/o the cursor.
> > 
> > The corruption is present since boot-time, and stays there when the X
> > starts. Sometimes it disappears (e.g., in response to a window/desktop
> > switch), but in a non-deterministic way and the corruption comes back later.
> > 
> > > I see the BIOS is pretty old. Can you try to update it?
> > 
> > I will try in the next days, but from a first look it seems all updates
> > require Windows (which I've not on this system).
> 
> Dunno if this is the right one, but some T431s seems to have ISOs available
> for BIOS update:
> https://download.lenovo.com/pccbbs/mobiles/ghuj20us.iso
> 
> > 
> > > Let's also try to figure out which watermark level is the problem.
> > > Please do these tests with drm-tip because it might not work with an older
> > > kernel.
> > > 
> > > First let's rule out LP3:
> > > # echo '12 4 16 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency
> > > # echo '12 4 16 0' > /sys/kernel/debug/dri/0/i915_cur_wm_latency
> > > $ xset dpms force off ; xset dpms force on
> > > Still corrupted?
> > 
> > Yes
> > 
> > > Then LP2:
> > > # echo '12 4 0 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency
> > > # echo '12 4 0 0' > /sys/kernel/debug/dri/0/i915_cur_wm_latency
> > > $ xset dpms force off ; xset dpms force on
> > > Still corrupted?
> > 
> > Yes
> > 
> > > And finally LP1:
> > > # echo '12 0 0 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency
> > > # echo '12 0 0 0' > /sys/kernel/debug/dri/0/i915_cur_wm_latency
> > > $ xset dpms force off ; xset dpms force on
> > > Still corrupted?
> > 
> > No, the corruption is gone. Switching windows, desktops, focus etc seems to
> > work fine. And it doesn't re-appear after > 10 mins.
> 
> Hmm. That machine seems very broken when even LP1 doesn't work.

Umm, I guess there might be a misunderstanding: after setting LP1 with the values you suggested, the corruption is gone and everything seems to be OK as before the regression.

Anyway, I'll also try the BIOS update and post the results (thanks for the pointer, I'll check).

(In reply to Andrea from comment #9)
> (In reply to Ville Syrjala from comment #8)
> > (In reply to Andrea from comment #7)
> > > (In reply to Ville Syrjala from comment #6)
> > > > All the numbers look very much correct :/
...
> > > > And finally LP1:
> > > > # echo '12 0 0 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency
> > > > # echo '12 0 0 0' > /sys/kernel/debug/dri/0/i915_cur_wm_latency
> > > > $ xset dpms force off ; xset dpms force on
> > > > Still corrupted?
> > > 
> > > No, the corruption is gone. Switching windows, desktops, focus etc seems to
> > > work fine. And it doesn't re-appear after > 10 mins.
> > 
> > Hmm. That machine seems very broken when even LP1 doesn't work.
> 
> Umm, I guess there might be a misunderstanding: after setting LP1 with the
> values you suggested, the corruption is gone and everything seems to be OK
> as before the regression.
> 
> Anyway, I'll also try the BIOS update and post the results (thanks for the
> pointer, I'll check).

JFTR, I've updated to "DMI: LENOVO 20AA0016GE/20AA0016GE, BIOS GHET41WW (1.26 ) 11/21/2018", same results:
- the monitor starts corrupted
- setting echo '12 0 0 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency ... "fixes" the issue.

> 
> Hmm. That machine seems very broken when even LP1 doesn't work.

Ville, LP1 does work and no corruption noticed. How to proceed further?

Created attachment 143441 [details] [review]
[PATCH] drm/i915: Disable LP1+ watermarks on Lenovo Thinkpad T431s

This patch should disable LP1+ watermarks on the affected machine automagically. Please test and also attach the output of intel_watermarks when using the patch so that I can double check that everything looks correct.

(In reply to Ville Syrjala from comment #12)
> Created attachment 143441 [details] [review] [review]
> [PATCH] drm/i915: Disable LP1+ watermarks on Lenovo Thinkpad T431s
> 
> This patch should disable LP1+ watermarks on the affected machine
> automagically. Please test and also attach the output of intel_watermarks
> when using the patch so that I can double check that everything looks
> correct.

I checked out the last drm-tip to apply the patch, but drm-tip doesn't show the problem anymore.

The drm-tip I used:

commit 348fd7b7fa6584957fa6a5143058b3fbb319806b
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Mar 1 18:32:47 2019 +0000

    drm-tip: 2019y-03m-01d-18h-31m-34s UTC integration manifest

The commit that seems to fix the issue is:

"drm/i915/fbdev: Actually configure untiled displays"
d179b88deb3bf6fed4991a31fd6f0f2cad21fab5

Reverting it makes the problem appear again.

intel_watermark with d179b88deb3bf6fed4991a31fd6f0f2cad21fab5 (good):
    WM_PIPE_A = 0x000b0000
    WM_PIPE_B = 0x00000000
    WM_PIPE_C = 0x00000000
       WM_LP1 = 0x84301100
       WM_LP2 = 0x90303c00
       WM_LP3 = 0xa0406600
   WM_LP1_SPR = 0x00000000
   WM_LP2_SPR = 0x00000000
   WM_LP3_SPR = 0x00000000
      ARB_CTL = 0xd6663056
     ARB_CTL2 = 0x00000000
WM_PIPE_A: primary=11, cursor=0, sprite=0
WM_PIPE_B: primary=0, cursor=0, sprite=0
WM_PIPE_C: primary=0, cursor=0, sprite=0
WM_LP1: enabled, latency=4, fbc=3, primary=17, cursor=0, sprite=0
WM_LP2: enabled, latency=16, fbc=3, primary=60, cursor=0, sprite=0
WM_LP3: enabled, latency=32, fbc=4, primary=102, cursor=0, sprite=0
Primary A trickle feed = disabled
Sprite A trickle feed = enabled
Primary B trickle feed = disabled
Sprite B trickle feed = enabled
Primary C trickle feed = enabled
Sprite C trickle feed = enabled
DDB partitioning = 1/2
FBC watermark = enabled

intel_watermark without d179b88deb3bf6fed4991a31fd6f0f2cad21fab5 (bad):
    WM_PIPE_A = 0x000b0000
    WM_PIPE_B = 0x00000000
    WM_PIPE_C = 0x00000000
       WM_LP1 = 0x84301100
       WM_LP2 = 0x90303c00
       WM_LP3 = 0xa0406600
   WM_LP1_SPR = 0x00000000
   WM_LP2_SPR = 0x00000000
   WM_LP3_SPR = 0x00000000
      ARB_CTL = 0xd6663056
     ARB_CTL2 = 0x00000000
WM_PIPE_A: primary=11, cursor=0, sprite=0
WM_PIPE_B: primary=0, cursor=0, sprite=0
WM_PIPE_C: primary=0, cursor=0, sprite=0
WM_LP1: enabled, latency=4, fbc=3, primary=17, cursor=0, sprite=0
WM_LP2: enabled, latency=16, fbc=3, primary=60, cursor=0, sprite=0
WM_LP3: enabled, latency=32, fbc=4, primary=102, cursor=0, sprite=0
Primary A trickle feed = disabled
Sprite A trickle feed = enabled
Primary B trickle feed = disabled
Sprite B trickle feed = enabled
Primary C trickle feed = disabled
Sprite C trickle feed = enabled
DDB partitioning = 1/2
FBC watermark = enabled

Primary C trickle feed is different.

(In reply to Ville Syrjala from comment #12)
> Created attachment 143441 [details] [review] [review]
> [PATCH] drm/i915: Disable LP1+ watermarks on Lenovo Thinkpad T431s
> 
> This patch should disable LP1+ watermarks on the affected machine
> automagically. Please test and also attach the output of intel_watermarks
> when using the patch so that I can double check that everything looks
> correct.

More info: your patch applied on top of the reverted d179b88deb also fixes the issue.

> $ git log --oneline
> drm/i915: Disable LP1+ watermarks on Lenovo Thinkpad T431s
> Revert "drm/i915/fbdev: Actually configure untiled displays"

intel_watermarks: (good)
    WM_PIPE_A = 0x000b0000
    WM_PIPE_B = 0x00000000
    WM_PIPE_C = 0x00000000
       WM_LP1 = 0x00000000
       WM_LP2 = 0x00000000
       WM_LP3 = 0x00000000
   WM_LP1_SPR = 0x00000000
   WM_LP2_SPR = 0x00000000
   WM_LP3_SPR = 0x00000000
      ARB_CTL = 0xd6663056
     ARB_CTL2 = 0x00000000
WM_PIPE_A: primary=11, cursor=0, sprite=0
WM_PIPE_B: primary=0, cursor=0, sprite=0
WM_PIPE_C: primary=0, cursor=0, sprite=0
WM_LP1: disabled, latency=0, fbc=0, primary=0, cursor=0, sprite=0
WM_LP2: disabled, latency=0, fbc=0, primary=0, cursor=0, sprite=0
WM_LP3: disabled, latency=0, fbc=0, primary=0, cursor=0, sprite=0
Primary A trickle feed = disabled
Sprite A trickle feed = enabled
Primary B trickle feed = disabled
Sprite B trickle feed = enabled
Primary C trickle feed = disabled
Sprite C trickle feed = enabled
DDB partitioning = 1/2
FBC watermark = enabled

Marking as fixed based on Andrea's feedback that the issue no longer exists on drm-tip

In 5.0.11 linux-stable the issue appeared again since the commit that "fixed" it in 5.0.0-rc8 was reverted.

Setting echo '12 0 0 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency still "fixes" the issue.

The patch in https://bugs.freedesktop.org/attachment.cgi?id=143441 does not apply cleanly anymore.

The commit that reverted the "fix" is:
commit 3e869fd348565c3bab7a6c61cc4b66c3594e6db2
Author: Dave Airlie <airlied@redhat.com>
Date:   Wed Apr 24 10:47:56 2019 +1000

    Revert "drm/i915/fbdev: Actually configure untiled displays"
    
    commit 9fa246256e09dc30820524401cdbeeaadee94025 upstream.
    
    This reverts commit d179b88deb3bf6fed4991a31fd6f0f2cad21fab5.
    
    This commit is documented to break userspace X.org modesetting driver in certain configurations.
    
    The X.org modesetting userspace driver is broken. No fixes are available yet. In order for this patch to be applied it either needs a config option or a workaround developed.
    
    This has been reported a few times, saying it's a userspace problem is clearly against the regression rules.

This thing is super mysterious.

Please grab
intel_reg read 0x70080 0x71080 0x72080 0x70280 0x71280 0x72280
intel_reg dump
intel_watermark

before and after 
3e869fd34856 ("Revert "drm/i915/fbdev: Actually configure untiled displays"")

I see DMAR is also active. Try booting with 'intel_iommu=igfx_off' passed to the kernel cmdline to see if that has any effect.

Thanks for the help. Attached (2019-05-08*) the requested info before and after 3e869fd34856.
Also attached the same info if I do "echo '12 0 0 0' > /sys/kernel/debug/dri/0/i915_pri_wm_latency", and with igfx_off.

The issue disappears either:
1) before 3e869fd34856
2) with echo '12 ...'
3) by disabling DMA remapping (i.e., adding intel_iommu=igfx_off)

If it helps, the DMAR output extracted from dmesg:
[    0.002921] ACPI: DMAR 0x00000000DAFDB000 0000B8 (v01 INTEL  SNB      00000001 INTL 00000001)
[    0.243778] DMAR: Disable GFX device mapping
[    0.391075] DMAR: Host address width 36
[    0.391079] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.391089] DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap c0000020e60262 ecap f0101a
[    0.391093] DMAR: DRHD base: 0x000000fed91000 flags: 0x1
[    0.391099] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap c9008020660262 ecap f0105a
[    0.391103] DMAR: RMRR base: 0x000000da43c000 end: 0x000000da452fff
[    0.391106] DMAR: RMRR base: 0x000000db800000 end: 0x000000df9fffff
[    0.391116] DMAR: No ATSR found
[    0.391165] DMAR: dmar1: Using Queued invalidation
[    0.391178] DMAR: Setting RMRR:
[    0.391242] DMAR: Setting identity map for device 0000:00:14.0 [0xda43c000 - 0xda452fff]
[    0.391313] DMAR: Setting identity map for device 0000:00:1a.0 [0xda43c000 - 0xda452fff]
[    0.391403] DMAR: Setting identity map for device 0000:00:1d.0 [0xda43c000 - 0xda452fff]
[    0.391420] DMAR: Prepare 0-16MiB unity mapping for LPC
[    0.391477] DMAR: Setting identity map for device 0000:00:1f.0 [0x0 - 0xffffff]
[    0.391632] DMAR: Intel(R) Virtualization Technology for Directed I/O

And without igfx_off:
[    0.003155] ACPI: DMAR 0x00000000DAFDB000 0000B8 (v01 INTEL  SNB      00000001 INTL 00000001)
[    0.391918] DMAR: Host address width 36
[    0.391923] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[    0.391932] DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap c0000020e60262 ecap f0101a
[    0.391935] DMAR: DRHD base: 0x000000fed91000 flags: 0x1
[    0.391942] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap c9008020660262 ecap f0105a
[    0.391946] DMAR: RMRR base: 0x000000da43c000 end: 0x000000da452fff
[    0.391949] DMAR: RMRR base: 0x000000db800000 end: 0x000000df9fffff
[    0.391959] DMAR: No ATSR found
[    0.392008] DMAR: dmar0: Using Queued invalidation
[    0.392018] DMAR: dmar1: Using Queued invalidation
[    0.392255] DMAR: Setting RMRR:
[    0.392320] DMAR: Setting identity map for device 0000:00:02.0 [0xdb800000 - 0xdf9fffff]
[    0.392878] DMAR: Setting identity map for device 0000:00:14.0 [0xda43c000 - 0xda452fff]
[    0.392964] DMAR: Setting identity map for device 0000:00:1a.0 [0xda43c000 - 0xda452fff]
[    0.393031] DMAR: Setting identity map for device 0000:00:1d.0 [0xda43c000 - 0xda452fff]
[    0.393047] DMAR: Prepare 0-16MiB unity mapping for LPC
[    0.393103] DMAR: Setting identity map for device 0000:00:1f.0 [0x0 - 0xffffff]
[    0.393500] DMAR: Intel(R) Virtualization Technology for Directed I/O
[    0.415290] [drm] DMAR active, disabling use of stolen memory

Created attachment 144199 [details]
2019-05-08_after_3e869fd34856

Created attachment 144200 [details]
2019-05-08_after_3e869fd34856_igfx_off

Created attachment 144201 [details]
2019-05-08_revert_3e869fd34856

Created attachment 144202 [details]
2019-05-08_echo12

@Ville, what's the next step?

@Ville, how to proceed further with this issue?

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/216.