Bug 109477 - [regression, bisected] [i915] setting initial watermarks on gen 7 IVYBRIDGE causes blank lines on monitor
Summary: [regression, bisected] [i915] setting initial watermarks on gen 7 IVYBRIDGE c...
Status: REOPENED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: x86-64 (AMD64) Linux (All)
: high normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-28 13:04 UTC by Andrea
Modified: 2019-06-26 10:37 UTC (History)
2 users (show)

See Also:
i915 platform: IVB
i915 features: display/watermark


Attachments
output corruption (633.49 KB, image/jpeg)
2019-01-28 13:04 UTC, Andrea
no flags Details
dmesg drm.debug=0xe (129.41 KB, text/plain)
2019-01-28 17:59 UTC, Andrea
no flags Details
intel_watermark with issue (867 bytes, text/plain)
2019-01-28 17:59 UTC, Andrea
no flags Details
intel_watermark without issue (870 bytes, text/plain)
2019-01-28 18:00 UTC, Andrea
no flags Details
[PATCH] drm/i915: Disable LP1+ watermarks on Lenovo Thinkpad T431s (4.84 KB, patch)
2019-02-22 15:26 UTC, Ville Syrjala
no flags Details | Splinter Review
2019-05-08_after_3e869fd34856 (17.99 KB, text/plain)
2019-05-08 22:01 UTC, Andrea
no flags Details
2019-05-08_after_3e869fd34856_igfx_off (17.99 KB, text/plain)
2019-05-08 22:02 UTC, Andrea
no flags Details
2019-05-08_revert_3e869fd34856 (17.99 KB, text/plain)
2019-05-08 22:03 UTC, Andrea
no flags Details
2019-05-08_echo12 (17.89 KB, text/plain)
2019-05-08 22:03 UTC, Andrea
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrea 2019-01-28 13:04:22 UTC
Created attachment 143236 [details]
output corruption

I've seen a regression on linux-stable since this commit (merged on stable between 4.19.2 and 4.19.3)

# first bad commit: [a46a7350b1e85fe78580f6a4c809a876867a9df8] drm/i915: Fix ilk+ watermarks when disabling pipes

I've a gen 7:

Platform: IVYBRIDGE
PCI ID: 0x0166
PCI Revision: 0x09
PCI Subsystem: 17aa:2208

graphic card on a Lenovo T431s, which has "has_gmch_display: no", but apparently it doesn't fully support setting the initial_watermarks().

See screenshot for the output corruption. See git bisect log, and the lspci for the card.

Excluding the call to initial_watermarks() "fixes" the issue:

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 3bd44d042a1d..1c1b2ee556ef 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12639,12 +12639,14 @@ static void intel_atomic_commit_tail(struct drm_atomic_state *state)
                        intel_check_cpu_fifo_underruns(dev_priv);
                        intel_check_pch_fifo_underruns(dev_priv);
 
+#if 0
                        /* FIXME unify this for all platforms */
                        if (!new_crtc_state->active &&
                            !HAS_GMCH_DISPLAY(dev_priv) &&
                            dev_priv->display.initial_watermarks)
                                dev_priv->display.initial_watermarks(intel_state,
                                                                     to_intel_crtc_state(new_crtc_state));
+#endif
                }
        }

For completeness, I've tried the drm-tip:

commit bc2fcdf82a5b94f015126dfa9db03f88feb9ae17
Date:   Mon Jan 28 11:15:42 2019 +0100

but the issue is still present.


### git bisect log
git bisect start
# bad: [73aa1c86c6ec67931abf0c6b96b6853578b07db5] Linux 4.19.3
git bisect bad 73aa1c86c6ec67931abf0c6b96b6853578b07db5
# good: [7950eb316adf792283cac5743dfe5a11e74833dc] Linux 4.19.2
git bisect good 7950eb316adf792283cac5743dfe5a11e74833dc
# good: [67a19f87a02beec6a676ed427fbe3c1f5f00d9f4] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings
git bisect good 67a19f87a02beec6a676ed427fbe3c1f5f00d9f4
# good: [401182ae096bfb16693bcfb8fcab1bc128a5c6bc] kdb: print real address of pointers instead of hashed addresses
git bisect good 401182ae096bfb16693bcfb8fcab1bc128a5c6bc
# good: [3ff21b59ffd294c04fd83994e71417247f0d2ee7] drm/etnaviv: fix bogus fence complete check in timeout handler
git bisect good 3ff21b59ffd294c04fd83994e71417247f0d2ee7
# good: [1a25e1a1be71a49ee7f34fb14b5a26191e6cf501] drm/i915: Mark up GTT sizes as u64
git bisect good 1a25e1a1be71a49ee7f34fb14b5a26191e6cf501
# bad: [828271c43b7850748b3cd18e769367a244875acf] drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5
git bisect bad 828271c43b7850748b3cd18e769367a244875acf
# bad: [b4aa9db0b24f8504ee8e4de36bc84eae4f9fad63] drm/i915: Compare user's 64b GTT offset even on 32b
git bisect bad b4aa9db0b24f8504ee8e4de36bc84eae4f9fad63
# bad: [a46a7350b1e85fe78580f6a4c809a876867a9df8] drm/i915: Fix ilk+ watermarks when disabling pipes
git bisect bad a46a7350b1e85fe78580f6a4c809a876867a9df8
# good: [6d6e718e454b65448bbb50c876e5040f5d05db6d] drm/i915: Fix error handling for the NV12 fb dimensions check
git bisect good 6d6e718e454b65448bbb50c876e5040f5d05db6d
# first bad commit: [a46a7350b1e85fe78580f6a4c809a876867a9df8] drm/i915: Fix ilk+ watermarks when disabling pipes

### lspci -vvv -x
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller])
        Subsystem: Lenovo 3rd Gen Core processor Graphics Controller
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 26
        Region 0: Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
        Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M]
        Region 4: I/O ports at 4000 [size=64]
        [virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
        Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
                Address: fee08004  Data: 4025
        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [a4] PCI Advanced Features
                AFCap: TP+ FLR+
                AFCtrl: FLR-
                AFStatus: TP-
        Kernel driver in use: i915
00: 86 80 66 01 07 04 90 00 09 00 00 03 00 00 00 00
10: 04 00 00 f0 00 00 00 00 0c 00 00 e0 00 00 00 00
20: 01 40 00 00 00 00 00 00 00 00 00 00 aa 17 08 22
30: 00 00 00 00 90 00 00 00 00 00 00 00 ff 01 00 00
Comment 1 Ville Syrjala 2019-01-28 14:10:17 UTC
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.
Comment 2 Andrea 2019-01-28 17:59:29 UTC
Created attachment 143239 [details]
dmesg drm.debug=0xe
Comment 3 Andrea 2019-01-28 17:59:56 UTC
Created attachment 143240 [details]
intel_watermark with issue
Comment 4 Andrea 2019-01-28 18:00:18 UTC
Created attachment 143241 [details]
intel_watermark without issue
Comment 5 Andrea 2019-01-28 18:01:34 UTC
(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.
Comment 6 Ville Syrjala 2019-01-28 19:01:02 UTC
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?
Comment 7 Andrea 2019-01-28 20:50:48 UTC
(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.
Comment 8 Ville Syrjala 2019-01-29 13:45:24 UTC
(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.
Comment 9 Andrea 2019-01-29 20:05:45 UTC
(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).
Comment 10 Andrea 2019-01-29 23:37:12 UTC
(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.
Comment 11 Lakshmi 2019-02-22 09:04:31 UTC
> 
> Hmm. That machine seems very broken when even LP1 doesn't work.

Ville, LP1 does work and no corruption noticed. How to proceed further?
Comment 12 Ville Syrjala 2019-02-22 15:26:12 UTC
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.
Comment 13 Andrea 2019-03-02 10:12:03 UTC
(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.
Comment 14 Andrea 2019-03-02 10:29:22 UTC
(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
Comment 15 James Ausmus 2019-04-15 17:36:02 UTC
Marking as fixed based on Andrea's feedback that the issue no longer exists on drm-tip
Comment 16 Andrea 2019-05-04 09:26:11 UTC
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.
Comment 17 Ville Syrjala 2019-05-06 16:34:04 UTC
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.
Comment 18 Andrea 2019-05-08 21:59:55 UTC
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
Comment 19 Andrea 2019-05-08 22:01:43 UTC
Created attachment 144199 [details]
2019-05-08_after_3e869fd34856
Comment 20 Andrea 2019-05-08 22:02:37 UTC
Created attachment 144200 [details]
2019-05-08_after_3e869fd34856_igfx_off
Comment 21 Andrea 2019-05-08 22:03:20 UTC
Created attachment 144201 [details]
2019-05-08_revert_3e869fd34856
Comment 22 Andrea 2019-05-08 22:03:41 UTC
Created attachment 144202 [details]
2019-05-08_echo12
Comment 23 Lakshmi 2019-06-26 10:37:40 UTC
@Ville, what's the next step?


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.