Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 13 9月, 2019 5 次提交
  3. 12 9月, 2019 11 次提交
  5. 11 9月, 2019 20 次提交
  7. 10 9月, 2019 4 次提交
    • C
      drm/i915/selftests: Tighten the timeout testing for partial mmaps · 07e98eb0
      由 Chris Wilson 提交于 
      Currently, if there is time remaining before the start of the loop, we
do one full iteration over many possible different chunks within the
object. A full loop may take 50+s (depending on speed of indirect GTT
mmapings) and we try separately with LINEAR, X and Y -- at which point
igt times out. If we check more frequently, we will interrupt the loop
upon our timeout -- it is hard to argue for as this significantly reduces
the test coverage as we dramatically reduce the runtime. In practical
terms, the coverage we should prioritise is in using different fence
setups, forcing verification of the tile row computations over the
current preference of checking extracting chunks. Though the exhaustive
search is great given an infinite timeout, to improve our current
coverage, we also add a randomised smoketest of partial mmaps. So let's
do both, add a randomised smoketest of partial tiling chunks and the
exhaustive (though time limited) search for failures.

Even in adding another subtest, we should shave 100s off BAT! (With,
hopefully, no loss in coverage, at least over multiple runs.)
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190910121009.13431-1-chris@chris-wilson.co.uk
      07e98eb0
    • C
      drm/i915/selftests: Take runtime wakeref for igt_ggtt_lowlevel · 7c465310
      由 Chris Wilson 提交于 
      Being a "low-level" test, we opt to bypass the normal bind/unbind hooks
for the lower level insert_entries/clear_range. For ggtt, the
bind/unbind hooks provide the runtime wakeref and so we must also handle
this in exercising the low level hooks.

<4> [538.151672] RPM raw-wakeref not held
<4> [538.151825] WARNING: CPU: 0 PID: 11 at ./drivers/gpu/drm/i915/intel_runtime_pm.h:107 fwtable_read32+0x1be/0x300 [i915]
<4> [538.151830] Modules linked in: i915(+) amdgpu gpu_sched ttm vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic mei_hdcp btusb btrtl btbcm x86_pkg_temp_thermal coretemp btintel crct10dif_pclmul bluetooth crc32_pclmul snd_intel_nhlt snd_hda_codec ecdh_generic ghash_clmulni_intel ecc snd_hwdep snd_hda_core lpc_ich r8169 realtek snd_pcm mei_me mei prime_numbers pinctrl_broxton pinctrl_intel [last unloaded: i915]
<4> [538.151861] CPU: 0 PID: 11 Comm: migration/0 Tainted: G     U            5.3.0-rc7-CI-Trybot_4938+ #1
<4> [538.151864] Hardware name: Intel corporation NUC6CAYS/NUC6CAYB, BIOS AYAPLCEL.86A.0056.2018.0926.1100 09/26/2018
<4> [538.151960] RIP: 0010:fwtable_read32+0x1be/0x300 [i915]
<4> [538.151965] Code: e8 e7 f9 5f e0 e9 0b ff ff ff 80 3d d5 8d 26 00 00 0f 85 81 fe ff ff 48 c7 c7 ef 01 bd a0 c6 05 c1 8d 26 00 01 e8 b2 e4 6a e0 <0f> 0b e9 67 fe ff ff 80 3d ad 8d 26 00 00 0f 85 65 fe ff ff 48 c7
<4> [538.151969] RSP: 0018:ffffc9000007be10 EFLAGS: 00010086
<4> [538.151972] RAX: 0000000000000000 RBX: ffff88826be10d50 RCX: 0000000000000002
<4> [538.151975] RDX: 0000000080000002 RSI: 0000000000000000 RDI: 00000000ffffffff
<4> [538.151978] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
<4> [538.151981] R10: 0000000000000000 R11: ffffc9000007bcb0 R12: 0000000000101008
<4> [538.151984] R13: 0000000000000000 R14: ffffc9000036f638 R15: 0000000000000002
<4> [538.151987] FS:  0000000000000000(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000
<4> [538.151990] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4> [538.151993] CR2: 00007fd48e7052f8 CR3: 0000000005210000 CR4: 00000000003406f0
<4> [538.151995] Call Trace:
<4> [538.152106]  bxt_vtd_ggtt_clear_range__cb+0x38/0x40 [i915]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190909110011.8958-2-chris@chris-wilson.co.uk
      7c465310
    • C
      drm/i915: Perform GGTT restore much earlier during resume · cec5ca08
      由 Chris Wilson 提交于 
      As soon as we re-enable the various functions within the HW, they may go
off and read data via a GGTT offset. Hence, if we have not yet restored
the GGTT PTE before then, they may read and even *write* random locations
in memory.

Detected by DMAR faults during resume.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Martin Peres <martin.peres@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190909110011.8958-4-chris@chris-wilson.co.uk
      cec5ca08
    • C
      drm/i915/ringbuffer: Flush writes before RING_TAIL update · 0efa99dd
      由 Chris Wilson 提交于 
      Be paranoid and make sure we flush any and all writes out of the WCB
before performing the UC mmio to update the RING_TAIL. (An UC write
should itself be enough to do the flush, hence the paranoia here.) Quite
infrequently, we see problems where the GPU seems to overshoot the
RING_TAIL and so executes garbage, hence the speculation.

References: https://bugs.freedesktop.org/show_bug.cgi?id=111598
References: https://bugs.freedesktop.org/show_bug.cgi?id=111417
References: https://bugs.freedesktop.org/show_bug.cgi?id=111034Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190909113018.13300-1-chris@chris-wilson.co.uk
      0efa99dd