while running various kms_frontbuffer_tracking subtests the results are flipping between failed and passed. The failing assert is always due to "FBC disabled". For 20 runs of all kms_frontbuffer_tracking subtests I failed n times on below tests: fbc-1p-offscren-pri-shrfb-draw-blt n=4 fbc-1p-pri-indfb-multidraw n=6 fbc-1p-primscrn-pri-indfb-draw-blt n=2 fbc-1p-primscrn-pri-shrfb-draw-blt n=1 fbc-rgb565-draw-blt n=2 fbc-1p-offscren-pri-shrfb-draw-render n=2 fbc-rgb565-draw-render n=1
I notice that the wait for FBC timeout has also been flip-flopping between 2000-5000ms in the test over time. If I reset the timeout to 5000ms the flip-floppy results can no longer be reproduced.
Created attachment 132298 [details] [review] patch that increase wait timeout for FBC
I have send the patch to the list but so far no comments. Since the timeout was previously set to 5000ms I don't see any problem with going back to this value. NOTE that this is NOT 100% reproducible for each test rather 1/10. It could potentially be the case that the 2000ms timeout has never actually worked.
(In reply to Marta Löfstedt from comment #3) > I have send the patch to the list but so far no comments... Adding Whiteboard PatchSubmitted. Thanks
The following test are working well on BDW with latest configuration ==================================================== Test list ==================================================== fbc-1p-offscren-pri-shrfb-draw-blt fbc-1p-pri-indfb-multidraw fbc-1p-primscrn-pri-indfb-draw-blt fbc-1p-primscrn-pri-shrfb-draw-blt fbc-rgb565-draw-blt fbc-1p-offscren-pri-shrfb-draw-render fbc-rgb565-draw-render ==================================================== Graphic Stack ==================================================== Component: drm tag: libdrm-2.4.81-33-g3876bc2 commit: 3876bc246a07070a6043159cd7623d4def9bbd4c Component: cairo tag: 1.15.6-2-g57b4050 commit: 57b40507dda3f58dfc8635548d606b86dc7bcf51 Component: intel-gpu-tools tag: intel-gpu-tools-1.19-112-g493151b commit: 493151b0768aa4ca535cef49cb7efa174a9c3a77 Component: piglit tag: piglit-v1 commit: 973892687cf5c2f8e2dbe1d22998b82736643787 ====================================== Software ====================================== kernel version : 4.13.0-rc1-drm-tip-ww30-commit-2a4f730+ /bin/bash: BDW-2-NUC5i7RYB: command not found architecture : x86_64 os version : Ubuntu 16.10 os codename : yakkety kernel driver : i915 bios revision : 5.6 bios release date : 05/29/2015 hardware acceleration : disabled swap partition : enabled on (/dev/sda3) ====================================== Graphic drivers ====================================== modesetting : enabled modesetting compiled for : 1.18.4 X.Org Video Driver xorg-xserver : 1.18.4 libdrm : 2.4.82 cairo : 1.15.7 intel-gpu-tools (tag) : intel-gpu-tools-1.19-116-g76bce77 intel-gpu-tools (commit) : 76bce77 ====================================== Hardware ====================================== platform : Broadwell motherboard id : NUC5i7RYB form factor : Desktop cpu family : Core i7 cpu family id : 6 cpu information : Intel(R) Core(TM) i7-5557U CPU @ 3.10GHz gpu card : Intel Corporation Iris Graphics 6100 (rev 09) (prog-if 00 [VGA controller]) memory ram : 7.71 GB max memory ram : 16 GB cpu thread : 4 cpu core : 2 cpu model : 61 cpu stepping : 4 socket : Socket BGA1168 signature : Type 0, Family 6, Model 61, Stepping 4 hard drive : 447GiB (480GB) current cd clock frequency : 337500 kHz maximum cd clock frequency : 540000 kHz displays connected : HDMI-A-1 DP-1
(In reply to Armando Antonio from comment #5) > The following test are working well on BDW with latest configuration > ... > displays connected : HDMI-A-1 DP-1 How many times did you execute this? This bug is about inconsistent results over multiple runs. I have just run 5 times on BDW: fbc-1p-offscren-pri-shrfb-draw-blt and fbc-rgb565-draw-blt fails 1/5. Also, my patch is not integrated, yet.
Still no review on my patch. I asked on IRC: <marta_> I did this IGT patch before vacation: https://patchwork.freedesktop.org/patch/164198/ <marta_> but I have had no comments. <marta_> We have flip-floppy results for kms_frontbuffer_tracking for a lot of fbc related subtests. If I increase time out from 2000ms to 5000ms the tests appear to always pass. <marta_> Note, when the test was created the timeout was 5000ms. <marta_> If anyone has an objection to changing back to 5000ms please speak up! <marta_> bug: https://bugs.freedesktop.org/show_bug.cgi?id=101623 * ThSenior has quit (Remote host closed the connection) * DJAnonimo (shiners@genf196.server4you.de) has joined <danvet> tsa, pls have an eye on shard-kbl runtime <danvet> and complain if still not good enough yet :-) <danvet> with the very latest igt that I just pushed ofc <danvet> marta_, pls ping pzanoni <danvet> he's the master of all I CC:ed Paulo Zanoni on the patch. To document further the initial timeout when the test was created was 5000ms then it was changed to 2000ms by this: commit 64590c7b768dc8d8dd962f812d5ff5a39e7e8b54 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Aug 14 16:08:07 2015 -0300 kms_frontbuffer_tracking: reduce the FBC wait timeout to 2s Just like we did for PSR, let's do it for FBC. FBC gets reenabled in just 50ms, so the 5000ms timeout is huge. On the other hand, we only pay the 5000ms timeout full price 9 times when running kms_frontbuffer_tracking --fbc-only, so this change shouldn't save too much time. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> It is the interesting to note that the PSR timeout was later changed back to 5000ms again. commit d074b44ab6a7ac14cc36b1dc98df5bcf73c82f95 Author: Rodrigo Vivi <rodrigo.vivi@intel.com> Date: Mon Nov 2 15:54:06 2015 -0800 kms_frontbuffer_tracking: Increase the time we wait for PSR.
This flip-flop behaviour is also well documented at: https://intel-gfx-ci.01.org/tree/drm-tip/shards-all.html with a lot a failing kms_frontbuffer_tracking with "FBC disabled" for both the SNB and KBL shards.
Paulo Zanoni has Acked the patch, I will send up V2, when I can find data showing if this is actually a regression or not.
If I run the kms_frontbuffer_tracking tests from the current IGT on a 4.2 vanilla kernel (4.2 was release around the time when igt@64590c7b7 was merged) all tests fail. If I run igt@64590c7b7 on 4.2 kernel some of the pinpointed test consistently fail others consistently pass. If I run igt@64590c7b7 on 4.13-rc3 kernel all kms_frontbuffer_tracking tests fail. So, in a we do indeed have a regression here. However, it seems that both the tests and the kernel have diverged so much during 2 years that it will not make sense to do a bisect. Instead I will need to do some timing experiments to see what is actually going on.
The close to 2 seconds wait for fbc enabled occurs only when we are changing between draw domains, typically between blt and mmap_cpu. Also, we never hit the "retry:" in intel_fbc_work_fn. So, I no longer think this issue is about how long time it takes to enable fbc.
This bug is now about performance of domain changes. Is it reasonable with +2 seconds between blt and mmap_cpu?
Sent V2 of the patch with the included documentation Paulo aksed for.
Chris suggested to use igt_drop_caches_set(device, DROP_RETIRE) instead of increasing timeout. This also appear to significantly improve the runtime of the tests
While spinning a testlist with all kms_frontbuffer_tracking tests. I can no longer reproduce the "FBC disabled" issue on BDW NUCi5 with drm-tip git@ee53909d971 Instead I hit: [ 2739.847719] WARN_ON(fbc->active) [ 2739.847795] ------------[ cut here ]------------ [ 2739.847884] WARNING: CPU: 2 PID: 25732 at drivers/gpu/drm/i915/intel_fbc.c:1173 __intel_fbc_disable+0xdf/0x110 [i915] [ 2739.847886] Modules linked in: rfcomm bnep arc4 iwlmvm binfmt_misc nls_iso8859_1 intel_rapl x86_pkg_temp_thermal intel_powerclamp mac80211 coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd cryptd glue_helper iwlwifi intel_cstate snd_hda_codec_realtek intel_rapl_perf snd_soc_rt5640 snd_hda_codec_hdmi snd_hda_codec_generic snd_soc_rl6231 snd_soc_ssm4567 snd_soc_core cfg80211 snd_hda_intel btusb btrtl btbcm snd_hda_codec btintel snd_compress snd_hwdep bluetooth snd_hda_core input_leds snd_seq lpc_ich ir_rc6_decoder snd_pcm ecdh_generic mei_me shpchp snd_seq_device mei snd_timer rc_rc6_mce ir_lirc_codec lirc_dev snd acpi_als nuvoton_cir snd_soc_sst_acpi rc_core elan_i2c snd_soc_sst_match kfifo_buf dw_dmac dw_dmac_core industrialio 8250_dw spi_pxa2xx_platform [ 2739.847959] acpi_pad soundcore mac_hid parport_pc ppdev lp parport ip_tables x_tables autofs4 i915 hid_generic usbhid i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm e1000e ptp ahci libahci pps_core video sdhci_acpi i2c_hid sdhci hid [ 2739.847997] CPU: 2 PID: 25732 Comm: kms_frontbuffer Tainted: G U W 4.13.0-rc6+ #41 [ 2739.847999] Hardware name: /NUC5i5RYB, BIOS RYBDWi35.86A.0365.2017.0704.1050 07/04/2017 [ 2739.848002] task: ffff8e428b314500 task.stack: ffffa86e42f84000 [ 2739.848070] RIP: 0010:__intel_fbc_disable+0xdf/0x110 [i915] [ 2739.848072] RSP: 0018:ffffa86e42f87940 EFLAGS: 00010286 [ 2739.848076] RAX: 0000000000000014 RBX: ffff8e4283078000 RCX: ffffffffae25f1c8 [ 2739.848079] RDX: 0000000000000000 RSI: 0000000000000096 RDI: 0000000000000247 [ 2739.848081] RBP: ffffa86e42f87950 R08: 0000000000000014 R09: 00000000000046a9 [ 2739.848082] R10: ffffa86e40cdfe30 R11: 0000000000000014 R12: ffff8e428c0f6000 [ 2739.848084] R13: ffff8e428307abf0 R14: ffff8e428c8da000 R15: ffff8e4283078000 [ 2739.848088] FS: 00007f185b9eea40(0000) GS:ffff8e4296d00000(0000) knlGS:0000000000000000 [ 2739.848090] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2739.848092] CR2: 000055de0dc3eeb8 CR3: 000000024b808000 CR4: 00000000003406e0 [ 2739.848095] Call Trace: [ 2739.848161] intel_fbc_disable+0x5f/0x70 [i915] [ 2739.848224] intel_atomic_commit_tail+0x153/0xfa0 [i915] [ 2739.848291] ? intel_atomic_commit_ready+0x48/0x5c [i915] [ 2739.848338] ? __i915_sw_fence_complete+0xf8/0x1a0 [i915] [ 2739.848407] intel_atomic_commit+0x18c/0x240 [i915] [ 2739.848444] drm_atomic_commit+0x4b/0x50 [drm] [ 2739.848500] hsw_pipe_A_crc_wa+0x6b/0x170 [i915] [ 2739.848554] get_new_crc_ctl_reg+0x143/0x330 [i915] [ 2739.848607] intel_crtc_set_crc_source+0x8b/0x200 [i915] [ 2739.848634] crtc_crc_open+0xf1/0x2b0 [drm] [ 2739.848642] ? kmem_cache_alloc_trace+0x181/0x190 [ 2739.848650] full_proxy_open+0xff/0x1c0 [ 2739.848656] do_dentry_open+0x1fc/0x300 [ 2739.848662] ? full_proxy_release+0x90/0x90 [ 2739.848667] vfs_open+0x4e/0x80 [ 2739.848672] path_openat+0x614/0x1490 [ 2739.848677] ? __slab_free+0xa9/0x300 [ 2739.848682] ? __slab_free+0xa9/0x300 [ 2739.848687] ? _copy_to_user+0x2a/0x40 [ 2739.848712] ? crc_control_write+0x7e/0x100 [drm] [ 2739.848717] do_filp_open+0x99/0x110 [ 2739.848723] ? __check_object_size+0xb3/0x190 [ 2739.848729] ? __alloc_fd+0x46/0x170 [ 2739.848735] do_sys_open+0x130/0x220 [ 2739.848740] ? do_sys_open+0x130/0x220 [ 2739.848746] SyS_openat+0x14/0x20 [ 2739.848752] entry_SYSCALL_64_fastpath+0x1e/0xa9 [ 2739.848755] RIP: 0033:0x7f1859be875a [ 2739.848757] RSP: 002b:00007ffd45522540 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 [ 2739.848761] RAX: ffffffffffffffda RBX: 0000564f1343a5a0 RCX: 00007f1859be875a [ 2739.848763] RDX: 0000000000000000 RSI: 00007ffd45522600 RDI: 0000000000000006 [ 2739.848765] RBP: 00007ffd45522740 R08: 0000000000000000 R09: 000000000000000f [ 2739.848767] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 [ 2739.848769] R13: 0000564f1254bb6a R14: 00007ffd45522950 R15: 0000564f12762a60 [ 2739.848772] Code: e1 ea 68 c0 e8 24 77 ed ec 0f ff 80 bb d2 2c 00 00 00 0f 84 6f ff ff ff 48 c7 c6 fb ea 68 c0 48 c7 c7 e1 ea 68 c0 e8 02 77 ed ec <0f> ff 41 80 bc 24 b8 04 00 00 00 0f 84 5a ff ff ff 48 c7 c6 10 [ 2739.848845] ---[ end trace d6ff4a47c036fe0f ]--- [ 2739.848995] WARN_ON(fbc->active) [ 2739.849030] ------------[ cut here ]------------ [ 2739.849103] WARNING: CPU: 2 PID: 25732 at drivers/gpu/drm/i915/intel_fbc.c:1141 intel_fbc_enable+0x4a1/0x550 [i915] [ 2739.849104] Modules linked in: rfcomm bnep arc4 iwlmvm binfmt_misc nls_iso8859_1 intel_rapl x86_pkg_temp_thermal intel_powerclamp mac80211 coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd cryptd glue_helper iwlwifi intel_cstate snd_hda_codec_realtek intel_rapl_perf snd_soc_rt5640 snd_hda_codec_hdmi snd_hda_codec_generic snd_soc_rl6231 snd_soc_ssm4567 snd_soc_core cfg80211 snd_hda_intel btusb btrtl btbcm snd_hda_codec btintel snd_compress snd_hwdep bluetooth snd_hda_core input_leds snd_seq lpc_ich ir_rc6_decoder snd_pcm ecdh_generic mei_me shpchp snd_seq_device mei snd_timer rc_rc6_mce ir_lirc_codec lirc_dev snd acpi_als nuvoton_cir snd_soc_sst_acpi rc_core elan_i2c snd_soc_sst_match kfifo_buf dw_dmac dw_dmac_core industrialio 8250_dw spi_pxa2xx_platform [ 2739.849174] acpi_pad soundcore mac_hid parport_pc ppdev lp parport ip_tables x_tables autofs4 i915 hid_generic usbhid i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm e1000e ptp ahci libahci pps_core video sdhci_acpi i2c_hid sdhci hid [ 2739.849207] CPU: 2 PID: 25732 Comm: kms_frontbuffer Tainted: G U W 4.13.0-rc6+ #41 [ 2739.849209] Hardware name: /NUC5i5RYB, BIOS RYBDWi35.86A.0365.2017.0704.1050 07/04/2017 [ 2739.849211] task: ffff8e428b314500 task.stack: ffffa86e42f84000 [ 2739.849280] RIP: 0010:intel_fbc_enable+0x4a1/0x550 [i915] [ 2739.849283] RSP: 0018:ffffa86e42f878c0 EFLAGS: 00010282 [ 2739.849286] RAX: 0000000000000014 RBX: ffff8e4283078000 RCX: ffffffffae25f1c8 [ 2739.849288] RDX: 0000000000000000 RSI: 0000000000000092 RDI: 0000000000000247 [ 2739.849290] RBP: ffffa86e42f87910 R08: 0000000000000014 R09: 00000000000046e0 [ 2739.849292] R10: ffffa86e42f87670 R11: 0000000000000014 R12: ffff8e428c0f6000 [ 2739.849294] R13: ffff8e42867e9000 R14: ffff8e4283410e00 R15: ffff8e428c8da000 [ 2739.849298] FS: 00007f185b9eea40(0000) GS:ffff8e4296d00000(0000) knlGS:0000000000000000 [ 2739.849300] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2739.849302] CR2: 000055de0dc3eeb8 CR3: 000000024b808000 CR4: 00000000003406e0 [ 2739.849303] Call Trace: [ 2739.849373] intel_update_crtc+0x7a/0xd0 [i915] [ 2739.849441] intel_update_crtcs+0x6b/0x80 [i915] [ 2739.849508] intel_atomic_commit_tail+0x2e9/0xfa0 [i915] [ 2739.849575] ? intel_atomic_commit_ready+0x48/0x5c [i915] [ 2739.849622] ? __i915_sw_fence_complete+0xf8/0x1a0 [i915] [ 2739.849689] intel_atomic_commit+0x18c/0x240 [i915] [ 2739.849722] drm_atomic_commit+0x4b/0x50 [drm] [ 2739.849779] hsw_pipe_A_crc_wa+0x6b/0x170 [i915] [ 2739.849833] get_new_crc_ctl_reg+0x143/0x330 [i915] [ 2739.849886] intel_crtc_set_crc_source+0x8b/0x200 [i915] [ 2739.849912] crtc_crc_open+0xf1/0x2b0 [drm] [ 2739.849918] ? kmem_cache_alloc_trace+0x181/0x190 [ 2739.849925] full_proxy_open+0xff/0x1c0 [ 2739.849931] do_dentry_open+0x1fc/0x300 [ 2739.849936] ? full_proxy_release+0x90/0x90 [ 2739.849942] vfs_open+0x4e/0x80 [ 2739.849947] path_openat+0x614/0x1490 [ 2739.849951] ? __slab_free+0xa9/0x300 [ 2739.849956] ? __slab_free+0xa9/0x300 [ 2739.849960] ? _copy_to_user+0x2a/0x40 [ 2739.849986] ? crc_control_write+0x7e/0x100 [drm] [ 2739.849991] do_filp_open+0x99/0x110 [ 2739.849997] ? __check_object_size+0xb3/0x190 [ 2739.850002] ? __alloc_fd+0x46/0x170 [ 2739.850008] do_sys_open+0x130/0x220 [ 2739.850013] ? do_sys_open+0x130/0x220 [ 2739.850019] SyS_openat+0x14/0x20 [ 2739.850024] entry_SYSCALL_64_fastpath+0x1e/0xa9 [ 2739.850027] RIP: 0033:0x7f1859be875a [ 2739.850029] RSP: 002b:00007ffd45522540 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 [ 2739.850033] RAX: ffffffffffffffda RBX: 0000564f1343a5a0 RCX: 00007f1859be875a [ 2739.850035] RDX: 0000000000000000 RSI: 00007ffd45522600 RDI: 0000000000000006 [ 2739.850037] RBP: 00007ffd45522740 R08: 0000000000000000 R09: 000000000000000f [ 2739.850039] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 [ 2739.850041] R13: 0000564f1254bb6a R14: 00007ffd45522950 R15: 0000564f12762a60 [ 2739.850044] Code: c6 c8 3a 6a c0 48 c7 c7 e1 ea 68 c0 e8 1a 60 ed ec 0f ff e9 f6 fb ff ff 48 c7 c6 fb ea 68 c0 48 c7 c7 e1 ea 68 c0 e8 00 60 ed ec <0f> ff e9 ce fb ff ff 49 8b 94 24 30 2c 00 00 41 03 94 24 08 3f
I believe this new behavior is related to the issue that caused BUG 102410. However, the fix for 102410: "commit 908b6e6e8ab4c1e0c3783be4c4b437ac6fa374ea Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Aug 25 16:02:15 2017 +0100 drm/i915: Quietly cancel FBC activation if CRTC is turned off before worker" only removed a *ERROR* print.
Note we are still seeing "FBC disabled" on KBL-shards: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3016/shard-kbl2/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-blt.html
Note, the WARN_ONs are reproduced on CI: see BUG 102473
I think this bug may be a dup of bug 100020, because the "FBC disabled".
(In reply to Elizabeth from comment #19) > I think this bug may be a dup of bug 100020, because the "FBC disabled". Well, it could be related, but as I wrote in #c15, the "FBC disabled" issue is no longer reproducible. Instead I hit the WARN_ON(fbc->active). Which is handled in BUG 102473. So, are you claiming that you can still reproduce the "FBC disabled" issue in BUG 100020 or are you claiming that you now hit the WARN_ON(fbc->active)?
Sorry for the spam. I mean the "FBC disabled" in KBL, but I need to retest 100020 to be sure if it is still reproducible. (In reply to Marta Löfstedt from comment #17) > Note we are still seeing "FBC disabled" on KBL-shards: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3016/shard-kbl2/ > igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-blt.html
I did a long spin of all kms tests during the weekend with drm-tip@6e644626945c reverted. The results show consistent "FBC disabled" for all fbc related kms_frombuffer_tracking testcases. So, this is also a regression.
Also: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3253/shard-apl4/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-pgflip-blt.html
also, https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3253/shard-apl4/igt@kms_frontbuffer_tracking@fbc-1p-rte.html
(In reply to Elizabeth from comment #21) > Sorry for the spam. I mean the "FBC disabled" in KBL, but I need to retest > 100020 to be sure if it is still reproducible. > (In reply to Marta Löfstedt from comment #17) > > Note we are still seeing "FBC disabled" on KBL-shards: > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3016/shard-kbl2/ > > igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-blt.html 100020 is very specific to a workaround applied only to hsw and it is due the poor status reporting interface in fbc. but I can see the FBC disabled happening on other platforms for unrelated reasons. It still triggers on HSW, btw. This mentions an underrun detection as the cause of failure. It is good to see if the underrun is the actual error or a side effect of the fbc status being overwritten after the actual failure. How hard is it to reproduce on any KBL? I can give it a try too.
(In reply to krisman from comment #25) > (In reply to Elizabeth from comment #21) > > Sorry for the spam. I mean the "FBC disabled" in KBL, but I need to retest > > 100020 to be sure if it is still reproducible. > > (In reply to Marta Löfstedt from comment #17) > > > Note we are still seeing "FBC disabled" on KBL-shards: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3016/shard-kbl2/ > > > igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-blt.html > > 100020 is very specific to a workaround applied only to hsw and it is due > the poor status reporting interface in fbc. but I can see the FBC disabled > happening on other platforms for unrelated reasons. It still triggers on > HSW, btw. > > This mentions an underrun detection as the cause of failure. It is good to > see if the underrun is the actual error or a side effect of the fbc status > being overwritten after the actual failure. How hard is it to reproduce on > any KBL? I can give it a try too. I already have an IGT patch on the list that increase the wait time for the tests. This was sort of Ack:ed, but I believe I would need to provide more investigations as to why this issue was associated with specific draw domain combinations. After that Chris suggested to drop caches, which also solved the issue. At the time I was investigating this issue for BDW. However, just when I was about to finalize a V3 based on dropping caches. The issue on BDW shifted from hitting the "FBC disabled) to the WARN_ON(fbc->active) in bug 102473. So, I started working on that. But unfortunately I have very little time over to do this work. Anyways, if you have a KBL and spin all fbc related frotnbuffer-tracking testcases I am sure that you will eventually reproduce this issue. /Marta
more failing subtests on APL-shards: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3267/shard-apl6/igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-wc.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3267/shard-apl6/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3267/shard-apl6/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3267/shard-apl6/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-mmap-cpu.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3267/shard-apl6/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-move.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3267/shard-apl6/igt@kms_frontbuffer_tracking@fbc-farfromfence.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3267/shard-apl6/igt@kms_frontbuffer_tracking@fbc-badstride.html Note, I have not had any time to investigate if the issue on the APL-shards is infact the same as described in this bug.
Also on SNB-shards: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3267/shard-snb3/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-blt.html
CI_DRM_3288 shard-apl4 igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-gtt fail: (kms_frontbuffer_tracking:4991) CRITICAL: Test assertion failure function do_status_assertions, file kms_frontbuffer_tracking.c:1712: (kms_frontbuffer_tracking:4991) CRITICAL: Failed assertion: false (kms_frontbuffer_tracking:4991) CRITICAL: FBC disabled Subtest fbc-1p-primscrn-cur-indfb-draw-mmap-gtt failed. https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3288/shard-apl4/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-gtt.html
new subtest on: CI_DRM_3288 shard-apl4 igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen (kms_frontbuffer_tracking:4756) CRITICAL: Test assertion failure function do_status_assertions, file kms_frontbuffer_tracking.c:1712: (kms_frontbuffer_tracking:4756) CRITICAL: Failed assertion: false (kms_frontbuffer_tracking:4756) CRITICAL: FBC disabled Subtest fbc-1p-primscrn-spr-indfb-fullscreen failed. https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3288/shard-apl4/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen.html
new subtest on: CI_DRM_3288 shard-apl4 igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-mmap-gtt (kms_frontbuffer_tracking:4014) CRITICAL: Test assertion failure function do_status_assertions, file kms_frontbuffer_tracking.c:1712: (kms_frontbuffer_tracking:4014) CRITICAL: Failed assertion: false (kms_frontbuffer_tracking:4014) CRITICAL: FBC disabled Subtest fbc-1p-primscrn-pri-indfb-draw-mmap-gtt failed. https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3288/shard-apl4/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-mmap-gtt.html
new subtest on: CI_DRM_3288 shard-apl4 igt@kms_frontbuffer_tracking@fbc-suspend (kms_frontbuffer_tracking:5895) CRITICAL: Test assertion failure function do_status_assertions, file kms_frontbuffer_tracking.c:1712: (kms_frontbuffer_tracking:5895) CRITICAL: Failed assertion: false (kms_frontbuffer_tracking:5895) CRITICAL: FBC disabled Subtest fbc-suspend failed. https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3288/shard-apl4/igt@kms_frontbuffer_tracking@fbc-suspend.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3295/shard-kbl3/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-render.html (kms_frontbuffer_tracking:1335) CRITICAL: Test assertion failure function do_status_assertions, file kms_frontbuffer_tracking.c:1712: (kms_frontbuffer_tracking:1335) CRITICAL: Failed assertion: false (kms_frontbuffer_tracking:1335) CRITICAL: FBC disabled Subtest fbc-1p-primscrn-pri-indfb-draw-render failed.
I also see this on shard-glkb with drm-intel-fixes. Particularly it got worst with latest round with fixes on top of 4.14-rc6: dc35b1129cc3 drm/i915: Hold rcu_read_lock when iterating over the radixtree (vma idr) 23e873389d84 drm/i915: Hold rcu_read_lock when iterating over the radixtree (objects) 7c838e2a9be5 drm/i915/edp: read edp display control registers unconditionally 8777b927b92c drm/i915: Do not rely on wm preservation for ILK watermarks 713946d16f45 drm/i915: Cancel the modeset retry work during modeset cleanup
s/4.14-rc6/4.14-rc7. I meant that these patches are applied on top of 4.14-rc7 queued for 4.14-rc8.
Rodrigo, see comment: https://bugs.freedesktop.org/show_bug.cgi?id=101623#c26
Rodrigo also see discussion in: https://patchwork.freedesktop.org/patch/173683/
Fixing title, this applies to more than just BDW.
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3333/shard-snb4/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-render.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3363/shard-apl6/igt@kms_frontbuffer_tracking@fbc-rgb565-draw-blt.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3363/shard-apl6/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3363/shard-apl6/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-mmap-gtt.html https://intel-gfx-ci.01.org/tree/drm-tip/IGT_3992/shard-apl5/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-pwrite.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3443/shard-apl5/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt.html (kms_frontbuffer_tracking:3808) CRITICAL: Test assertion failure function do_status_assertions, file kms_frontbuffer_tracking.c:1712: (kms_frontbuffer_tracking:3808) CRITICAL: Failed assertion: false (kms_frontbuffer_tracking:3808) CRITICAL: FBC disabled Subtest fbc-1p-primscrn-spr-indfb-draw-blt failed.
Here is one for HSW https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3405/shard-hsw2/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-blt.html
Also, on GLK-shards: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3456/shard-glkb3/igt@kms_frontbuffer_tracking@fbc-stridechange.html (kms_frontbuffer_tracking:10021) CRITICAL: Test assertion failure function do_status_assertions, file kms_frontbuffer_tracking.c:1712: (kms_frontbuffer_tracking:10021) CRITICAL: Failed assertion: false (kms_frontbuffer_tracking:10021) CRITICAL: FBC disabled Subtest fbc-stridechange failed.
https://intel-gfx-ci.01.org/tree/drm-tip/IGT_4039/shard-apl5/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-blt.html (kms_frontbuffer_tracking:1921) CRITICAL: Test assertion failure function do_status_assertions, file kms_frontbuffer_tracking.c:1712: (kms_frontbuffer_tracking:1921) CRITICAL: Failed assertion: false (kms_frontbuffer_tracking:1921) CRITICAL: FBC disabled Subtest fbc-1p-offscren-pri-indfb-draw-blt failed.
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3463/shard-glkb4/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt.html (kms_frontbuffer_tracking:1926) CRITICAL: Test assertion failure function do_status_assertions, file kms_frontbuffer_tracking.c:1712: (kms_frontbuffer_tracking:1926) CRITICAL: Failed assertion: false (kms_frontbuffer_tracking:1926) CRITICAL: FBC disabled Subtest fbc-1p-primscrn-shrfb-msflip-blt failed.
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3478/shard-snb4/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-blt.html (kms_frontbuffer_tracking:2464) CRITICAL: Test assertion failure function do_status_assertions, file kms_frontbuffer_tracking.c:1712: (kms_frontbuffer_tracking:2464) CRITICAL: Failed assertion: false (kms_frontbuffer_tracking:2464) CRITICAL: FBC disabled Subtest fbc-1p-primscrn-pri-indfb-draw-blt failed.
https://intel-gfx-ci.01.org/tree/drm-tip/IGT_4071/shard-glkb6/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move.html (kms_frontbuffer_tracking:2690) CRITICAL: Test assertion failure function do_status_assertions, file kms_frontbuffer_tracking.c:1715: (kms_frontbuffer_tracking:2690) CRITICAL: Failed assertion: false (kms_frontbuffer_tracking:2690) CRITICAL: FBC disabled Subtest fbc-1p-primscrn-spr-indfb-move failed.
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3642/shard-hsw7/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-render.html (kms_frontbuffer_tracking:1432) CRITICAL: Test assertion failure function do_status_assertions, file kms_frontbuffer_tracking.c:1714: (kms_frontbuffer_tracking:1432) CRITICAL: Failed assertion: fbc_is_enabled() (kms_frontbuffer_tracking:1432) CRITICAL: FBC disabled Subtest fbc-2p-primscrn-pri-indfb-draw-render failed.
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3669/shard-apl7/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-mmap-cpu.html (kms_frontbuffer_tracking:2158) CRITICAL: Test assertion failure function do_status_assertions, file kms_frontbuffer_tracking.c:1714: (kms_frontbuffer_tracking:2158) CRITICAL: Failed assertion: fbc_is_enabled() (kms_frontbuffer_tracking:2158) CRITICAL: FBC disabled Subtest fbc-1p-offscren-pri-shrfb-draw-mmap-cpu failed.
https://intel-gfx-ci.01.org/tree/drm-tip/IGT_4171/shard-hsw5/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-shrfb-draw-blt.html (kms_frontbuffer_tracking:1331) CRITICAL: Test assertion failure function do_status_assertions, file kms_frontbuffer_tracking.c:1714: (kms_frontbuffer_tracking:1331) CRITICAL: Failed assertion: fbc_is_enabled() (kms_frontbuffer_tracking:1331) CRITICAL: FBC disabled Subtest fbc-2p-scndscrn-pri-shrfb-draw-blt failed.
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3759/shard-apl8/igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-cpu.html (kms_frontbuffer_tracking:1841) WARNING: fbc_is_enabled()? FBC disabled: underrun detected (kms_frontbuffer_tracking:1841) CRITICAL: Test assertion failure function do_status_assertions, file kms_frontbuffer_tracking.c:1833: (kms_frontbuffer_tracking:1841) CRITICAL: Failed assertion: fbc_is_enabled(IGT_LOG_WARN) (kms_frontbuffer_tracking:1841) CRITICAL: FBC disabled Subtest fbc-rgb565-draw-mmap-cpu failed.
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3769/shard-apl8/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-mmap-wc.html (kms_frontbuffer_tracking:1765) WARNING: fbc_is_enabled()? FBC disabled: FIFO underrun (kms_frontbuffer_tracking:1765) CRITICAL: Test assertion failure function do_status_assertions, file kms_frontbuffer_tracking.c:1833: (kms_frontbuffer_tracking:1765) CRITICAL: Failed assertion: fbc_is_enabled(IGT_LOG_WARN) (kms_frontbuffer_tracking:1765) CRITICAL: FBC disabled Subtest fbc-1p-offscren-pri-shrfb-draw-mmap-wc failed.
The below test have failed on CFL QA igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-msflip-blt igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-pgflip-blt igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-plflip-blt igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-shrfb-msflip-blt igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-shrfb-pgflip-blt igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-shrfb-plflip-blt IGT-Version: 1.21-g960e55a (x86_64) (Linux: 4.16.0-rc1-drm-intel-qa-ww8-commit-6697b76+ x86_64) Primary screen: eDP 2560x1440, crtc 0 Secondary screen: DP 3840x2160, crtc 1 FBC last action not supported Can't test DRRS: Not supported. Sink CRC not supported: panel doesn't support it Stack trace: #0 [__igt_fail_assert+0x101] #1 [__do_assertions+0x6a4] #2 [prepare_subtest_screens+0x9] #3 [main+0x27b7] #4 [__libc_start_main+0xf1] #5 [_start+0x29] #6 [<unknown>+0x29] Subtest fbc-2p-primscrn-shrfb-msflip-blt: FAIL (6.019s) (kms_frontbuffer_tracking:1848) WARNING: fbc_is_enabled()? FBC disabled: mode too large for compression (kms_frontbuffer_tracking:1848) CRITICAL: Test assertion failure function do_status_assertions, file kms_frontbuffer_tracking.c:1841: (kms_frontbuffer_tracking:1848) CRITICAL: Failed assertion: fbc_is_enabled(IGT_LOG_WARN) (kms_frontbuffer_tracking:1848) CRITICAL: FBC disabled Subtest fbc-2p-primscrn-shrfb-msflip-blt failed.
It looks like the frequency of hitting this has significantly gone down in favor for bug 103167. except for: GLK igt@kms_frontbuffer_tracking@fbc-stridechange which is 100% fail: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_4297/shard-glkb6/igt@kms_frontbuffer_tracking@fbc-stridechange.html I will remove the impact from KBL-shards in cibuglog, since they hit the link training so frequently.
We now also pull in data from full runs on CFL and CNL: (kms_frontbuffer_tracking:2566) CRITICAL: Test assertion failure function do_status_assertions, file kms_frontbuffer_tracking.c:1844: (kms_frontbuffer_tracking:2566) CRITICAL: Failed assertion: fbc_is_enabled(IGT_LOG_WARN) (kms_frontbuffer_tracking:2566) CRITICAL: FBC disabled https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3903/fi-cnl-y3/igt@kms_frontbuffer_tracking@fbcdrrs-2p-scndscrn-cur-indfb-onoff.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3903/fi-cnl-y3/igt@kms_frontbuffer_tracking@fbcdrrs-2p-primscrn-spr-indfb-draw-pwrite.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3903/fi-cnl-y3/igt@kms_frontbuffer_tracking@fbcdrrs-2p-primscrn-shrfb-msflip-blt.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3903/fi-cnl-y3/igt@kms_frontbuffer_tracking@fbcdrrs-2p-primscrn-pri-shrfb-draw-blt.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3903/fi-cnl-y3/igt@kms_frontbuffer_tracking@fbcdrrs-1p-primscrn-pri-indfb-draw-mmap-wc.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3903/fi-cfl-s2/igt@kms_frontbuffer_tracking@fbc-stridechange.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3903/fi-cnl-y3/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-shrfb-draw-mmap-wc.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3903/fi-cnl-y3/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-fullscreen.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3903/fi-cnl-y3/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt.html
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3915/shard-glkb2/igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-mmap-cpu.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3915/shard-glkb2/igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-mmap-gtt.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3915/shard-glkb2/igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-mmap-wc.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3915/shard-glkb2/igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-pwrite.html https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3915/shard-glkb3/igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-render.html
We have pulled in more data from the shards testlist runs on BAT machines. I am not going to spam all links here just some examples. For overview of the results see: https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html (kms_frontbuffer_tracking:2822) WARNING: fbc_is_enabled()? FBC disabled: mode too large for compression (kms_frontbuffer_tracking:2822) CRITICAL: Test assertion failure function do_status_assertions, file ../tests/kms_frontbuffer_tracking.c:1733: (kms_frontbuffer_tracking:2822) CRITICAL: Failed assertion: fbc_is_enabled(IGT_LOG_WARN) (kms_frontbuffer_tracking:2822) CRITICAL: FBC disabled Subtest fbc-2p-scndscrn-shrfb-msflip-blt failed. Some new examples: https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1/fi-skl-6770hq/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-shrfb-pgflip-blt.html https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1/fi-skl-6770hq/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-shrfb-draw-pwrite.html https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1/fi-skl-guc/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-move.html https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_1/fi-skl-6770hq/igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-shrfb-draw-mmap-gtt.html
This is the type of bug that becomes impossible to manage and fix. It started as a single issue with a single patch to fix it (and the patch was even acked), but as you read the comments you realize it has become a dump for every single type of problem related to FBC: different machines, different types of error messages, different bugs, etc. The fact that there's absolutely no bisection of the many different problems make it even worse. I'll repeat: FBC worked 100% reliably at some point and every single problem is a regression. We should probably categorize all the different problems, split them into different bugs and then bisect.
(In reply to Marta Löfstedt from comment #57) > We have pulled in more data from the shards testlist runs on BAT machines. I > am not going to spam all links here just some examples. For overview of the > results see: > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html > > (kms_frontbuffer_tracking:2822) WARNING: fbc_is_enabled()? > FBC disabled: mode too large for compression This is an entirely different bug. Please go to the BIOS of the machine and increase the amount of stolen memory. Thanks, Paulo
(In reply to Paulo Zanoni from comment #59) > (In reply to Marta Löfstedt from comment #57) > > We have pulled in more data from the shards testlist runs on BAT machines. I > > am not going to spam all links here just some examples. For overview of the > > results see: > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html > > > > (kms_frontbuffer_tracking:2822) WARNING: fbc_is_enabled()? > > FBC disabled: mode too large for compression > > This is an entirely different bug. > > Please go to the BIOS of the machine and increase the amount of stolen > memory. > > Thanks, > Paulo Thanks for the feedback, I do agree that this bug is a big mess, but that is what happens when bugs are not solved in reasonable time. If you can define exactly how you want the bug to be split up based on information given in the results, I will do that. However, the problem with the current version of cibuglog is that once I have filed a (machine, test) pair on an issue I will not see any new results from that pair. So, since a lot of machines flip-flop on various failure on this test it will be random what issue I will file on first. This will be fixed with the new cibuglog that Martin Peres is working on.
One reference: https://patchwork.freedesktop.org/series/40336/
(In reply to Marta Löfstedt from comment #60) > (In reply to Paulo Zanoni from comment #59) > > (In reply to Marta Löfstedt from comment #57) > > > We have pulled in more data from the shards testlist runs on BAT machines. I > > > am not going to spam all links here just some examples. For overview of the > > > results see: > > > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html > > > > > > (kms_frontbuffer_tracking:2822) WARNING: fbc_is_enabled()? > > > FBC disabled: mode too large for compression > > > > This is an entirely different bug. > > > > Please go to the BIOS of the machine and increase the amount of stolen > > memory. > > > > Thanks, > > Paulo > > Thanks for the feedback, I do agree that this bug is a big mess, but that is > what happens when bugs are not solved in reasonable time. That's not a valid excuse. If no developer has time to look into a bug, making it harder to look will only make it worse. > If you can define > exactly how you want the bug to be split up based on information given in > the results, I will do that. Different types of problems in different bugs? I mean, that is very simple. Also, joining separate bug reports for the same thing is 1000x easier than splitting a single bug report into separate bugs. But perhaps first you could look into the stolen memory BIOS solution and the current IGT patch we have (written by you), then after doing these things we see what's left. > However, the problem with the current version > of cibuglog is that once I have filed a (machine, test) pair on an issue I > will not see any new results from that pair. So, since a lot of machines > flip-flop on various failure on this test it will be random what issue I > will file on first. This will be fixed with the new cibuglog that Martin > Peres is working on. Having bad tools is not an excuse for filing bad bug reports.
Pulled out fi-skl-6700hq from this bug, that resultsed in bug 105678
I have now pulled out each machine affected by this bug and replaced by bug 105678, bug 105680, bug 105681, bug 105682, bug 105685 and by 103167 I will archive this from Ci buglog, but since QA have filed issues on it I can't close.
This tests has a failed on CNL QA Tests List: igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-blt igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-mmap-cpu igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-mmap-gtt igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-mmap-wc igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-pwrite igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-render igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-blt igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-mmap-cpu igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-mmap-gtt igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-mmap-wc igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-pwrite igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-render software: IGT-Version: 1.22-gc30e331 (x86_64) (Linux: 4.16.0-rc6-drm-intel-qa-ww12-commit-dff9ece+ x86_64) Output sample: (kms_frontbuffer_tracking:847) DEBUG: fbc_is_enabled(IGT_LOG_DEBUG) took 0ms (kms_frontbuffer_tracking:847) CRITICAL: Test assertion failure function do_status_assertions, file kms_frontbuffer_tracking.c:1753: (kms_frontbuffer_tracking:847) CRITICAL: Failed assertion: !fbc_wait_until_enabled() (kms_frontbuffer_tracking:847) igt-core-INFO: Stack trace: (kms_frontbuffer_tracking:847) igt-core-INFO: #0 [__igt_fail_assert+0x101] (kms_frontbuffer_tracking:847) igt-core-INFO: #1 [__do_assertions+0x4ce] (kms_frontbuffer_tracking:847) igt-core-INFO: #2 [main+0xcb0] (kms_frontbuffer_tracking:847) igt-core-INFO: #3 [__libc_start_main+0xf1] (kms_frontbuffer_tracking:847) igt-core-INFO: #4 [_start+0x29] (kms_frontbuffer_tracking:847) igt-core-INFO: #5 [<unknown>+0x29]
These tests failed with assertion mentioned on comment 65 in ww12 commit-4db112a+ but are now green on ww14 commit-c46052c+ on GLK, CFL and CNL: igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-mmap-cpu igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-mmap-gtt igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-mmap-wc igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-pwrite igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-render igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-blt These tests failed with assertion mentioned on comment 57 in ww11 commit-e867298+ but are now green on ww12 and ww14 on CNL: igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-mmap-wc igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-mmap-gtt igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-blt igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-render igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw These tests failed with assertion mentioned on comment 57 in latest run, ww14, in SNB: igt@kms_frontbuffer_tracking@fbc-rgb565-draw-render igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-gtt igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw This test failed with assertion mentioned on comment 57 with SNB and CNL: igt@kms_frontbuffer_tracking@fbc-2p-pri-indfb-multidraw This test show assertion described on bug 103167: igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-shrfb-draw-mmap-wc
I will close this since it has been replaced by the more detailed FBC disabled bugs mentioned in Comment 64
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.