| Summary: | [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 | ||
|---|---|---|---|
| Product: | DRI | Reporter: | Martin Peres <martin.peres> |
| Component: | DRM/Intel | Assignee: | Stanislav Lisovskiy <stanislav.lisovskiy> |
| Status: | RESOLVED DUPLICATE | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Severity: | normal | ||
| Priority: | highest | CC: | intel-gfx-bugs, lakshminarayana.vudum, poojarai984 |
| Version: | XOrg git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | ReadyForDev | ||
| i915 platform: | ICL | i915 features: | display/Other |
|
Description
Martin Peres
2018-10-12 10:11:38 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 Need to wait results from BIOS..2392. Imre, any progress here? 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. I've made some patch for this, testing it now. https://patchwork.freedesktop.org/series/54267/ 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 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. 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? (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. 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 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 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. *** This bug has been marked as a duplicate of bug 107724 *** Investigation showed that issue occurs due to same kind of limitations as https://bugs.freedesktop.org/show_bug.cgi?id=107724 *** Bug 108993 has been marked as a duplicate of this bug. *** 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.