The test igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-C spewed the following warning when running on haswell: [ 122.858359] Unclaimed read from register 0x70008 [ 122.858387] ------------[ cut here ]------------ [ 122.858407] WARNING: CPU: 5 PID: 63 at drivers/gpu/drm/i915/intel_uncore.c:792 __unclaimed_reg_debug+0x47/0x60 [i915] [ 122.858409] Modules linked in: vgem snd_hda_codec_hdmi i915 x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul snd_hda_codec_realtek snd_hda_codec_generic ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core r8169 mei_me mii snd_pcm lpc_ich prime_numbers mei [ 122.858476] CPU: 5 PID: 63 Comm: kworker/5:1 Tainted: G U 4.13.0-rc5-CI-CI_DRM_2968+ #1 [ 122.858479] Hardware name: MSI MS-7924/Z97M-G43(MS-7924), BIOS V1.12 02/15/2016 [ 122.858501] Workqueue: events_long i915_hangcheck_elapsed [i915] [ 122.858506] task: ffff88040d1d0040 task.stack: ffffc90000254000 [ 122.858528] RIP: 0010:__unclaimed_reg_debug+0x47/0x60 [i915] [ 122.858531] RSP: 0018:ffffc900002579d8 EFLAGS: 00010096 [ 122.858536] RAX: 0000000000000024 RBX: 0000000000000000 RCX: 0000000000000002 [ 122.858538] RDX: 0000000080000002 RSI: ffffffff81c9f973 RDI: 00000000ffffffff [ 122.858541] RBP: ffffc900002579f0 R08: 0000000000000000 R09: 0000000000000001 [ 122.858543] R10: ffffc90000257968 R11: 0000000089e5bf7e R12: 0000000000070008 [ 122.858545] R13: 0000000000000001 R14: 0000000000000000 R15: ffff880400bd0ba0 [ 122.858548] FS: 0000000000000000(0000) GS:ffff88041fb40000(0000) knlGS:0000000000000000 [ 122.858551] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 122.858553] CR2: 0000006149bc2200 CR3: 0000000003e0f000 CR4: 00000000001406e0 [ 122.858555] Call Trace: [ 122.858578] gen6_read32+0x22d/0x2b0 [i915] [ 122.858600] ? fwtable_read8+0x2c0/0x2c0 [i915] [ 122.858617] intel_modeset_setup_hw_state+0x786/0xe00 [i915] [ 122.858634] __intel_display_resume+0x1f/0xd0 [i915] [ 122.858650] intel_finish_reset+0xff/0x170 [i915] [ 122.858661] i915_reset_device+0x205/0x260 [i915] [ 122.858673] ? gen8_gt_irq_ack+0x170/0x170 [i915] [ 122.858678] ? work_on_cpu_safe+0x60/0x60 [ 122.858691] i915_handle_error+0x2d8/0x430 [i915] [ 122.858695] ? vsnprintf+0xd1/0x4b0 [ 122.858699] ? scnprintf+0x3a/0x70 [ 122.858715] hangcheck_declare_hang+0xd3/0xf0 [i915] [ 122.858728] ? intel_runtime_pm_put+0x56/0xa0 [i915] [ 122.858745] i915_hangcheck_elapsed+0x262/0x2d0 [i915] [ 122.858750] process_one_work+0x224/0x650 [ 122.858754] worker_thread+0x4e/0x3b0 [ 122.858757] kthread+0x114/0x150 [ 122.858759] ? process_one_work+0x650/0x650 [ 122.858761] ? kthread_create_on_node+0x40/0x40 [ 122.858763] ? kthread_create_on_node+0x40/0x40 [ 122.858765] ret_from_fork+0x27/0x40 [ 122.858770] Code: 01 75 31 84 db 75 2d 45 84 ed 48 c7 c0 35 ae 28 a0 48 c7 c6 2b ae 28 a0 48 0f 44 f0 44 89 e2 48 c7 c7 3e ae 28 a0 e8 ca 1f f2 e0 <0f> ff 83 2d 8c f5 0f 00 01 5b 41 5c 41 5d 5d c3 66 0f 1f 84 00 [ 122.858848] ---[ end trace 102ab81f8845a0ae ]--- Full results: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_2968/shard-hsw4/igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-C.html
Daniel suggested this might be related to commit 4055dc75d6b51c23602b11c6f716e59b8947ffbf Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Aug 17 18:32:29 2017 +0100 drm/i915: Stop touching forcewake following a gen6+ engine reset Forcewake is not affected by the engine reset on gen6+. Indeed the reason why we added intel_uncore_forcewake_reset() to gen6_reset_engines() was to keep the bookkeeping intact because the reset did not touch the forcewake bit (yet we cancelled the forcewake consumers)! This was done in commit 521198a2e7095: Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Fri Aug 23 16:52:30 2013 +0300 drm/i915: sanitize forcewake registers on reset In reset we try to restore the forcewake state to pre reset state, using forcewake_count. The reset doesn't seem to clear the forcewake bits so we get warn on forcewake ack register not clearing. That futzing of the forcewake bookkeeping was dropped in commit 0294ae7b44bb ("drm/i915: Consolidate forcewake resetting to a single function"), but it did not make the realisation that the remaining intel_uncore_forcewake_reset() was redundant. The new danger with using intel_uncore_forcewake_reset() with per-engine resets is that the driver and hw are still in an active state as we perform the reset. We may be using the forcewake to read protected registers elsewhere and those results may be clobbered by the concurrent dropping of forcewake. but I was not convinced. On the off chance I was wrong...
*** Bug 102692 has been marked as a duplicate of this bug. ***
Also, on: igt@kms_busy@extended-modeset-hang-oldfb-with-reset-render-A https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3121/shard-hsw5/igt@kms_busy@extended-modeset-hang-oldfb-with-reset-render-A.html
new subtest: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3225/shard-hsw2/igt@kms_busy@extended-modeset-hang-oldfb-with-reset-render-C.html
Reference: https://patchwork.freedesktop.org/patch/188558/
*** Bug 103038 has been marked as a duplicate of this bug. ***
commit 738a8143866c4cdbe4c008f1583a0c55338266b2 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Nov 15 22:04:42 2017 +0200 drm/i915: Don't sanitize frame start delay if the pipe is off
patch integrated to CI_DRM_3354.
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.