Bug 108336 - [CI][DRMTIP] igt@*crc tests* - warn / dmesg-warn - Suspicious CRC: it looks like the CRC read back was from a register in a powered down well
Summary: [CI][DRMTIP] igt@*crc tests* - warn / dmesg-warn - Suspicious CRC: it looks l...
Status: RESOLVED DUPLICATE of bug 107724
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: Other All
: highest normal
Assignee: Stanislav Lisovskiy
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords:
: 108993 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-10-12 10:11 UTC by Martin Peres
Modified: 2019-03-08 14:23 UTC (History)
3 users (show)

See Also:
i915 platform: ICL
i915 features: display/Other

Attachments

Description Martin Peres 2018-10-12 10:11:38 UTC 
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_125/fi-icl-u/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_125/fi-icl-u/igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-legacy.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_125/fi-icl-u/igt@kms_flip_tiling@flip-to-yf-tiled.html

	
Starting subtest: flip-to-Yf-tiled
(kms_flip_tiling:1045) igt_debugfs-WARNING: Warning on condition crc->crc[i] == 0xffffffff in function crc_sanity_checks, file ../lib/igt_debugfs.c:869
(kms_flip_tiling:1045) igt_debugfs-WARNING: Suspicious CRC: it looks like the CRC read back was from a register in a powered down well
(kms_flip_tiling:1045) igt_debugfs-WARNING: Warning on condition crc->crc[i] == 0xffffffff in function crc_sanity_checks, file ../lib/igt_debugfs.c:869
(kms_flip_tiling:1045) igt_debugfs-WARNING: Suspicious CRC: it looks like the CRC read back was from a register in a powered down well
(kms_flip_tiling:1045) igt_debugfs-WARNING: Warning on condition crc->crc[i] == 0xffffffff in function crc_sanity_checks, file ../lib/igt_debugfs.c:869
(kms_flip_tiling:1045) igt_debugfs-WARNING: Suspicious CRC: it looks like the CRC read back was from a register in a powered down well
(kms_flip_tiling:1045) igt_debugfs-WARNING: Warning on condition crc->crc[i] == 0xffffffff in function crc_sanity_checks, file ../lib/igt_debugfs.c:869
(kms_flip_tiling:1045) igt_debugfs-WARNING: Suspicious CRC: it looks like the CRC read back was from a register in a powered down well
(kms_flip_tiling:1045) igt_debugfs-WARNING: Warning on condition crc->crc[i] == 0xffffffff in function crc_sanity_checks, file ../lib/igt_debugfs.c:869
(kms_flip_tiling:1045) igt_debugfs-WARNING: Suspicious CRC: it looks like the CRC read back was from a register in a powered down well
(kms_flip_tiling:1045) igt_debugfs-WARNING: Warning on condition crc->crc[i] == 0xffffffff in function crc_sanity_checks, file ../lib/igt_debugfs.c:869
(kms_flip_tiling:1045) igt_debugfs-WARNING: Suspicious CRC: it looks like the CRC read back was from a register in a powered down well
Subtest flip-to-Yf-tiled: SUCCESS (5.177s)

<3> [39.197389] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
<3> [39.203315] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
<3> [40.669535] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
<3> [42.139008] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe C FIFO underrun
<3> [43.613679] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun



https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_125/fi-icl-u/igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-untiled.html

Starting subtest: draw-method-xrgb2101010-mmap-wc-untiled
(kms_draw_crc:1040) igt_debugfs-WARNING: Warning on condition crc->crc[i] == 0xffffffff in function crc_sanity_checks, file ../lib/igt_debugfs.c:869
(kms_draw_crc:1040) igt_debugfs-WARNING: Suspicious CRC: it looks like the CRC read back was from a register in a powered down well
(kms_draw_crc:1040) igt_debugfs-WARNING: Warning on condition crc->crc[i] == 0xffffffff in function crc_sanity_checks, file ../lib/igt_debugfs.c:869
(kms_draw_crc:1040) igt_debugfs-WARNING: Suspicious CRC: it looks like the CRC read back was from a register in a powered down well
Subtest draw-method-xrgb2101010-mmap-wc-untiled: SUCCESS (0.391s)
Comment 1 Martin Peres 2018-10-16 08:03:20 UTC 
Here is a new bunch of these issues, all of them with also fifo underrun:

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_128/fi-icl-u/igt@kms_plane_lowres@pipe-c-tiling-y.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_128/fi-icl-u/igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-move.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_128/fi-icl-u/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html

https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_128/fi-icl-u/igt@kms_ccs@pipe-c-crc-primary-basic.html

	
Starting subtest: pipe-C-crc-primary-basic
(kms_ccs:1181) igt_debugfs-WARNING: Warning on condition crc->crc[i] == 0xffffffff in function crc_sanity_checks, file ../lib/igt_debugfs.c:869
(kms_ccs:1181) igt_debugfs-WARNING: Suspicious CRC: it looks like the CRC read back was from a register in a powered down well
(kms_ccs:1181) igt_debugfs-WARNING: Warning on condition crc->crc[i] == 0xffffffff in function crc_sanity_checks, file ../lib/igt_debugfs.c:869
(kms_ccs:1181) igt_debugfs-WARNING: Suspicious CRC: it looks like the CRC read back was from a register in a powered down well
Subtest pipe-C-crc-primary-basic: SUCCESS (1.884s)

<3> [40.437999] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
<3> [42.588120] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
Comment 2 Jani Saarinen 2018-10-26 10:32:07 UTC 
Need to wait results from BIOS..2392.
Comment 3 Lakshmi 2018-12-03 12:41:55 UTC 
Imre, any progress here?
Comment 4 Jani Saarinen 2018-12-19 14:19:23 UTC 
From Ville (fdo bug 106974)
> I was just looking at crcs on icl and spotted the following:
> 0x00098785 0xd2d6ad2b 0x00000000 0x00000000 0x00000000 0x00000000
> 0x00098786 0xd2d6ad2b 0x00000000 0x00000000 0x00000000 0x00000000
> 0x0009879b 0xffffffff 0x00000000 0x00000000 0x00000000 0x00000000
> 0x0009879c 0xd2d6ad2b 0x00000000 0x00000000 0x00000000 0x00000000
> 0x0009879d 0x82618fd1 0x00000000 0x00000000 0x00000000 0x00000000
> 
> So the frame counter jumps by quite a lot there and we get a bogus crc at
> the same time. As I immediately suspected the culprit is PSR. We should
> probably disable PSR while CRC capturing is enabled.
Comment 5 Stanislav Lisovskiy 2018-12-19 14:20:57 UTC 
I've made some patch for this, testing it now.

https://patchwork.freedesktop.org/series/54267/
Comment 6 Stanislav Lisovskiy 2018-12-19 15:25:12 UTC 
Waiting for the results of the latest patch, however yesterday's one seem to already have many of 107724/108336 cases fixed:

https://patchwork.freedesktop.org/series/54224/:

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-pwrite:
    - shard-iclb:         DMESG-FAIL [fdo#107724] -> PASS +4

  * igt@kms_rotation_crc@primary-rotation-180:
    - shard-iclb:         DMESG-WARN [fdo#107724] / [fdo#108336] -> PASS +12

  * igt@kms_vblank@pipe-c-wait-forked:
    - shard-iclb:         DMESG-WARN [fdo#107724] -> PASS +19
Comment 7 Stanislav Lisovskiy 2019-01-08 08:03:44 UTC 
Current conclusion about the root cause is that some test cases like kms_atomic_transition cause this when they apply extreme plane width and height, drm_atomic_check_only fails then in calc_watermarks function, however there are seem to be some not canceled side effects after that, which lead to the issue. Then all subsequent tests fail with that "suspicious crc" issue.

I have suspicion that calc_watermarks which is called after some changes were already applied in the end of intel_atomic_check, which leaves the system in some weird state.

So the patch was to simply try calling it earlier. Unfortunately it helps only partly, for some reason now at least every first time I run this test case, everything seems to be OK, however next time we still get this "suspicious crc". So I will continue looking to figure out the correct change.
Comment 8 Stanislav Lisovskiy 2019-01-14 12:31:11 UTC 
Found one more interesting thing: 

Sometimes wm levels are written as 0 for all levels, for planes which are currently enabled and have non-zero ddb allocation, which at least looks controversial. This is printed from skl_write_wm_level function, which does the actual write to corresponding watermark level register:

 2445.635172] [PLANE:30:plane 1A] ddb (0 - 992) -> (0 - 248)
[ 2445.666098] [PLANE:58:plane 5A] ddb (0 - 0) -> (248 - 496)
[ 2445.682616] [PLANE:65:plane 6A] ddb (0 - 0) -> (496 - 744)
[ 2445.699144] [PLANE:72:plane 7A] ddb (0 - 0) -> (744 - 992)
[ 2445.718131] Writing plane 0 level 5 0 blocks while plane or ddb(f8) enabled
[ 2445.718133] Writing plane 0 level 6 0 blocks while plane or ddb(f8) enabled
[ 2445.739075] Writing plane 0 level 7 0 blocks while plane or ddb(f8) enabled
[ 2445.760015] Writing plane 4 level 5 0 blocks while plane or ddb(1f0) enabled
[ 2445.780954] Writing plane 4 level 6 0 blocks while plane or ddb(1f0) enabled
[ 2445.802147] Writing plane 4 level 7 0 blocks while plane or ddb(1f0) enabled
[ 2445.823343] Writing plane 5 level 5 0 blocks while plane or ddb(2e8) enabled
[ 2445.844534] Writing plane 5 level 6 0 blocks while plane or ddb(2e8) enabled
[ 2445.865725] Writing plane 5 level 7 0 blocks while plane or ddb(2e8) enabled
[ 2445.886923] Writing plane 6 level 5 0 blocks while plane or ddb(3e0) enabled
[ 2445.908116] Writing plane 6 level 6 0 blocks while plane or ddb(3e0) enabled
[ 2445.929306] Writing plane 6 level 7 0 blocks while plane or ddb(3e0) enabled

So we are writing 0 blocks for enabled plane, which has non-zero ddb(ddb_y->end in brackets) allocation. I wonder if this is correct at all as ddb allocation currently seems to be calculated based on watermarks, moreover does it even make sense to have 0 wm level blocks and non zero ddb range for that?
Comment 9 Ville Syrjala 2019-01-14 19:35:29 UTC 
(In reply to Stanislav Lisovskiy from comment #8)
> Found one more interesting thing: 
> 
> Sometimes wm levels are written as 0 for all levels, for planes which are
> currently enabled and have non-zero ddb allocation, which at least looks
> controversial. This is printed from skl_write_wm_level function, which does
> the actual write to corresponding watermark level register:
> 
>  2445.635172] [PLANE:30:plane 1A] ddb (0 - 992) -> (0 - 248)
> [ 2445.666098] [PLANE:58:plane 5A] ddb (0 - 0) -> (248 - 496)
> [ 2445.682616] [PLANE:65:plane 6A] ddb (0 - 0) -> (496 - 744)
> [ 2445.699144] [PLANE:72:plane 7A] ddb (0 - 0) -> (744 - 992)
> [ 2445.718131] Writing plane 0 level 5 0 blocks while plane or ddb(f8)
> enabled
> [ 2445.718133] Writing plane 0 level 6 0 blocks while plane or ddb(f8)
> enabled
> [ 2445.739075] Writing plane 0 level 7 0 blocks while plane or ddb(f8)
> enabled
> [ 2445.760015] Writing plane 4 level 5 0 blocks while plane or ddb(1f0)
> enabled
> [ 2445.780954] Writing plane 4 level 6 0 blocks while plane or ddb(1f0)
> enabled
> [ 2445.802147] Writing plane 4 level 7 0 blocks while plane or ddb(1f0)
> enabled
> [ 2445.823343] Writing plane 5 level 5 0 blocks while plane or ddb(2e8)
> enabled
> [ 2445.844534] Writing plane 5 level 6 0 blocks while plane or ddb(2e8)
> enabled
> [ 2445.865725] Writing plane 5 level 7 0 blocks while plane or ddb(2e8)
> enabled
> [ 2445.886923] Writing plane 6 level 5 0 blocks while plane or ddb(3e0)
> enabled
> [ 2445.908116] Writing plane 6 level 6 0 blocks while plane or ddb(3e0)
> enabled
> [ 2445.929306] Writing plane 6 level 7 0 blocks while plane or ddb(3e0)
> enabled
> 
> So we are writing 0 blocks for enabled plane, which has non-zero
> ddb(ddb_y->end in brackets) allocation. I wonder if this is correct at all
> as ddb allocation currently seems to be calculated based on watermarks,
> moreover does it even make sense to have 0 wm level blocks and non zero ddb
> range for that?

Presumably in this case level 5+ watermarks are disabled.
Comment 10 Stanislav Lisovskiy 2019-01-15 10:23:24 UTC 
Here is more traces. I've added own prints to skl_program_plane, skl_write_plane_wm, intel_update_crtc and others. Here you can see that at some point we get ddb allocation updated from 0-0 to  0-992, also for level 0 there should be 6 blocks, however in skl_write_plane_wm we write zeroes! 
Looks strange at least to me. Then immediately after that we start to get FIFO underruns:

[  112.129891] skl compute wm
[  112.129892] skl compute wm work
[  112.129897] plane blocks per line 1048576 y_tile_minimum 4194304 cpp 4 min scanlines 4 plane pixel rate 154000 wp->xtiled 0 ytiled 0 rc 0
[  112.129900] Level 0 blocks 6 lines 1 latency 3
[  112.129902] Level 1 blocks 33 lines 2 latency 22
[  112.129904] Level 2 blocks 33 lines 2 latency 22
[  112.129906] Level 3 blocks 49 lines 3 latency 32
[  112.129909] Level 4 blocks 49 lines 3 latency 32
[  112.129911] Level 5 blocks 129 lines 8 latency 100
[  112.129913] Level 6 blocks 177 lines 11 latency 148
[  112.129916] Level 7 blocks 193 lines 12 latency 160
[  112.130229] [PLANE:30:plane 1A] state 00000000cf256453 ddb (0 - 0) -> (0 - 992)
[  112.130518] [PLANE:79:cursor A] state 00000000cf256453 ddb (0 - 0) -> (992 - 1024)
[  112.131873] intel_update_crtc start
[  112.132571] skl update crc wm
[  112.132572] skl update crc wm work
[  112.132936] skl update crc wm
[  112.132937] skl update crc wm work
[  112.135853] skl_program plane start
[  112.135860] skl write plane wm
[  112.135868] Writing plane 0 level 0 6 blocks while plane ddb(0-992) enabled
[  112.135870] Writing plane 0 level 1 33 blocks while plane ddb(0-992) enabled
[  112.135872] Writing plane 0 level 2 33 blocks while plane ddb(0-992) enabled
[  112.135875] Writing plane 0 level 3 49 blocks while plane ddb(0-992) enabled
[  112.135877] Writing plane 0 level 4 49 blocks while plane ddb(0-992) enabled
[  112.135879] Writing plane 0 level 5 129 blocks while plane ddb(0-992) enabled
[  112.135881] Writing plane 0 level 6 177 blocks while plane ddb(0-992) enabled
[  112.135883] Writing plane 0 level 7 193 blocks while plane ddb(0-992) enabled
[  112.135885] Writing plane 0 transition level 8 20 blocks while plane ddb(0-992) enabled
[  112.135887] skl_program plane end
[  112.135890] skl write plane wm
[  112.135892] Writing plane 1 level 0 0 blocks while plane ddb(0-0) enabled
[  112.135894] Writing plane 1 level 1 0 blocks while plane ddb(0-0) enabled
[  112.135897] Writing plane 1 level 2 0 blocks while plane ddb(0-0) enabled
[  112.135898] Writing plane 1 level 3 0 blocks while plane ddb(0-0) enabled
[  112.135901] Writing plane 1 level 4 0 blocks while plane ddb(0-0) enabled
[  112.135903] Writing plane 1 level 5 0 blocks while plane ddb(0-0) enabled
[  112.135905] Writing plane 1 level 6 0 blocks while plane ddb(0-0) enabled
[  112.135907] Writing plane 1 level 7 0 blocks while plane ddb(0-0) enabled
[  112.135909] Writing plane 1 transition level 8 0 blocks while plane ddb(0-0) enabled
[  112.135912] skl write plane wm
[  112.135914] Writing plane 2 level 0 0 blocks while plane ddb(0-0) enabled
[  112.135916] Writing plane 2 level 1 0 blocks while plane ddb(0-0) enabled
[  112.135918] Writing plane 2 level 2 0 blocks while plane ddb(0-0) enabled
[  112.135920] Writing plane 2 level 3 0 blocks while plane ddb(0-0) enabled
[  112.135922] Writing plane 2 level 4 0 blocks while plane ddb(0-0) enabled
[  112.135924] Writing plane 2 level 5 0 blocks while plane ddb(0-0) enabled
[  112.135926] Writing plane 2 level 6 0 blocks while plane ddb(0-0) enabled
[  112.135928] Writing plane 2 level 7 0 blocks while plane ddb(0-0) enabled
[  112.135931] Writing plane 2 transition level 8 0 blocks while plane ddb(0-0) enabled
[  112.135933] skl write plane wm
[  112.135935] Writing plane 3 level 0 0 blocks while plane ddb(0-0) enabled
[  112.135937] Writing plane 3 level 1 0 blocks while plane ddb(0-0) enabled
[  112.135939] Writing plane 3 level 2 0 blocks while plane ddb(0-0) enabled
[  112.135941] Writing plane 3 level 3 0 blocks while plane ddb(0-0) enabled
[  112.135943] Writing plane 3 level 4 0 blocks while plane ddb(0-0) enabled
[  112.135945] Writing plane 3 level 5 0 blocks while plane ddb(0-0) enabled
[  112.135947] Writing plane 3 level 6 0 blocks while plane ddb(0-0) enabled
[  112.135949] Writing plane 3 level 7 0 blocks while plane ddb(0-0) enabled
[  112.135951] Writing plane 3 transition level 8 0 blocks while plane ddb(0-0) enabled
[  112.135954] skl write plane wm
[  112.135956] Writing plane 4 level 0 0 blocks while plane ddb(0-0) enabled
[  112.135958] Writing plane 4 level 1 0 blocks while plane ddb(0-0) enabled
[  112.135960] Writing plane 4 level 2 0 blocks while plane ddb(0-0) enabled
[  112.135962] Writing plane 4 level 3 0 blocks while plane ddb(0-0) enabled
[  112.135964] Writing plane 4 level 4 0 blocks while plane ddb(0-0) enabled
[  112.135966] Writing plane 4 level 5 0 blocks while plane ddb(0-0) enabled
[  112.135968] Writing plane 4 level 6 0 blocks while plane ddb(0-0) enabled
[  112.135971] Writing plane 4 level 7 0 blocks while plane ddb(0-0) enabled
[  112.135973] Writing plane 4 transition level 8 0 blocks while plane ddb(0-0) enabled
[  112.135975] skl write plane wm
[  112.135977] Writing plane 5 level 0 0 blocks while plane ddb(0-0) enabled
[  112.135979] Writing plane 5 level 1 0 blocks while plane ddb(0-0) enabled
[  112.135981] Writing plane 5 level 2 0 blocks while plane ddb(0-0) enabled
[  112.135983] Writing plane 5 level 3 0 blocks while plane ddb(0-0) enabled
[  112.135985] Writing plane 5 level 4 0 blocks while plane ddb(0-0) enabled
[  112.135987] Writing plane 5 level 5 0 blocks while plane ddb(0-0) enabled
[  112.135990] Writing plane 5 level 6 0 blocks while plane ddb(0-0) enabled
[  112.135991] Writing plane 5 level 7 0 blocks while plane ddb(0-0) enabled
[  112.135994] Writing plane 5 transition level 8 0 blocks while plane ddb(0-0) enabled
[  112.135996] skl write plane wm
[  112.135999] Writing plane 6 level 0 0 blocks while plane ddb(0-0) enabled
[  112.136001] Writing plane 6 level 1 0 blocks while plane ddb(0-0) enabled
[  112.136003] Writing plane 6 level 2 0 blocks while plane ddb(0-0) enabled
[  112.136005] Writing plane 6 level 3 0 blocks while plane ddb(0-0) enabled
[  112.136007] Writing plane 6 level 4 0 blocks while plane ddb(0-0) enabled
[  112.136008] Writing plane 6 level 5 0 blocks while plane ddb(0-0) enabled
[  112.136011] Writing plane 6 level 6 0 blocks while plane ddb(0-0) enabled
[  112.136013] Writing plane 6 level 7 0 blocks while plane ddb(0-0) enabled
[  112.136015] Writing plane 6 transition level 8 0 blocks while plane ddb(0-0) enabled
[  112.136042] intel_update_crtc end
[  112.149925] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
Comment 11 Stanislav Lisovskiy 2019-01-15 10:31:21 UTC 
Discard previous comment, everything was correct:

[  112.129900] Level 0 blocks 6 lines 1 latency 3
[  112.129902] Level 1 blocks 33 lines 2 latency 22
[  112.129904] Level 2 blocks 33 lines 2 latency 22
[  112.129906] Level 3 blocks 49 lines 3 latency 32
[  112.129909] Level 4 blocks 49 lines 3 latency 32
[  112.129911] Level 5 blocks 129 lines 8 latency 100
[  112.129913] Level 6 blocks 177 lines 11 latency 148
[  112.129916] Level 7 blocks 193 lines 12 latency 160
[  112.130229] [PLANE:30:plane 1A] state 00000000cf256453 ddb (0 - 0) -> (0 - 992)
[  112.130518] [PLANE:79:cursor A] state 00000000cf256453 ddb (0 - 0) -> (992 - 1024)
[  112.131873] intel_update_crtc start
[  112.132571] skl update crc wm
[  112.132572] skl update crc wm work
[  112.132936] skl update crc wm
[  112.132937] skl update crc wm work
[  112.135853] skl_program plane start
[  112.135860] skl write plane wm
[  112.135868] Writing plane 0 level 0 6 blocks while plane ddb(0-992) enabled
[  112.135870] Writing plane 0 level 1 33 blocks while plane ddb(0-992) enabled
[  112.135872] Writing plane 0 level 2 33 blocks while plane ddb(0-992) enabled
[  112.135875] Writing plane 0 level 3 49 blocks while plane ddb(0-992) enabled
[  112.135877] Writing plane 0 level 4 49 blocks while plane ddb(0-992) enabled
[  112.135879] Writing plane 0 level 5 129 blocks while plane ddb(0-992) enabled
[  112.135881] Writing plane 0 level 6 177 blocks while plane ddb(0-992) enabled
[  112.135883] Writing plane 0 level 7 193 blocks while plane ddb(0-992) enabled
[  112.135885] Writing plane 0 transition level 8 20 blocks while plane ddb(0-992) enabled
[  112.135887] skl_program plane end
[  112.135890] skl write plane wm
Comment 12 Stanislav Lisovskiy 2019-01-15 12:10:57 UTC 
Looks like writing watermarks before updating plane size and not after in skl_program_plane fixes the issue. Typically I can reproduce it every first or second time, however now done few reboots, with 3 runs each and issue disappeared. 

I will continue testing, could be it just got much less reproducible. Otherwise I will send a patch today.
Comment 13 Stanislav Lisovskiy 2019-01-24 12:41:31 UTC 

*** This bug has been marked as a duplicate of bug 107724 ***
Comment 14 Stanislav Lisovskiy 2019-01-24 12:42:20 UTC 
Investigation showed that issue occurs due to same kind of limitations as https://bugs.freedesktop.org/show_bug.cgi?id=107724
Comment 15 Lakshmi 2019-01-30 11:12:03 UTC 
*** Bug 108993 has been marked as a duplicate of this bug. ***
Comment 16 CI Bug Log 2019-03-08 14:23:27 UTC 
A CI Bug Log filter associated to this bug has been updated:

{- ICL: all tests - warn / dmesg-warn - it looks like the CRC read back was from a register in a powered down well -}
{+ ICL: all tests - warn / dmesg-warn / incomplete - it looks like the CRC read back was from a register in a powered down well +}

 No new failures caught with the new filter

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.