Re: [Intel-gfx] [PATCH] drm: prefix header search paths with $(srctree)/
On Thu, Jan 31, 2019 at 1:01 PM Masahiro Yamada
wrote:
>
> Currently, the Kbuild core manipulates header search paths in a crazy
> way [1].
>
> To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> the search paths in the srctree. Some Makefiles are already written in
> that way, but not all. The goal of this work is to make the notation
> consistent, and finally get rid of the gross hacks.
>
> Having whitespaces after -I does not matter since commit 48f6e3cf5bc6
> ("kbuild: do not drop -I without parameter").
>
> [1]: https://patchwork.kernel.org/patch/9632347/
>
> Signed-off-by: Masahiro Yamada
> ---
Could you take a look at this series, please?
Thanks.
> I put all gpu/drm changes into a single patch because
> they are trivial conversion.
>
> Please let me know if I need to split this into per-driver patches.
>
>
> drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
> drivers/gpu/drm/amd/lib/Makefile| 2 +-
> drivers/gpu/drm/i915/gvt/Makefile | 2 +-
> drivers/gpu/drm/msm/Makefile| 6 +++---
> drivers/gpu/drm/nouveau/Kbuild | 8
> 5 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
> b/drivers/gpu/drm/amd/amdgpu/Makefile
> index f76bcb9..b21ebb0 100644
> --- a/drivers/gpu/drm/amd/amdgpu/Makefile
> +++ b/drivers/gpu/drm/amd/amdgpu/Makefile
> @@ -23,7 +23,7 @@
> # Makefile for the drm device driver. This driver provides support for the
> # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>
> -FULL_AMD_PATH=$(src)/..
> +FULL_AMD_PATH=$(srctree)/$(src)/..
> DISPLAY_FOLDER_NAME=display
> FULL_AMD_DISPLAY_PATH = $(FULL_AMD_PATH)/$(DISPLAY_FOLDER_NAME)
>
> diff --git a/drivers/gpu/drm/amd/lib/Makefile
> b/drivers/gpu/drm/amd/lib/Makefile
> index 6902430..d534992 100644
> --- a/drivers/gpu/drm/amd/lib/Makefile
> +++ b/drivers/gpu/drm/amd/lib/Makefile
> @@ -27,6 +27,6 @@
> # driver components or later moved to kernel/lib for sharing with
> # other drivers.
>
> -ccflags-y := -I$(src)/../include
> +ccflags-y := -I $(srctree)/$(src)/../include
>
> obj-$(CONFIG_CHASH) += chash.o
> diff --git a/drivers/gpu/drm/i915/gvt/Makefile
> b/drivers/gpu/drm/i915/gvt/Makefile
> index b016dc7..a4a5a96 100644
> --- a/drivers/gpu/drm/i915/gvt/Makefile
> +++ b/drivers/gpu/drm/i915/gvt/Makefile
> @@ -5,6 +5,6 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o
> trace_points.o firmware.o \
> execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o
> debugfs.o \
> fb_decoder.o dmabuf.o page_track.o
>
> -ccflags-y += -I$(src) -I$(src)/$(GVT_DIR)
> +ccflags-y += -I $(srctree)/$(src) -I
> $(srctree)/$(src)/$(GVT_DIR)/
> i915-y += $(addprefix $(GVT_DIR)/,
> $(GVT_SOURCE))
> obj-$(CONFIG_DRM_I915_GVT_KVMGT) += $(GVT_DIR)/kvmgt.o
> diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
> index 56a70c7..b7b1ebd 100644
> --- a/drivers/gpu/drm/msm/Makefile
> +++ b/drivers/gpu/drm/msm/Makefile
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0
> -ccflags-y := -Idrivers/gpu/drm/msm
> -ccflags-y += -Idrivers/gpu/drm/msm/disp/dpu1
> -ccflags-$(CONFIG_DRM_MSM_DSI) += -Idrivers/gpu/drm/msm/dsi
> +ccflags-y := -I $(srctree)/$(src)
> +ccflags-y += -I $(srctree)/$(src)/disp/dpu1
> +ccflags-$(CONFIG_DRM_MSM_DSI) += -I $(srctree)/$(src)/dsi
>
> msm-y := \
> adreno/adreno_device.o \
> diff --git a/drivers/gpu/drm/nouveau/Kbuild b/drivers/gpu/drm/nouveau/Kbuild
> index b17843d..b4bc88ad 100644
> --- a/drivers/gpu/drm/nouveau/Kbuild
> +++ b/drivers/gpu/drm/nouveau/Kbuild
> @@ -1,7 +1,7 @@
> -ccflags-y += -I$(src)/include
> -ccflags-y += -I$(src)/include/nvkm
> -ccflags-y += -I$(src)/nvkm
> -ccflags-y += -I$(src)
> +ccflags-y += -I $(srctree)/$(src)/include
> +ccflags-y += -I $(srctree)/$(src)/include/nvkm
> +ccflags-y += -I $(srctree)/$(src)/nvkm
> +ccflags-y += -I $(srctree)/$(src)
>
> # NVKM - HW resource manager
> #- code also used by various userspace tools/tests
> --
> 2.7.4
>
--
Best Regards
Masahiro Yamada
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] component: Add documentation
On 2/7/19 3:27 PM, Daniel Vetter wrote:
Hi Daniel,
I have a few possible changes for this documentation (see below).
> ---
> Documentation/driver-api/component.rst | 17
> Documentation/driver-api/device_link.rst | 3 +
> Documentation/driver-api/index.rst | 1 +
> drivers/base/component.c | 106 ++-
> include/linux/component.h| 70 +++
> 5 files changed, 194 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/driver-api/component.rst
>
> diff --git a/drivers/base/component.c b/drivers/base/component.c
> index ddcea8739c12..1624c2a892a5 100644
> --- a/drivers/base/component.c
> +++ b/drivers/base/component.c
> @@ -16,6 +16,32 @@
> #include
> #include
>
> +/**
> + * DOC: overview
> + *
> + * The component helper allows drivers to collect a pile of sub-devices,
> + * including their bound drivers, into an aggregate driver. Various
> subsystems
> + * already provide functions to get hold of such components, e.g.
> + * of_clk_get_by_name(). The component helper can be used when such a
> + * subsystem-specific way to find a device is not available: The component
> + * helper fills the niche of aggregate drivers for specific hardware, where
> + * further standardization into a subsystem would not be practical. The
> common
> + * example is when a logical device (e.g. a DRM display driver) is spread
> around
> + * the SoC on various component (scanout engines, blending blocks,
> transcoders
on various components
> + * for various outputs and so on).
> + *
> + * The component helper also doesn't solve runtime dependencies, e.g. for
> system
> + * suspend and resume operations. See also :ref:`device links`.
> + *
> + * Components are registered using component_add() and unregistered with
> + * component_del(), usually from the driver's probe and disconnect functions.
> + *
> + * Aggregate drivers first assemble a component match list of what they need
> + * using component_match_add(). This is then registered as an aggregate
> driver
> + * using component_master_add_with_match(), and unregistered using
> + * component_master_del().
> + */
> +
> struct component;
>
> struct component_match_array {
> @@ -301,10 +327,24 @@ static int component_match_realloc(struct device *dev,
> return 0;
> }
>
> -/*
> - * Add a component to be matched, with a release function.
> +/**
> + * component_match_add_release - add a component match with release callback
> + * @master: device with the aggregate driver
> + * @matchptr: pointer to the list of component matches
> + * @release: release function for @compare_data
> + * @compare: compare function to match against all components
> + * @compare_data: opaque pointer passed to the @compare function
> + *
> + * Adds a new component match to the list stored in @matchptr, which the
> @master
> + * aggregate driver needs to function. The list of component matches pointed
> to
> + * by @matchptr must be initialized to NULL before adding the first match.
> + *
> + * The allocated match list in @matchptr is automatically released using devm
> + * actions, where upon @release will be called to free any references held by
> + * @compare_data, e.g. when @compare_data is a _node that must be
> + * released with of_node_put().
> *
> - * The match array is first created or extended if necessary.
> + * See also component_match_add().
> */
> void component_match_add_release(struct device *master,
> struct component_match **matchptr,
> @@ -367,6 +407,18 @@ static void free_master(struct master *master)
> kfree(master);
> }
>
> +/**
> + * component_master_add_with_match - register an aggregate driver
> + * @dev: device with the aggregate driver
> + * @ops: callbacks for the aggregate driver
> + * @match: component match list for the aggregate driver
> + *
> + * Registers a new aggregate driver consisting of the components added to
> @match
> + * by calling one of the component_match_add() functions. Once all
> components in
> + * @match are available, it will be assembled by calling
> + * _master_ops.bind from @ops. Must be unregistered by calling
> + * component_master_del().
> + */
> int component_master_add_with_match(struct device *dev,
> const struct component_master_ops *ops,
> struct component_match *match)
> @@ -403,6 +455,15 @@ int component_master_add_with_match(struct device *dev,
> }
> EXPORT_SYMBOL_GPL(component_master_add_with_match);
>
> +/**
> + * component_master_del - unregister an aggregate driver
> + * @dev: device with the aggregate driver
> + * @ops: callbacks for the aggregate driver
> + *
> + * Unregisters an aggregate driver registered with
> + * component_master_add_with_match(). If necessary the aggregate driver is
> first
> + * disassembled by calling _master_ops.unbind from @ops.
> + */
> void component_master_del(struct device *dev,
> const struct component_master_ops *ops)
> {
>
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Move local mock_ggtt allocations to the heap
== Series Details ==
Series: drm/i915/selftests: Move local mock_ggtt allocations to the heap
URL : https://patchwork.freedesktop.org/series/56813/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5617_full -> Patchwork_12241_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12241_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c:
- shard-kbl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_cursor_crc@cursor-128x128-random:
- shard-apl: PASS -> FAIL [fdo#103232] +4
* igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232]
* igt@kms_fbcon_fbt@fbc:
- shard-iclb: PASS -> DMESG-WARN [fdo#109593]
* igt@kms_flip@dpms-vs-vblank-race-interruptible:
- shard-kbl: PASS -> FAIL [fdo#103060]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-wc:
- shard-apl: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff:
- shard-glk: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-blt:
- shard-iclb: PASS -> FAIL [fdo#103167] +5
* igt@kms_plane@pixel-format-pipe-b-planes:
- shard-apl: PASS -> FAIL [fdo#103166] +2
* igt@kms_plane@pixel-format-pipe-b-planes-source-clamping:
- shard-apl: PASS -> FAIL [fdo#108948]
* igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
- shard-iclb: PASS -> FAIL [fdo#103166]
* igt@pm_rpm@basic-rte:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +3
Possible fixes
* igt@kms_cursor_crc@cursor-128x128-suspend:
- shard-apl: FAIL [fdo#103191] / [fdo#103232] -> PASS
* igt@kms_cursor_crc@cursor-256x256-random:
- shard-apl: FAIL [fdo#103232] -> PASS +5
* igt@kms_flip@flip-vs-expired-vblank:
- shard-iclb: FAIL [fdo#105363] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-apl: FAIL [fdo#103167] -> PASS +2
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
- shard-iclb: FAIL [fdo#103167] -> PASS +1
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-glk: FAIL [fdo#103167] -> PASS +2
* igt@kms_plane_multiple@atomic-pipe-b-tiling-x:
- shard-iclb: FAIL [fdo#103166] -> PASS
* igt@kms_psr@no_drrs:
- shard-iclb: FAIL [fdo#108341] -> PASS
* igt@kms_universal_plane@universal-plane-pipe-c-functional:
- shard-glk: FAIL [fdo#103166] -> PASS
* igt@pm_rpm@legacy-planes-dpms:
- shard-iclb: DMESG-WARN [fdo#107724] -> PASS
Warnings
* igt@i915_selftest@live_contexts:
- shard-iclb: DMESG-FAIL [fdo#108569] -> INCOMPLETE [fdo#108569]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103060]: https://bugs.freedesktop.org/show_bug.cgi?id=103060
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108341]: https://bugs.freedesktop.org/show_bug.cgi?id=108341
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108948]: https://bugs.freedesktop.org/show_bug.cgi?id=108948
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109280]: https://bugs.freedesktop.org/show_bug.cgi?id=109280
[fdo#109281]: https://bugs.freedesktop.org/show_bug.cgi?id=109281
[fdo#109593]: https://bugs.freedesktop.org/show_bug.cgi?id=109593
Participating hosts (7 -> 6)
--
Missing(1): shard-skl
Build changes
-
* Linux: CI_DRM_5617 -> Patchwork_12241
CI_DRM_5617: 75d902e598dbb8f95b42abc70dfcf41d275f478f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4833: 7802324e86ddf947cba847e910f75b1a8affe8d7 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12241: 3d3a696bdb9acbbaac51177e262676699fd0a982 @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @
git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12241/
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/9] drm/i915: Make user contexts bannable again! (rev2)
== Series Details ==
Series: series starting with [1/9] drm/i915: Make user contexts bannable again!
(rev2)
URL : https://patchwork.freedesktop.org/series/56809/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5617_full -> Patchwork_12240_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_12240_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12240_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_12240_full:
### IGT changes ###
Possible regressions
* igt@gem_ctx_param@invalid-param-set:
- shard-kbl: PASS -> FAIL
- shard-hsw: PASS -> FAIL
- shard-snb: PASS -> FAIL
- shard-glk: PASS -> FAIL
- shard-iclb: PASS -> FAIL
- shard-apl: PASS -> FAIL
Known issues
Here are the changes found in Patchwork_12240_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_param@invalid-param-get:
- shard-apl: PASS -> FAIL [fdo#109559]
- shard-iclb: PASS -> FAIL [fdo#109559]
- shard-glk: PASS -> FAIL [fdo#109559]
- shard-snb: PASS -> FAIL [fdo#109559]
- shard-hsw: PASS -> FAIL [fdo#109559]
- shard-kbl: PASS -> FAIL [fdo#109559]
* igt@kms_color@pipe-c-legacy-gamma:
- shard-glk: PASS -> FAIL [fdo#104782]
* igt@kms_cursor_crc@cursor-256x256-dpms:
- shard-apl: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions:
- shard-hsw: PASS -> FAIL [fdo#103355]
* igt@kms_fbcon_fbt@fbc:
- shard-iclb: PASS -> DMESG-WARN [fdo#109593]
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-wc:
- shard-glk: PASS -> FAIL [fdo#103167] +3
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-wc:
- shard-iclb: PASS -> FAIL [fdo#103167] +2
* igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-apl: PASS -> FAIL [fdo#103166]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-x:
- shard-glk: PASS -> FAIL [fdo#103166] +1
* igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
- shard-iclb: PASS -> FAIL [fdo#103166]
* igt@kms_vblank@pipe-c-ts-continuation-dpms-rpm:
- shard-apl: PASS -> FAIL [fdo#104894]
* igt@pm_rpm@dpms-lpsp:
- shard-iclb: PASS -> DMESG-WARN [fdo#107724] +2
Possible fixes
* igt@i915_selftest@live_workarounds:
- shard-iclb: DMESG-FAIL [fdo#108954] -> PASS
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-glk: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_cursor_crc@cursor-128x42-sliding:
- shard-apl: FAIL [fdo#103232] -> PASS +7
* igt@kms_cursor_legacy@flip-vs-cursor-atomic:
- shard-glk: FAIL [fdo#102670] -> PASS
* igt@kms_flip@flip-vs-expired-vblank:
- shard-iclb: FAIL [fdo#105363] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-apl: FAIL [fdo#103167] -> PASS +3
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
- shard-iclb: FAIL [fdo#103167] -> PASS +1
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-fullscreen:
- shard-glk: FAIL [fdo#103167] -> PASS
* igt@kms_plane@plane-position-covered-pipe-b-planes:
- shard-glk: FAIL [fdo#103166] -> PASS
* igt@kms_plane_multiple@atomic-pipe-b-tiling-x:
- shard-iclb: FAIL [fdo#103166] -> PASS
* igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
- shard-apl: FAIL [fdo#103166] -> PASS +1
* igt@kms_sysfs_edid_timing:
- shard-iclb: FAIL [fdo#100047] -> PASS
* igt@pm_rpm@cursor-dpms:
- shard-iclb: DMESG-WARN [fdo#107724] -> PASS +2
* igt@pm_rpm@universal-planes:
- shard-iclb: DMESG-WARN [fdo#108654] / [fdo#108756] -> PASS
Warnings
* igt@pm_backlight@fade_with_suspend:
- shard-iclb: FAIL [fdo#107847] -> DMESG-FAIL [fdo#107724] /
[fdo#107847]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#100047]: https://bugs.freedesktop.org/show_bug.cgi?id=100047
[fdo#102670]: https://bugs.freedesktop.org/show_bug.cgi?id=102670
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Move local mock_ggtt allocations to the heap
== Series Details ==
Series: drm/i915/selftests: Move local mock_ggtt allocations to the heap
URL : https://patchwork.freedesktop.org/series/56813/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5617 -> Patchwork_12241
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/56813/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12241 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: PASS -> FAIL [fdo#109485]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
Possible fixes
* igt@kms_pipe_crc_basic@read-crc-pipe-a:
- fi-byt-clapper: FAIL [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
[fdo#109513]: https://bugs.freedesktop.org/show_bug.cgi?id=109513
[fdo#109527]: https://bugs.freedesktop.org/show_bug.cgi?id=109527
[fdo#109528]: https://bugs.freedesktop.org/show_bug.cgi?id=109528
[fdo#109530]: https://bugs.freedesktop.org/show_bug.cgi?id=109530
Participating hosts (37 -> 33)
--
Additional (3): fi-icl-y fi-glk-j4005 fi-whl-u
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-byt-j1900 fi-byt-squawks
fi-bsw-cyan fi-apl-guc fi-bsw-kefka
Build changes
-
* Linux: CI_DRM_5617 -> Patchwork_12241
CI_DRM_5617: 75d902e598dbb8f95b42abc70dfcf41d275f478f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4833: 7802324e86ddf947cba847e910f75b1a8affe8d7 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12241: 3d3a696bdb9acbbaac51177e262676699fd0a982 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
3d3a696bdb9a drm/i915/selftests: Move local mock_ggtt allocations to the heap
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12241/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_create: Verify that all new objects are clear
On Sun, 17 Feb 2019 at 20:27, Chris Wilson wrote:
>
> Quoting Matthew Auld (2019-02-17 18:35:05)
> > On Thu, 14 Feb 2019 at 18:32, Chris Wilson wrote:
> > >
> > > The kernel must not return stale information back to userspace when they
> > > create a new object. For that purpose, we always clear objects on
> > > creation, so verify that this is so.
> > >
> > > Signed-off-by: Chris Wilson
> > > Cc: Matthew Auld
> > > ---
> > > tests/i915/gem_create.c | 71 +
> > > 1 file changed, 71 insertions(+)
> > >
> > > diff --git a/tests/i915/gem_create.c b/tests/i915/gem_create.c
> > > index 25c5e8088..9de2263d5 100644
> > > --- a/tests/i915/gem_create.c
> > > +++ b/tests/i915/gem_create.c
> > > @@ -44,6 +44,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > #include
> > >
> > > @@ -141,6 +142,73 @@ static void invalid_nonaligned_size(int fd)
> > > gem_close(fd, handle);
> > > }
> > >
> > > +static uint64_t get_npages(uint64_t *global, uint64_t npages)
> > > +{
> > > + uint64_t try, old, max;
> > > +
> > > + max = *global;
> > > + do {
> > > + old = max;
> > > + try = npages % (max / 2);
> > > + max -= try;
> > > + } while ((max = __sync_val_compare_and_swap(global, old, max)) !=
> > > old);
> > > +
> > > + return try;
> > > +}
> > > +
> > > +struct thread_clear {
> > > + uint64_t max;
> > > + int timeout;
> > > + int i915;
> > > +};
> > > +
> > > +static void *thread_clear(void *data)
> > > +{
> > > + struct thread_clear *arg = data;
> > > + int i915 = arg->i915;
> > > +
> > > + igt_until_timeout(arg->timeout) {
> > > + uint32_t handle;
> > > + uint64_t npages;
> > > +
> > > + npages = random();
> > > + npages <<= 32;
> > > + npages |= random();
> > > + npages = get_npages(>max, npages);
> > > +
> > > + handle = gem_create(i915, npages << 12);
> > > + for (uint64_t page = 0; page < npages; page++) {
> > > + uint64_t x;
> > > +
> > > + gem_read(i915, handle,
> > > + page % (4096 - sizeof(x)),
> > > + , sizeof(x));
> >
> > Don't we also want to read some values outside of the first page, or
> > am I missing something?
>
> No it was meant to be advancing each page, and then byte within page.
>
> With the trivial page * 4096 + ...?
Yup, r-b.
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_create: Verify that all new objects are clear
Quoting Matthew Auld (2019-02-17 18:35:05)
> On Thu, 14 Feb 2019 at 18:32, Chris Wilson wrote:
> >
> > The kernel must not return stale information back to userspace when they
> > create a new object. For that purpose, we always clear objects on
> > creation, so verify that this is so.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Matthew Auld
> > ---
> > tests/i915/gem_create.c | 71 +
> > 1 file changed, 71 insertions(+)
> >
> > diff --git a/tests/i915/gem_create.c b/tests/i915/gem_create.c
> > index 25c5e8088..9de2263d5 100644
> > --- a/tests/i915/gem_create.c
> > +++ b/tests/i915/gem_create.c
> > @@ -44,6 +44,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> >
> > @@ -141,6 +142,73 @@ static void invalid_nonaligned_size(int fd)
> > gem_close(fd, handle);
> > }
> >
> > +static uint64_t get_npages(uint64_t *global, uint64_t npages)
> > +{
> > + uint64_t try, old, max;
> > +
> > + max = *global;
> > + do {
> > + old = max;
> > + try = npages % (max / 2);
> > + max -= try;
> > + } while ((max = __sync_val_compare_and_swap(global, old, max)) !=
> > old);
> > +
> > + return try;
> > +}
> > +
> > +struct thread_clear {
> > + uint64_t max;
> > + int timeout;
> > + int i915;
> > +};
> > +
> > +static void *thread_clear(void *data)
> > +{
> > + struct thread_clear *arg = data;
> > + int i915 = arg->i915;
> > +
> > + igt_until_timeout(arg->timeout) {
> > + uint32_t handle;
> > + uint64_t npages;
> > +
> > + npages = random();
> > + npages <<= 32;
> > + npages |= random();
> > + npages = get_npages(>max, npages);
> > +
> > + handle = gem_create(i915, npages << 12);
> > + for (uint64_t page = 0; page < npages; page++) {
> > + uint64_t x;
> > +
> > + gem_read(i915, handle,
> > + page % (4096 - sizeof(x)),
> > + , sizeof(x));
>
> Don't we also want to read some values outside of the first page, or
> am I missing something?
No it was meant to be advancing each page, and then byte within page.
With the trivial page * 4096 + ...?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915/selftests: Move local mock_ggtt allocations to the heap
This struct appears quite large and pushes our stack frame over
1024 bytes -- too high for conservative setups. So move the mock_ggtt
struct to the heap.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 16 +++-
drivers/gpu/drm/i915/selftests/i915_vma.c | 16 +++-
2 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index 3850ef4a5ec8..488994d4ec19 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -1681,25 +1681,31 @@ int i915_gem_gtt_mock_selftests(void)
SUBTEST(igt_gtt_insert),
};
struct drm_i915_private *i915;
- struct i915_ggtt ggtt;
+ struct i915_ggtt *ggtt;
int err;
i915 = mock_gem_device();
if (!i915)
return -ENOMEM;
- mock_init_ggtt(i915, );
+ ggtt = kmalloc(sizeof(*ggtt), GFP_KERNEL);
+ if (!ggtt) {
+ err = -ENOMEM;
+ goto out_put;
+ }
+ mock_init_ggtt(i915, ggtt);
mutex_lock(>drm.struct_mutex);
- err = i915_subtests(tests, );
+ err = i915_subtests(tests, ggtt);
mock_device_flush(i915);
mutex_unlock(>drm.struct_mutex);
i915_gem_drain_freed_objects(i915);
- mock_fini_ggtt();
+ mock_fini_ggtt(ggtt);
+ kfree(ggtt);
+out_put:
drm_dev_put(>drm);
-
return err;
}
diff --git a/drivers/gpu/drm/i915/selftests/i915_vma.c
b/drivers/gpu/drm/i915/selftests/i915_vma.c
index cf1de82741fa..fc594b030f5a 100644
--- a/drivers/gpu/drm/i915/selftests/i915_vma.c
+++ b/drivers/gpu/drm/i915/selftests/i915_vma.c
@@ -725,24 +725,30 @@ int i915_vma_mock_selftests(void)
SUBTEST(igt_vma_partial),
};
struct drm_i915_private *i915;
- struct i915_ggtt ggtt;
+ struct i915_ggtt *ggtt;
int err;
i915 = mock_gem_device();
if (!i915)
return -ENOMEM;
- mock_init_ggtt(i915, );
+ ggtt = kmalloc(sizeof(*ggtt), GFP_KERNEL);
+ if (!ggtt) {
+ err = -ENOMEM;
+ goto out_put;
+ }
+ mock_init_ggtt(i915, ggtt);
mutex_lock(>drm.struct_mutex);
- err = i915_subtests(tests, );
+ err = i915_subtests(tests, ggtt);
mock_device_flush(i915);
mutex_unlock(>drm.struct_mutex);
i915_gem_drain_freed_objects(i915);
- mock_fini_ggtt();
+ mock_fini_ggtt(ggtt);
+ kfree(ggtt);
+out_put:
drm_dev_put(>drm);
-
return err;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/9] drm/i915/selftests: Move local mock_ggtt allocations to the heap
Quoting Matthew Auld (2019-02-17 18:40:05) > On Sun, 17 Feb 2019 at 16:13, Chris Wilson wrote: > > > > This struct appears quite large and pushes our stack frame over > > 1024 bytes -- too high for conservative setups. So move the mock_ggtt > > struct to the heap. > > > > Signed-off-by: Chris Wilson > > Cc: Matthew Auld > > Missing kfree() somewhere? Or two. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/9] drm/i915/selftests: Move local mock_ggtt allocations to the heap
On Sun, 17 Feb 2019 at 16:13, Chris Wilson wrote: > > This struct appears quite large and pushes our stack frame over > 1024 bytes -- too high for conservative setups. So move the mock_ggtt > struct to the heap. > > Signed-off-by: Chris Wilson > Cc: Matthew Auld Missing kfree() somewhere? Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_create: Verify that all new objects are clear
On Thu, 14 Feb 2019 at 18:32, Chris Wilson wrote:
>
> The kernel must not return stale information back to userspace when they
> create a new object. For that purpose, we always clear objects on
> creation, so verify that this is so.
>
> Signed-off-by: Chris Wilson
> Cc: Matthew Auld
> ---
> tests/i915/gem_create.c | 71 +
> 1 file changed, 71 insertions(+)
>
> diff --git a/tests/i915/gem_create.c b/tests/i915/gem_create.c
> index 25c5e8088..9de2263d5 100644
> --- a/tests/i915/gem_create.c
> +++ b/tests/i915/gem_create.c
> @@ -44,6 +44,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -141,6 +142,73 @@ static void invalid_nonaligned_size(int fd)
> gem_close(fd, handle);
> }
>
> +static uint64_t get_npages(uint64_t *global, uint64_t npages)
> +{
> + uint64_t try, old, max;
> +
> + max = *global;
> + do {
> + old = max;
> + try = npages % (max / 2);
> + max -= try;
> + } while ((max = __sync_val_compare_and_swap(global, old, max)) !=
> old);
> +
> + return try;
> +}
> +
> +struct thread_clear {
> + uint64_t max;
> + int timeout;
> + int i915;
> +};
> +
> +static void *thread_clear(void *data)
> +{
> + struct thread_clear *arg = data;
> + int i915 = arg->i915;
> +
> + igt_until_timeout(arg->timeout) {
> + uint32_t handle;
> + uint64_t npages;
> +
> + npages = random();
> + npages <<= 32;
> + npages |= random();
> + npages = get_npages(>max, npages);
> +
> + handle = gem_create(i915, npages << 12);
> + for (uint64_t page = 0; page < npages; page++) {
> + uint64_t x;
> +
> + gem_read(i915, handle,
> + page % (4096 - sizeof(x)),
> + , sizeof(x));
Don't we also want to read some values outside of the first page, or
am I missing something?
> + igt_assert_eq_u64(x, 0);
> + }
> + gem_close(i915, handle);
> +
> + __sync_add_and_fetch(>max, npages);
> + }
> +
> + return NULL;
> +}
> +
> +static void always_clear(int i915, int timeout)
> +{
> + struct thread_clear arg = {
> + .i915 = i915,
> + .timeout = timeout,
> + .max = intel_get_avail_ram_mb() << (20 - 12), /* in pages */
> + };
> + const int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
> + pthread_t thread[ncpus];
> +
> + for (int i = 0; i < ncpus; i++)
> + pthread_create([i], NULL, thread_clear, );
> + for (int i = 0; i < ncpus; i++)
> + pthread_join(thread[i], NULL);
> +}
> +
> igt_main
> {
> int fd = -1;
> @@ -162,4 +230,7 @@ igt_main
>
> igt_subtest("create-invalid-nonaligned")
> invalid_nonaligned_size(fd);
> +
> + igt_subtest("create-clear")
> + always_clear(fd, 30);
> }
> --
> 2.20.1
>
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_exec_schedule: Switch bach to gem_set_domain()
The write hazard lies extend also to the cache-dirty tracking; as we
purposefully do not tell the kernel we are writing to the bo, it fails
to note the CPU cache as dirty and so the gem_read() may not
sufficiently flush the caches prior to reading back from the GPU.
Signed-off-by: Chris Wilson
Cc: Antonio Argenziano
---
tests/i915/gem_exec_schedule.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index 59102b6bc..a9383000a 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -54,7 +54,8 @@ uint32_t __sync_read_u32(int fd, uint32_t handle, uint64_t
offset)
{
uint32_t value;
- gem_sync(fd, handle); /* No write hazard lies! */
+ gem_set_domain(fd, handle, /* No write hazard lies! */
+ I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
gem_read(fd, handle, offset, , sizeof(value));
return value;
@@ -63,7 +64,8 @@ uint32_t __sync_read_u32(int fd, uint32_t handle, uint64_t
offset)
static inline
void __sync_read_u32_count(int fd, uint32_t handle, uint32_t *dst, uint64_t
size)
{
- gem_sync(fd, handle); /* No write hazard lies! */
+ gem_set_domain(fd, handle, /* No write hazard lies! */
+ I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
gem_read(fd, handle, 0, dst, size);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/9] drm/i915: Make user contexts bannable again! (rev2)
== Series Details ==
Series: series starting with [1/9] drm/i915: Make user contexts bannable again!
(rev2)
URL : https://patchwork.freedesktop.org/series/56809/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5617 -> Patchwork_12240
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/56809/revisions/2/mbox/
Known issues
Here are the changes found in Patchwork_12240 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@i915_selftest@live_execlists:
- fi-apl-guc: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: PASS -> FAIL [fdo#109485]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
* igt@pm_rpm@basic-rte:
- fi-bsw-kefka: PASS -> FAIL [fdo#108800]
Possible fixes
* igt@i915_selftest@live_evict:
- fi-bsw-kefka: DMESG-WARN [fdo#107709] -> PASS
* igt@kms_pipe_crc_basic@read-crc-pipe-a:
- fi-byt-clapper: FAIL [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109294]: https://bugs.freedesktop.org/show_bug.cgi?id=109294
[fdo#109309]: https://bugs.freedesktop.org/show_bug.cgi?id=109309
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#109316]: https://bugs.freedesktop.org/show_bug.cgi?id=109316
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
[fdo#109527]: https://bugs.freedesktop.org/show_bug.cgi?id=109527
[fdo#109528]: https://bugs.freedesktop.org/show_bug.cgi?id=109528
[fdo#109530]: https://bugs.freedesktop.org/show_bug.cgi?id=109530
[fdo#109635 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109635
Participating hosts (37 -> 36)
--
Additional (4): fi-icl-y fi-glk-j4005 fi-icl-u2 fi-whl-u
Missing(5): fi-kbl-soraka fi-ilk-m540 fi-byt-j1900 fi-byt-squawks
fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5617 -> Patchwork_12240
CI_DRM_5617: 75d902e598dbb8f95b42abc70dfcf41d275f478f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4833: 7802324e86ddf947cba847e910f75b1a8affe8d7 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12240: 3be34136a0eb1a3262399e2b7478074dededbb6a @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
3be34136a0eb drm/i915: Trim delays for wedging
f6b521db8e4e drm/i915: Trim i915_do_reset() to minimum delays
d1862023dd64 drm/i915: Reorder struct_mutex-vs-reset_lock in i915_gem_fault()
258f897a1c79 drm/i915: Avoid reset lock in writing fence registers
655613b3ee20 drm/i915: Move verify_wm_state() to heap
ee4d03caf0ea drm/i915/selftests: Move local mock_ggtt allocations to the heap
dad779ca76b6 drm/i915: Optionally disable automatic recovery after a GPU reset
801c337002f2 drm/i915: Prevent user context creation while wedged
f1a2277064d5 drm/i915: Make user contexts bannable again!
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12240/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/9] drm/i915: Make user contexts bannable again! (rev2)
== Series Details == Series: series starting with [1/9] drm/i915: Make user contexts bannable again! (rev2) URL : https://patchwork.freedesktop.org/series/56809/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Make user contexts bannable again! Okay! Commit: drm/i915: Prevent user context creation while wedged Okay! Commit: drm/i915: Optionally disable automatic recovery after a GPU reset Okay! Commit: drm/i915/selftests: Move local mock_ggtt allocations to the heap Okay! Commit: drm/i915: Move verify_wm_state() to heap Okay! Commit: drm/i915: Avoid reset lock in writing fence registers Okay! Commit: drm/i915: Reorder struct_mutex-vs-reset_lock in i915_gem_fault() -O:drivers/gpu/drm/i915/i915_gem.c:1898:32: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem.c:1898:32: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem.c:1898:32: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem.c:1898:32: warning: expression using sizeof(void) Commit: drm/i915: Trim i915_do_reset() to minimum delays Okay! Commit: drm/i915: Trim delays for wedging Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/9] drm/i915: Make user contexts bannable again! (rev2)
== Series Details ==
Series: series starting with [1/9] drm/i915: Make user contexts bannable again!
(rev2)
URL : https://patchwork.freedesktop.org/series/56809/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f1a2277064d5 drm/i915: Make user contexts bannable again!
801c337002f2 drm/i915: Prevent user context creation while wedged
dad779ca76b6 drm/i915: Optionally disable automatic recovery after a GPU reset
-:20: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#20:
References:
https://lists.freedesktop.org/archives/mesa-dev/2019-February/215431.html
total: 0 errors, 1 warnings, 0 checks, 96 lines checked
ee4d03caf0ea drm/i915/selftests: Move local mock_ggtt allocations to the heap
655613b3ee20 drm/i915: Move verify_wm_state() to heap
258f897a1c79 drm/i915: Avoid reset lock in writing fence registers
-:23: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#23:
<4> [125.739679] a730190a
(_priv->gpu_error.reset_backoff_srcu){+.+.}, at:
i915_reset_trylock+0x0/0x310 [i915]
total: 0 errors, 1 warnings, 0 checks, 26 lines checked
d1862023dd64 drm/i915: Reorder struct_mutex-vs-reset_lock in i915_gem_fault()
f6b521db8e4e drm/i915: Trim i915_do_reset() to minimum delays
-:21: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.txt
#21: FILE: drivers/gpu/drm/i915/i915_reset.c:165:
+ udelay(20);
-:27: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.txt
#27: FILE: drivers/gpu/drm/i915/i915_reset.c:170:
+ udelay(20);
total: 0 errors, 0 warnings, 2 checks, 14 lines checked
3be34136a0eb drm/i915: Trim delays for wedging
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/9] drm/i915: Make user contexts bannable again!
== Series Details ==
Series: series starting with [1/9] drm/i915: Make user contexts bannable again!
URL : https://patchwork.freedesktop.org/series/56809/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5616 -> Patchwork_12239
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/56809/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12239 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-byt-clapper: PASS -> INCOMPLETE [fdo#102657]
* igt@pm_rpm@module-reload:
- fi-skl-6260u: PASS -> INCOMPLETE [fdo#107807]
Possible fixes
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@i915_selftest@live_execlists:
- fi-apl-guc: INCOMPLETE [fdo#103927] -> PASS
- {fi-icl-y}: INCOMPLETE [fdo#109567] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102657]: https://bugs.freedesktop.org/show_bug.cgi?id=102657
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107807]: https://bugs.freedesktop.org/show_bug.cgi?id=107807
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109567]: https://bugs.freedesktop.org/show_bug.cgi?id=109567
Participating hosts (40 -> 36)
--
Additional (1): fi-glk-j4005
Missing(5): fi-kbl-soraka fi-ilk-m540 fi-bsw-n3050 fi-byt-squawks
fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5616 -> Patchwork_12239
CI_DRM_5616: 3479bf1d93b4e556be2804ff39ad41293fc48e4f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4833: 7802324e86ddf947cba847e910f75b1a8affe8d7 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12239: 1b1e5512337ec75d9db7e58615cdf4b47b71d826 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
1b1e5512337e drm/i915: Trim delays for wedging
28f9b341fa1d drm/i915: Trim i915_do_reset() to minimum delays
b3e220ab636d drm/i915: Reorder struct_mutex-vs-reset_lock in i915_gem_fault()
3dc9280a028c drm/i915: Avoid reset lock in writing fence registers
cca5b459de06 drm/i915: Move verify_wm_state() to heap
fc8819eea289 drm/i915/selftests: Move local mock_ggtt allocations to the heap
1105d9066d77 drm/i915: Optionally disable automatic recovery after a GPU reset
0bad7186178e drm/i915: Prevent user context creation while wedged
b5b63e011d58 drm/i915: Make user contexts bannable again!
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12239/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Optionally disable automatic recovery after a GPU reset
Some clients, such as mesa, may only emit minimal incremental batches
that rely on the logical context state from previous batches. They know
that recovery is impossible after a hang as their required GPU state is
lost, and that each in flight and subsequent batch will hang (resetting
the context image back to default perpetuating the problem).
To avoid getting into the state in the first place, we can allow clients
to opt out of automatic recovery and elect to ban any guilty context
following a hang. This prevents the continual stream of hangs and allows
the client to recreate their context and rebuild the state from scratch.
v2: Prefer calling it recoverable rather than unrecoverable.
References:
https://lists.freedesktop.org/archives/mesa-dev/2019-February/215431.html
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
Acked-by: Kenneth Graunke # for mesa
---
Fixup setting args->size = 0 (silent rebase error).
---
drivers/gpu/drm/i915/i915_gem_context.c | 15 ++-
drivers/gpu/drm/i915/i915_gem_context.h | 16
drivers/gpu/drm/i915/i915_reset.c | 3 ++-
include/uapi/drm/i915_drm.h | 20
4 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index f6c48274fafb..7fdc273bd57c 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -364,7 +364,7 @@ __create_hw_context(struct drm_i915_private *dev_priv,
list_add_tail(>link, _priv->contexts.list);
ctx->i915 = dev_priv;
ctx->sched.priority = I915_USER_PRIORITY(I915_PRIORITY_NORMAL);
- ctx->user_flags = BIT(UCONTEXT_BANNABLE);
+ ctx->user_flags = BIT(UCONTEXT_BANNABLE) | BIT(UCONTEXT_RECOVERABLE);
for (n = 0; n < ARRAY_SIZE(ctx->__engine); n++)
intel_context_init(>__engine[n], ctx, dev_priv->engine[n]);
@@ -957,6 +957,10 @@ int i915_gem_context_getparam_ioctl(struct drm_device
*dev, void *data,
args->size = 0;
args->value = i915_gem_context_is_bannable(ctx);
break;
+ case I915_CONTEXT_PARAM_RECOVERABLE:
+ args->size = 0;
+ args->value = i915_gem_context_is_recoverable(ctx);
+ break;
case I915_CONTEXT_PARAM_PRIORITY:
args->size = 0;
args->value = ctx->sched.priority >> I915_USER_PRIORITY_SHIFT;
@@ -1291,6 +1295,15 @@ int i915_gem_context_setparam_ioctl(struct drm_device
*dev, void *data,
i915_gem_context_clear_bannable(ctx);
break;
+ case I915_CONTEXT_PARAM_RECOVERABLE:
+ if (args->size)
+ ret = -EINVAL;
+ else if (args->value)
+ i915_gem_context_set_recoverable(ctx);
+ else
+ i915_gem_context_clear_recoverable(ctx);
+ break;
+
case I915_CONTEXT_PARAM_PRIORITY:
{
s64 priority = args->value;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index ca150a764c24..071108d34ae0 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -134,6 +134,7 @@ struct i915_gem_context {
#define UCONTEXT_NO_ZEROMAP0
#define UCONTEXT_NO_ERROR_CAPTURE 1
#define UCONTEXT_BANNABLE 2
+#define UCONTEXT_RECOVERABLE 3
/**
* @flags: small set of booleans
@@ -270,6 +271,21 @@ static inline void i915_gem_context_clear_bannable(struct
i915_gem_context *ctx)
clear_bit(UCONTEXT_BANNABLE, >user_flags);
}
+static inline bool i915_gem_context_is_recoverable(const struct
i915_gem_context *ctx)
+{
+ return test_bit(UCONTEXT_RECOVERABLE, >user_flags);
+}
+
+static inline void i915_gem_context_set_recoverable(struct i915_gem_context
*ctx)
+{
+ set_bit(UCONTEXT_RECOVERABLE, >user_flags);
+}
+
+static inline void i915_gem_context_clear_recoverable(struct i915_gem_context
*ctx)
+{
+ clear_bit(UCONTEXT_RECOVERABLE, >user_flags);
+}
+
static inline bool i915_gem_context_is_banned(const struct i915_gem_context
*ctx)
{
return test_bit(CONTEXT_BANNED, >flags);
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index a6fb6754f621..a171465b1c04 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -66,7 +66,8 @@ static bool context_mark_guilty(struct i915_gem_context *ctx)
bannable = i915_gem_context_is_bannable(ctx);
score = atomic_add_return(CONTEXT_SCORE_GUILTY, >ban_score);
- banned = score >= CONTEXT_SCORE_BAN_THRESHOLD;
+ banned = (!i915_gem_context_is_recoverable(ctx) ||
+ score >= CONTEXT_SCORE_BAN_THRESHOLD);
/* Cool
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/9] drm/i915: Make user contexts bannable again!
== Series Details == Series: series starting with [1/9] drm/i915: Make user contexts bannable again! URL : https://patchwork.freedesktop.org/series/56809/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Make user contexts bannable again! Okay! Commit: drm/i915: Prevent user context creation while wedged Okay! Commit: drm/i915: Optionally disable automatic recovery after a GPU reset Okay! Commit: drm/i915/selftests: Move local mock_ggtt allocations to the heap Okay! Commit: drm/i915: Move verify_wm_state() to heap Okay! Commit: drm/i915: Avoid reset lock in writing fence registers Okay! Commit: drm/i915: Reorder struct_mutex-vs-reset_lock in i915_gem_fault() -O:drivers/gpu/drm/i915/i915_gem.c:1898:32: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem.c:1898:32: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem.c:1898:32: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem.c:1898:32: warning: expression using sizeof(void) Commit: drm/i915: Trim i915_do_reset() to minimum delays Okay! Commit: drm/i915: Trim delays for wedging Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/9] drm/i915: Make user contexts bannable again!
== Series Details ==
Series: series starting with [1/9] drm/i915: Make user contexts bannable again!
URL : https://patchwork.freedesktop.org/series/56809/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b5b63e011d58 drm/i915: Make user contexts bannable again!
0bad7186178e drm/i915: Prevent user context creation while wedged
1105d9066d77 drm/i915: Optionally disable automatic recovery after a GPU reset
-:20: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#20:
References:
https://lists.freedesktop.org/archives/mesa-dev/2019-February/215431.html
total: 0 errors, 1 warnings, 0 checks, 95 lines checked
fc8819eea289 drm/i915/selftests: Move local mock_ggtt allocations to the heap
cca5b459de06 drm/i915: Move verify_wm_state() to heap
3dc9280a028c drm/i915: Avoid reset lock in writing fence registers
-:23: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#23:
<4> [125.739679] a730190a
(_priv->gpu_error.reset_backoff_srcu){+.+.}, at:
i915_reset_trylock+0x0/0x310 [i915]
total: 0 errors, 1 warnings, 0 checks, 26 lines checked
b3e220ab636d drm/i915: Reorder struct_mutex-vs-reset_lock in i915_gem_fault()
28f9b341fa1d drm/i915: Trim i915_do_reset() to minimum delays
-:21: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.txt
#21: FILE: drivers/gpu/drm/i915/i915_reset.c:165:
+ udelay(20);
-:27: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.txt
#27: FILE: drivers/gpu/drm/i915/i915_reset.c:170:
+ udelay(20);
total: 0 errors, 0 warnings, 2 checks, 14 lines checked
1b1e5512337e drm/i915: Trim delays for wedging
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/9] drm/i915: Prevent user context creation while wedged
Introduce a new ABI method for detecting a wedged driver by reporting
-EIO from DRM_IOCTL_I915_GEM_CONTEXT_CREATE.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_context.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 102866967998..f6c48274fafb 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -797,18 +797,23 @@ static bool client_is_banned(struct drm_i915_file_private
*file_priv)
int i915_gem_context_create_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_i915_private *i915 = to_i915(dev);
struct drm_i915_gem_context_create *args = data;
struct drm_i915_file_private *file_priv = file->driver_priv;
struct i915_gem_context *ctx;
int ret;
- if (!DRIVER_CAPS(dev_priv)->has_logical_contexts)
+ if (!DRIVER_CAPS(i915)->has_logical_contexts)
return -ENODEV;
if (args->pad != 0)
return -EINVAL;
+ if (i915_terminally_wedged(>gpu_error)) {
+ DRM_DEBUG("driver is wedged; banning new ctx!\n");
+ return -EIO;
+ }
+
if (client_is_banned(file_priv)) {
DRM_DEBUG("client %s[%d] banned from creating ctx\n",
current->comm,
@@ -821,7 +826,7 @@ int i915_gem_context_create_ioctl(struct drm_device *dev,
void *data,
if (ret)
return ret;
- ctx = i915_gem_create_context(dev_priv, file_priv);
+ ctx = i915_gem_create_context(i915, file_priv);
mutex_unlock(>struct_mutex);
if (IS_ERR(ctx))
return PTR_ERR(ctx);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/9] drm/i915/selftests: Move local mock_ggtt allocations to the heap
This struct appears quite large and pushes our stack frame over
1024 bytes -- too high for conservative setups. So move the mock_ggtt
struct to the heap.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 15 ++-
drivers/gpu/drm/i915/selftests/i915_vma.c | 15 ++-
2 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index 3850ef4a5ec8..73aafcb4c673 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -1681,25 +1681,30 @@ int i915_gem_gtt_mock_selftests(void)
SUBTEST(igt_gtt_insert),
};
struct drm_i915_private *i915;
- struct i915_ggtt ggtt;
+ struct i915_ggtt *ggtt;
int err;
i915 = mock_gem_device();
if (!i915)
return -ENOMEM;
- mock_init_ggtt(i915, );
+ ggtt = kmalloc(sizeof(*ggtt), GFP_KERNEL);
+ if (!ggtt) {
+ err = -ENOMEM;
+ goto out_put;
+ }
+ mock_init_ggtt(i915, ggtt);
mutex_lock(>drm.struct_mutex);
- err = i915_subtests(tests, );
+ err = i915_subtests(tests, ggtt);
mock_device_flush(i915);
mutex_unlock(>drm.struct_mutex);
i915_gem_drain_freed_objects(i915);
- mock_fini_ggtt();
+ mock_fini_ggtt(ggtt);
+out_put:
drm_dev_put(>drm);
-
return err;
}
diff --git a/drivers/gpu/drm/i915/selftests/i915_vma.c
b/drivers/gpu/drm/i915/selftests/i915_vma.c
index cf1de82741fa..4a1c8575e425 100644
--- a/drivers/gpu/drm/i915/selftests/i915_vma.c
+++ b/drivers/gpu/drm/i915/selftests/i915_vma.c
@@ -725,24 +725,29 @@ int i915_vma_mock_selftests(void)
SUBTEST(igt_vma_partial),
};
struct drm_i915_private *i915;
- struct i915_ggtt ggtt;
+ struct i915_ggtt *ggtt;
int err;
i915 = mock_gem_device();
if (!i915)
return -ENOMEM;
- mock_init_ggtt(i915, );
+ ggtt = kmalloc(sizeof(*ggtt), GFP_KERNEL);
+ if (!ggtt) {
+ err = -ENOMEM;
+ goto out_put;
+ }
+ mock_init_ggtt(i915, ggtt);
mutex_lock(>drm.struct_mutex);
- err = i915_subtests(tests, );
+ err = i915_subtests(tests, ggtt);
mock_device_flush(i915);
mutex_unlock(>drm.struct_mutex);
i915_gem_drain_freed_objects(i915);
- mock_fini_ggtt();
+ mock_fini_ggtt(ggtt);
+out_put:
drm_dev_put(>drm);
-
return err;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/9] drm/i915: Avoid reset lock in writing fence registers
The idea of taking the reset lock around writing the fence register was
to serialise the mmio write we also perform during the reset where those
registers get clobbered. However, the lock is overkill as write tearing
between reset and fence_update() is harmless; the final value of the
fence register is the same. A race between revoke_fences() and
fence_update() is also harmless at this point as on the fault path where
this is necessary, we acquire the reset lock to coordinate ourselves in
the upper layer.
The danger of acquiring the reset lock again in fence_update() is that
we may recurse from the shrinker along the i915_gem_fault() path.
<4> [125.739646]
<4> [125.739652] WARNING: possible recursive locking detected
<4> [125.739659] 5.0.0-rc6-ga6e4cbf00557-drmtip_223+ #1 Tainted: G U
<4> [125.739666]
<4> [125.739672] gem_mmap_gtt/1017 is trying to acquire lock:
<4> [125.739679] a730190a
(_priv->gpu_error.reset_backoff_srcu){+.+.}, at:
i915_reset_trylock+0x0/0x310 [i915]
<4> [125.739848]
but task is already holding lock:
<4> [125.739854] a730190a
(_priv->gpu_error.reset_backoff_srcu){+.+.}, at:
i915_reset_trylock+0x192/0x310 [i915]
<4> [125.739918]
other info that might help us debug this:
<4> [125.739925] Possible unsafe locking scenario:
<4> [125.739930]CPU0
<4> [125.739934]
<4> [125.739937] lock(_priv->gpu_error.reset_backoff_srcu);
<4> [125.739944] lock(_priv->gpu_error.reset_backoff_srcu);
<4> [125.739950]
*** DEADLOCK ***
<4> [125.739958] May be due to missing lock nesting notation
<4> [125.739966] 5 locks held by gem_mmap_gtt/1017:
<4> [125.739972] #0: 471f682c (>mmap_sem){}, at:
__do_page_fault+0x133/0x500
<4> [125.739987] #1: 26542685 (>struct_mutex){+.+.}, at:
i915_gem_fault+0x1f6/0x860 [i915]
<4> [125.740061] #2: a730190a
(_priv->gpu_error.reset_backoff_srcu){+.+.}, at:
i915_reset_trylock+0x192/0x310 [i915]
<4> [125.740126] #3: c828eb4f (fs_reclaim){+.+.}, at:
fs_reclaim_acquire.part.25+0x0/0x30
<4> [125.740140] #4: 2d360d65 (shrinker_rwsem){}, at:
shrink_slab+0x1cb/0x2c0
<4> [125.740151]
stack backtrace:
<4> [125.740159] CPU: 1 PID: 1017 Comm: gem_mmap_gtt Tainted: G U
5.0.0-rc6-ga6e4cbf00557-drmtip_223+ #1
<4> [125.740170] Hardware name: Dell Inc. OptiPlex 745
/0GW726, BIOS 2.3.1 05/21/2007
<4> [125.740180] Call Trace:
<4> [125.740189] dump_stack+0x67/0x9b
<4> [125.740199] __lock_acquire+0xc75/0x1b00
<4> [125.740209] ? arch_tlb_finish_mmu+0x2a/0xa0
<4> [125.740216] ? tlb_finish_mmu+0x1a/0x30
<4> [125.740222] ? zap_page_range_single+0xe2/0x130
<4> [125.740230] ? lock_acquire+0xa6/0x1c0
<4> [125.740237] lock_acquire+0xa6/0x1c0
<4> [125.740296] ? i915_clear_error_registers+0x280/0x280 [i915]
<4> [125.740357] i915_reset_trylock+0x44/0x310 [i915]
<4> [125.740417] ? i915_clear_error_registers+0x280/0x280 [i915]
<4> [125.740426] ? lockdep_hardirqs_on+0xe0/0x1b0
<4> [125.740434] ? _raw_spin_unlock_irqrestore+0x39/0x60
<4> [125.740499] fence_update+0x218/0x470 [i915]
<4> [125.740571] i915_vma_unbind+0xa6/0x550 [i915]
<4> [125.740640] i915_gem_object_unbind+0xfa/0x190 [i915]
<4> [125.740711] i915_gem_shrink+0x2dc/0x590 [i915]
<4> [125.740722] ? ___preempt_schedule+0x16/0x18
<4> [125.740792] ? i915_gem_shrinker_scan+0xc9/0x130 [i915]
<4> [125.740861] i915_gem_shrinker_scan+0xc9/0x130 [i915]
<4> [125.740870] do_shrink_slab+0x143/0x3f0
<4> [125.740878] shrink_slab+0x228/0x2c0
<4> [125.740886] shrink_node+0x167/0x450
<4> [125.740894] do_try_to_free_pages+0xc4/0x340
<4> [125.740902] try_to_free_pages+0xdc/0x2e0
<4> [125.740911] __alloc_pages_nodemask+0x662/0x1110
<4> [125.740921] ? reacquire_held_locks+0xb5/0x1b0
<4> [125.740928] ? reacquire_held_locks+0xb5/0x1b0
<4> [125.740986] ? i915_reset_trylock+0x192/0x310 [i915]
<4> [125.741045] ? i915_memcpy_init_early+0x30/0x30 [i915]
<4> [125.741054] pte_alloc_one+0x12/0x70
<4> [125.741060] __pte_alloc+0x11/0xf0
<4> [125.741067] apply_to_page_range+0x37e/0x440
<4> [125.741127] remap_io_mapping+0x6c/0x100 [i915]
<4> [125.741196] i915_gem_fault+0x5a9/0x860 [i915]
<4> [125.741204] ? ptlock_alloc+0x15/0x30
<4> [125.741212] __do_fault+0x2c/0xb0
<4> [125.741218] __handle_mm_fault+0x8ee/0xfa0
<4> [125.741227] handle_mm_fault+0x196/0x3a0
<4> [125.741235] __do_page_fault+0x246/0x500
<4> [125.741243] ? page_fault+0x8/0x30
<4> [125.741250] page_fault+0x1e/0x30
<4> [125.741256] RIP: 0033:0x55d0cc456e12
<4> [125.741264] Code: b0 df ff ff 89 c2 8b 85 70 df ff ff 01 c2 8b 85 70 df ff
ff 48 98 48 8d 0c 85 00 00 00 00 48 8b 85 e0 df ff ff 48 01 c8 f7 d2 <89> 10 83
85 70 df ff ff 01 81 bd 70 df ff ff ff 03 00 00 7e be 48
<4> [125.741280] RSP: 002b:7ffc1bab7ab0 EFLAGS: 00010206
<4> [125.741287] RAX: 7fc787cb6000 RBX: RCX:
<4> [125.741295] RDX:
[Intel-gfx] [PATCH 9/9] drm/i915: Trim delays for wedging
CI still reports the occasional multi-second delay for resets, in particular along the wedge+recovery paths. As the likely, and unbounded, delay here is from sync_rcu, use the expedited variant instead. Testcase: igt/gem_eio/unwedge-stress Signed-off-by: Chris Wilson Cc: Mika Kuoppala --- drivers/gpu/drm/i915/i915_reset.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_reset.c b/drivers/gpu/drm/i915/i915_reset.c index 280f0e35cb3d..c334089a7476 100644 --- a/drivers/gpu/drm/i915/i915_reset.c +++ b/drivers/gpu/drm/i915/i915_reset.c @@ -830,7 +830,7 @@ static void __i915_gem_set_wedged(struct drm_i915_private *i915) * either this call here to intel_engine_write_global_seqno, or the one * in nop_submit_request. */ - synchronize_rcu(); + synchronize_rcu_expedited(); /* Mark all executing requests as skipped */ for_each_engine(engine, i915, id) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/9] drm/i915: Trim i915_do_reset() to minimum delays
Remove the "safety-factor" in our udelays for i915_do_reset(). If we are told to hold the line high for 20us, do it only for 20us plus the tiny bit of udelay latency. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_reset.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reset.c b/drivers/gpu/drm/i915/i915_reset.c index 1911e00d2581..280f0e35cb3d 100644 --- a/drivers/gpu/drm/i915/i915_reset.c +++ b/drivers/gpu/drm/i915/i915_reset.c @@ -162,12 +162,12 @@ static int i915_do_reset(struct drm_i915_private *i915, /* Assert reset for at least 20 usec, and wait for acknowledgement. */ pci_write_config_byte(pdev, I915_GDRST, GRDOM_RESET_ENABLE); - udelay(50); + udelay(20); err = wait_for_atomic(i915_in_reset(pdev), 50); /* Clear the reset request. */ pci_write_config_byte(pdev, I915_GDRST, 0); - udelay(50); + udelay(20); if (!err) err = wait_for_atomic(!i915_in_reset(pdev), 50); -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/9] drm/i915: Move verify_wm_state() to heap
The stack usage exceeded 1024 bytes prompting warnings on conservative
setups, so move the temporary allocation for HW readback onto the heap.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 48 ++--
1 file changed, 31 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index afa21daaae51..e10cab1c8c65 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12230,12 +12230,15 @@ static void verify_wm_state(struct drm_crtc *crtc,
struct drm_crtc_state *new_state)
{
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
- struct skl_ddb_allocation hw_ddb, *sw_ddb;
- struct skl_pipe_wm hw_wm, *sw_wm;
- struct skl_plane_wm *hw_plane_wm, *sw_plane_wm;
+ struct skl_hw_state {
+ struct skl_ddb_entry ddb_y[I915_MAX_PLANES];
+ struct skl_ddb_entry ddb_uv[I915_MAX_PLANES];
+ struct skl_ddb_allocation ddb;
+ struct skl_pipe_wm wm;
+ } *hw;
+ struct skl_ddb_allocation *sw_ddb;
+ struct skl_pipe_wm *sw_wm;
struct skl_ddb_entry *hw_ddb_entry, *sw_ddb_entry;
- struct skl_ddb_entry hw_ddb_y[I915_MAX_PLANES];
- struct skl_ddb_entry hw_ddb_uv[I915_MAX_PLANES];
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
const enum pipe pipe = intel_crtc->pipe;
int plane, level, max_level = ilk_wm_max_level(dev_priv);
@@ -12243,22 +12246,29 @@ static void verify_wm_state(struct drm_crtc *crtc,
if (INTEL_GEN(dev_priv) < 9 || !new_state->active)
return;
- skl_pipe_wm_get_hw_state(intel_crtc, _wm);
+ hw = kzalloc(sizeof(*hw), GFP_KERNEL);
+ if (!hw)
+ return;
+
+ skl_pipe_wm_get_hw_state(intel_crtc, >wm);
sw_wm = _intel_crtc_state(new_state)->wm.skl.optimal;
- skl_pipe_ddb_get_hw_state(intel_crtc, hw_ddb_y, hw_ddb_uv);
+ skl_pipe_ddb_get_hw_state(intel_crtc, hw->ddb_y, hw->ddb_uv);
- skl_ddb_get_hw_state(dev_priv, _ddb);
+ skl_ddb_get_hw_state(dev_priv, >ddb);
sw_ddb = _priv->wm.skl_hw.ddb;
- if (INTEL_GEN(dev_priv) >= 11)
- if (hw_ddb.enabled_slices != sw_ddb->enabled_slices)
- DRM_ERROR("mismatch in DBUF Slices (expected %u, got
%u)\n",
- sw_ddb->enabled_slices,
- hw_ddb.enabled_slices);
+ if (INTEL_GEN(dev_priv) >= 11 &&
+ hw->ddb.enabled_slices != sw_ddb->enabled_slices)
+ DRM_ERROR("mismatch in DBUF Slices (expected %u, got %u)\n",
+ sw_ddb->enabled_slices,
+ hw->ddb.enabled_slices);
+
/* planes */
for_each_universal_plane(dev_priv, pipe, plane) {
- hw_plane_wm = _wm.planes[plane];
+ struct skl_plane_wm *hw_plane_wm, *sw_plane_wm;
+
+ hw_plane_wm = >wm.planes[plane];
sw_plane_wm = _wm->planes[plane];
/* Watermarks */
@@ -12290,7 +12300,7 @@ static void verify_wm_state(struct drm_crtc *crtc,
}
/* DDB */
- hw_ddb_entry = _ddb_y[plane];
+ hw_ddb_entry = >ddb_y[plane];
sw_ddb_entry =
_intel_crtc_state(new_state)->wm.skl.plane_ddb_y[plane];
if (!skl_ddb_entry_equal(hw_ddb_entry, sw_ddb_entry)) {
@@ -12308,7 +12318,9 @@ static void verify_wm_state(struct drm_crtc *crtc,
* once the plane becomes visible, we can skip this check
*/
if (1) {
- hw_plane_wm = _wm.planes[PLANE_CURSOR];
+ struct skl_plane_wm *hw_plane_wm, *sw_plane_wm;
+
+ hw_plane_wm = >wm.planes[PLANE_CURSOR];
sw_plane_wm = _wm->planes[PLANE_CURSOR];
/* Watermarks */
@@ -12340,7 +12352,7 @@ static void verify_wm_state(struct drm_crtc *crtc,
}
/* DDB */
- hw_ddb_entry = _ddb_y[PLANE_CURSOR];
+ hw_ddb_entry = >ddb_y[PLANE_CURSOR];
sw_ddb_entry =
_intel_crtc_state(new_state)->wm.skl.plane_ddb_y[PLANE_CURSOR];
if (!skl_ddb_entry_equal(hw_ddb_entry, sw_ddb_entry)) {
@@ -12350,6 +12362,8 @@ static void verify_wm_state(struct drm_crtc *crtc,
hw_ddb_entry->start, hw_ddb_entry->end);
}
}
+
+ kfree(hw);
}
static void
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/9] drm/i915: Reorder struct_mutex-vs-reset_lock in i915_gem_fault()
Annoyingly, struct_mutex was not entirely eliminated from the reset
pathway; for reasons of its own, intel_display_resumes() requires
struct_mutex to prepare the planes it already captured. To avoid the
immediate problem of a deadlock between the struct_mutex and the reset
srcu, we have to acquire the reset_lock before struct_mutex in
i915_gem_fault(). Now any wait underneath struct_mutex will result us in
having to forcibly reset all inflight rendering, less than ideal.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b421bc7a2e26..b3129cb0a04d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1834,9 +1834,15 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
wakeref = intel_runtime_pm_get(dev_priv);
+ srcu = i915_reset_trylock(dev_priv);
+ if (srcu < 0) {
+ ret = srcu;
+ goto err_rpm;
+ }
+
ret = i915_mutex_lock_interruptible(dev);
if (ret)
- goto err_rpm;
+ goto err_reset;
/* Access to snoopable pages through the GTT is incoherent. */
if (obj->cache_level != I915_CACHE_NONE && !HAS_LLC(dev_priv)) {
@@ -1885,12 +1891,6 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
if (ret)
goto err_unpin;
- srcu = i915_reset_trylock(dev_priv);
- if (srcu < 0) {
- ret = srcu;
- goto err_fence;
- }
-
/* Finally, remap it using the new GTT offset */
ret = remap_io_mapping(area,
area->vm_start + (vma->ggtt_view.partial.offset
<< PAGE_SHIFT),
@@ -1898,7 +1898,7 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
min_t(u64, vma->size, area->vm_end -
area->vm_start),
>iomap);
if (ret)
- goto err_reset;
+ goto err_fence;
/* Mark as being mmapped into userspace for later revocation */
assert_rpm_wakelock_held(dev_priv);
@@ -1908,14 +1908,14 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
i915_vma_set_ggtt_write(vma);
-err_reset:
- i915_reset_unlock(dev_priv, srcu);
err_fence:
i915_vma_unpin_fence(vma);
err_unpin:
__i915_vma_unpin(vma);
err_unlock:
mutex_unlock(>struct_mutex);
+err_reset:
+ i915_reset_unlock(dev_priv, srcu);
err_rpm:
intel_runtime_pm_put(dev_priv, wakeref);
i915_gem_object_unpin_pages(obj);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/9] drm/i915: Optionally disable automatic recovery after a GPU reset
Some clients, such as mesa, may only emit minimal incremental batches
that rely on the logical context state from previous batches. They know
that recovery is impossible after a hang as their required GPU state is
lost, and that each in flight and subsequent batch will hang (resetting
the context image back to default perpetuating the problem).
To avoid getting into the state in the first place, we can allow clients
to opt out of automatic recovery and elect to ban any guilty context
following a hang. This prevents the continual stream of hangs and allows
the client to recreate their context and rebuild the state from scratch.
v2: Prefer calling it recoverable rather than unrecoverable.
References:
https://lists.freedesktop.org/archives/mesa-dev/2019-February/215431.html
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
Acked-by: Kenneth Graunke # for mesa
---
drivers/gpu/drm/i915/i915_gem_context.c | 14 +-
drivers/gpu/drm/i915/i915_gem_context.h | 16
drivers/gpu/drm/i915/i915_reset.c | 3 ++-
include/uapi/drm/i915_drm.h | 20
4 files changed, 51 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index f6c48274fafb..b6564f3faf85 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -364,7 +364,7 @@ __create_hw_context(struct drm_i915_private *dev_priv,
list_add_tail(>link, _priv->contexts.list);
ctx->i915 = dev_priv;
ctx->sched.priority = I915_USER_PRIORITY(I915_PRIORITY_NORMAL);
- ctx->user_flags = BIT(UCONTEXT_BANNABLE);
+ ctx->user_flags = BIT(UCONTEXT_BANNABLE) | BIT(UCONTEXT_RECOVERABLE);
for (n = 0; n < ARRAY_SIZE(ctx->__engine); n++)
intel_context_init(>__engine[n], ctx, dev_priv->engine[n]);
@@ -957,6 +957,9 @@ int i915_gem_context_getparam_ioctl(struct drm_device *dev,
void *data,
args->size = 0;
args->value = i915_gem_context_is_bannable(ctx);
break;
+ case I915_CONTEXT_PARAM_RECOVERABLE:
+ args->value = i915_gem_context_is_recoverable(ctx);
+ break;
case I915_CONTEXT_PARAM_PRIORITY:
args->size = 0;
args->value = ctx->sched.priority >> I915_USER_PRIORITY_SHIFT;
@@ -1291,6 +1294,15 @@ int i915_gem_context_setparam_ioctl(struct drm_device
*dev, void *data,
i915_gem_context_clear_bannable(ctx);
break;
+ case I915_CONTEXT_PARAM_RECOVERABLE:
+ if (args->size)
+ ret = -EINVAL;
+ else if (args->value)
+ i915_gem_context_set_recoverable(ctx);
+ else
+ i915_gem_context_clear_recoverable(ctx);
+ break;
+
case I915_CONTEXT_PARAM_PRIORITY:
{
s64 priority = args->value;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
b/drivers/gpu/drm/i915/i915_gem_context.h
index ca150a764c24..071108d34ae0 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -134,6 +134,7 @@ struct i915_gem_context {
#define UCONTEXT_NO_ZEROMAP0
#define UCONTEXT_NO_ERROR_CAPTURE 1
#define UCONTEXT_BANNABLE 2
+#define UCONTEXT_RECOVERABLE 3
/**
* @flags: small set of booleans
@@ -270,6 +271,21 @@ static inline void i915_gem_context_clear_bannable(struct
i915_gem_context *ctx)
clear_bit(UCONTEXT_BANNABLE, >user_flags);
}
+static inline bool i915_gem_context_is_recoverable(const struct
i915_gem_context *ctx)
+{
+ return test_bit(UCONTEXT_RECOVERABLE, >user_flags);
+}
+
+static inline void i915_gem_context_set_recoverable(struct i915_gem_context
*ctx)
+{
+ set_bit(UCONTEXT_RECOVERABLE, >user_flags);
+}
+
+static inline void i915_gem_context_clear_recoverable(struct i915_gem_context
*ctx)
+{
+ clear_bit(UCONTEXT_RECOVERABLE, >user_flags);
+}
+
static inline bool i915_gem_context_is_banned(const struct i915_gem_context
*ctx)
{
return test_bit(CONTEXT_BANNED, >flags);
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index 5a067a4b3d5d..1911e00d2581 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -66,7 +66,8 @@ static bool context_mark_guilty(struct i915_gem_context *ctx)
bannable = i915_gem_context_is_bannable(ctx);
score = atomic_add_return(CONTEXT_SCORE_GUILTY, >ban_score);
- banned = score >= CONTEXT_SCORE_BAN_THRESHOLD;
+ banned = (!i915_gem_context_is_recoverable(ctx) ||
+ score >= CONTEXT_SCORE_BAN_THRESHOLD);
/* Cool contexts don't accumulate client ban score */
if (!bannable)
diff --git
[Intel-gfx] [PATCH 1/9] drm/i915: Make user contexts bannable again!
Since moving the bannable boolean into the context flags, we lost the
default setting of contexts being bannable. Oops.
Sadly because we have multi-level banning scheme, our testcase for being
banned cannot distinguish between the expected ban on the context and
the applied banned via the fd.
Fixes: 6095868a271d ("drm/i915: Complete kerneldoc for struct i915_gem_context")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: # v4.11+
---
drivers/gpu/drm/i915/i915_gem_context.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 280813a4bf82..102866967998 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -364,6 +364,7 @@ __create_hw_context(struct drm_i915_private *dev_priv,
list_add_tail(>link, _priv->contexts.list);
ctx->i915 = dev_priv;
ctx->sched.priority = I915_USER_PRIORITY(I915_PRIORITY_NORMAL);
+ ctx->user_flags = BIT(UCONTEXT_BANNABLE);
for (n = 0; n < ARRAY_SIZE(ctx->__engine); n++)
intel_context_init(>__engine[n], ctx, dev_priv->engine[n]);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 3/8] lib: Restore the i915.reset modparam before cleaning up
We force a reset on test exit so that we can rapidly cleanup after a
naughty test, it is not unknown for us to leave a queue of hanging
batches around. However, if we have also fiddled with the i915.reset
parameter in the meantime, this can leave the kernel unable to fulfil
our request (and those naughty batches continue to disrupt testing).
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Petri Latvala
---
lib/drmtest.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/drmtest.c b/lib/drmtest.c
index 1964795a6..6c0a0e381 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -54,6 +54,7 @@
#include "igt_device.h"
#include "igt_gt.h"
#include "igt_kmod.h"
+#include "igt_sysfs.h"
#include "version.h"
#include "config.h"
#include "intel_reg.h"
@@ -345,6 +346,7 @@ static void __cancel_work_at_exit(int fd)
{
igt_terminate_spin_batches(); /* for older kernels */
+ igt_sysfs_set_parameter(fd, "reset", "%x", -1u /* any method */);
igt_drop_caches_set(fd,
/* cancel everything */
DROP_RESET_ACTIVE | DROP_RESET_SEQNO |
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/8] i915/gem_eio: Check that context create fails when wedged
Lock down the new uABI that DRM_IOCTL_I915_GEM_CONTEXT_CREATE returns
-EIO when wedged.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
tests/i915/gem_eio.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/tests/i915/gem_eio.c b/tests/i915/gem_eio.c
index ac85a2eff..3c54820c9 100644
--- a/tests/i915/gem_eio.c
+++ b/tests/i915/gem_eio.c
@@ -118,6 +118,17 @@ static void test_throttle(int fd)
trigger_reset(fd);
}
+static void test_context_create(int fd)
+{
+ uint32_t ctx;
+
+ wedge_gpu(fd);
+
+ igt_assert_eq(__gem_context_create(fd, ), -EIO);
+
+ trigger_reset(fd);
+}
+
static void test_execbuf(int fd)
{
struct drm_i915_gem_execbuffer2 execbuf;
@@ -807,6 +818,9 @@ igt_main
igt_subtest("throttle")
test_throttle(fd);
+ igt_subtest("context-create")
+ test_context_create(fd);
+
igt_subtest("execbuf")
test_execbuf(fd);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/8] i915/gem_eio: Check we only ban the context
In trigger the ban, we only want to observe the local context be banned
and not the fpriv as a whole.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
tests/i915/gem_eio.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tests/i915/gem_eio.c b/tests/i915/gem_eio.c
index 3c54820c9..3afdbd69e 100644
--- a/tests/i915/gem_eio.c
+++ b/tests/i915/gem_eio.c
@@ -324,8 +324,15 @@ static void __test_banned(int fd)
igt_spin_t *hang;
if (__gem_execbuf(fd, ) == -EIO) {
+ uint32_t ctx = 0;
+
igt_info("Banned after causing %lu hangs\n", count);
igt_assert(count > 1);
+
+ /* Only this context, not the file, should be banned */
+ igt_assert_neq(__gem_context_create(fd, ), -EIO);
+ igt_assert_neq(ctx, 0);
+ gem_context_destroy(fd, ctx);
return;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 8/8] kms_fence_pin_leak: Move beneath i915/
kms_fence_pin_leak tests smooth sharp edges that are i915 specific (and
requires using GEM to do so). It doesn't belong in the general paddock
of all driver tests, so move it into the i915/ stable.
Signed-off-by: Chris Wilson
Cc: Arkadiusz Hiler
Cc: Petri Latvala
Acked-by: Petri Latvala
---
tests/Makefile.sources| 5 -
tests/{ => i915}/kms_fence_pin_leak.c | 0
tests/meson.build | 2 +-
3 files changed, 5 insertions(+), 2 deletions(-)
rename tests/{ => i915}/kms_fence_pin_leak.c (100%)
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index d2c4f9fe9..9972b2dd1 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -40,7 +40,6 @@ TESTS_progs = \
kms_dp_dsc \
kms_draw_crc \
kms_fbcon_fbt \
- kms_fence_pin_leak \
kms_flip \
kms_flip_event_leak \
kms_flip_tiling \
@@ -99,6 +98,10 @@ TESTS_progs = \
vgem_slow \
$(NULL)
+TESTS_progs += \
+ i915/kms_fence_pin_leak \
+ $(NULL)
+
TESTS_progs += gem_bad_reloc
gem_bad_reloc_SOURCES = i915/gem_bad_reloc.c
diff --git a/tests/kms_fence_pin_leak.c b/tests/i915/kms_fence_pin_leak.c
similarity index 100%
rename from tests/kms_fence_pin_leak.c
rename to tests/i915/kms_fence_pin_leak.c
diff --git a/tests/meson.build b/tests/meson.build
index ec980651a..08e55b9c0 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -27,7 +27,6 @@ test_progs = [
'kms_dp_dsc',
'kms_draw_crc',
'kms_fbcon_fbt',
- 'kms_fence_pin_leak',
'kms_flip',
'kms_flip_event_leak',
'kms_flip_tiling',
@@ -100,6 +99,7 @@ i915_progs = [
'fb_tiling',
'getparams_basic',
'hangman',
+ 'kms_fence_pin_leak',
'missed_irq',
'module_load',
'query',
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 5/8] i915/gem_exec_big: Add a single shot test
CI complains that the exhaustive test of trying every size up to the
limit is too slow, so add a simple test that tries to submit one
extreme batch buffer and check all the relocations land.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=10
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_big.c| 70 ++--
tests/intel-ci/blacklist.txt | 1 +
2 files changed, 60 insertions(+), 11 deletions(-)
diff --git a/tests/i915/gem_exec_big.c b/tests/i915/gem_exec_big.c
index a15672f66..015f59e29 100644
--- a/tests/i915/gem_exec_big.c
+++ b/tests/i915/gem_exec_big.c
@@ -71,7 +71,7 @@ static void exec1(int fd, uint32_t handle, uint64_t
reloc_ofs, unsigned flags, c
gem_exec[0].relocs_ptr = to_user_pointer(gem_reloc);
gem_exec[0].alignment = 0;
gem_exec[0].offset = 0;
- gem_exec[0].flags = 0;
+ gem_exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
gem_exec[0].rsvd1 = 0;
gem_exec[0].rsvd2 = 0;
@@ -154,12 +154,11 @@ static void execN(int fd, uint32_t handle, uint64_t
batch_size, unsigned flags,
gem_exec[0].handle = handle;
gem_exec[0].relocation_count = nreloc;
gem_exec[0].relocs_ptr = to_user_pointer(gem_reloc);
+ gem_exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
memset(, 0, sizeof(execbuf));
execbuf.buffers_ptr = to_user_pointer(gem_exec);
execbuf.buffer_count = 1;
- execbuf.batch_start_offset = 0;
- execbuf.batch_len = 8;
execbuf.flags = flags;
/* Avoid hitting slowpaths in the reloc processing which might yield a
@@ -197,16 +196,10 @@ static void execN(int fd, uint32_t handle, uint64_t
batch_size, unsigned flags,
#undef reloc_ofs
}
-igt_simple_main
+static void exhaustive(int fd)
{
uint32_t batch[2] = {MI_BATCH_BUFFER_END};
uint64_t batch_size, max, ggtt_max, reloc_ofs;
- int fd;
-
- fd = drm_open_driver(DRIVER_INTEL);
- igt_require_gem(fd);
-
- use_64bit_relocs = intel_gen(intel_get_drm_devid(fd)) >= 8;
max = 3 * gem_aperture_size(fd) / 4;
ggtt_max = 3 * gem_global_aperture_size(fd) / 4;
@@ -258,6 +251,61 @@ igt_simple_main
else
batch_size *= 2;
}
+}
+
+static void single(int i915)
+{
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ uint64_t batch_size, limit;
+ uint32_t handle;
+ void *ptr;
+
+ batch_size = (intel_get_avail_ram_mb() - 128) << 20; /* CI slack */
+ limit = gem_aperture_size(i915) - (256 << 10); /* low pages reserved */
+ if (!gem_uses_full_ppgtt(i915))
+ limit = 3 * limit / 4;
+
+ batch_size = min(batch_size, limit);
+ batch_size = ALIGN(batch_size, 4096);
+ igt_info("Submitting a %'"PRId64"MiB batch, %saperture size
%'"PRId64"MiB\n",
+batch_size >> 20,
+gem_uses_full_ppgtt(i915) ? "" : "shared ",
+gem_aperture_size(i915) >> 20);
+ intel_require_memory(1, batch_size, CHECK_RAM);
+
+ handle = gem_create(i915, batch_size);
+ gem_write(i915, handle, 0, , sizeof(bbe));
+
+ if (!FORCE_PREAD_PWRITE && gem_has_llc(i915))
+ ptr = __gem_mmap__cpu(i915, handle, 0, batch_size, PROT_READ);
+ else if (!FORCE_PREAD_PWRITE && gem_mmap__has_wc(i915))
+ ptr = __gem_mmap__wc(i915, handle, 0, batch_size, PROT_READ);
+ else
+ ptr = NULL;
+
+ execN(i915, handle, batch_size, 0, ptr);
+
+ if (ptr)
+ munmap(ptr, batch_size);
+}
+
+igt_main
+{
+ int i915 = -1;
+
+ igt_fixture {
+ i915 = drm_open_driver(DRIVER_INTEL);
+ igt_require_gem(i915);
+
+ use_64bit_relocs = intel_gen(intel_get_drm_devid(i915)) >= 8;
+ }
+
+ igt_subtest("single")
+ single(i915);
+
+ igt_subtest("exhaustive")
+ exhaustive(i915);
- close(fd);
+ igt_fixture
+ close(i915);
}
diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt
index f9ad47ea0..9a1dd0e63 100644
--- a/tests/intel-ci/blacklist.txt
+++ b/tests/intel-ci/blacklist.txt
@@ -28,6 +28,7 @@ igt@gem_ctx_thrash(@.*)?
igt@gem_evict_alignment(@.*)?
igt@gem_evict_everything(@.*)?
igt@gem_exec_alignment@(?!.*single).*
+igt@gem_exec_big@(?!.*single).*
igt@gem_exec_capture@many-(?!4K-).*
igt@gem_exec_fence@(?!.*basic).*
igt@gem_exec_flush@(?!.*basic).*
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 7/8] kms_fence_pin_leak: Ask for the GPU before use
Check that the GPU even exists before submitting a batch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109589 Signed-off-by: Chris Wilson --- tests/kms_fence_pin_leak.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/kms_fence_pin_leak.c b/tests/kms_fence_pin_leak.c index 62c52b627..e6c8b33c3 100644 --- a/tests/kms_fence_pin_leak.c +++ b/tests/kms_fence_pin_leak.c @@ -201,6 +201,7 @@ igt_simple_main igt_skip_on_simulation(); data.drm_fd = drm_open_driver_master(DRIVER_INTEL); + igt_require_gem(data.drm_fd); data.devid = intel_get_drm_devid(data.drm_fd); -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 6/8] i915/gem_exec_parse: Switch to a fixed timeout for basic-allocations
basic-allocations was written to demonstrate a flaw in our continual
reallocation of cmdparser shadow bo, largely fixed by keeping a small
cache of bo of different lengths (to speed up the search for the correct
sized bo). We only care enough to exercise the slowdown by submitting
lots of execbufs, and can see the effect of bo caching on the rate, so
replace the fixed number of iterations with a timeout and count how many
batches we could submit instead.
Similarly, we now do not need to wait for all of our queue to complete
as we can tell the kernel to drop the queue instead.
References: https://bugs.freedesktop.org/show_bug.cgi?id=107936
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/gem_exec_parse.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/tests/i915/gem_exec_parse.c b/tests/i915/gem_exec_parse.c
index b653b1bdc..62e8d0a51 100644
--- a/tests/i915/gem_exec_parse.c
+++ b/tests/i915/gem_exec_parse.c
@@ -303,15 +303,15 @@ test_lri(int fd, uint32_t handle, struct test_lri *test)
static void test_allocations(int fd)
{
- uint32_t bbe = MI_BATCH_BUFFER_END;
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
struct drm_i915_gem_execbuffer2 execbuf;
struct drm_i915_gem_exec_object2 obj[17];
- int i, j;
+ unsigned long count;
intel_require_memory(2, 1ull<<(12 + ARRAY_SIZE(obj)), CHECK_RAM);
memset(obj, 0, sizeof(obj));
- for (i = 0; i < ARRAY_SIZE(obj); i++) {
+ for (int i = 0; i < ARRAY_SIZE(obj); i++) {
uint64_t size = 1ull << (12 + i);
obj[i].handle = gem_create(fd, size);
@@ -322,17 +322,21 @@ static void test_allocations(int fd)
memset(, 0, sizeof(execbuf));
execbuf.buffer_count = 1;
- for (j = 0; j < 16384; j++) {
- igt_progress("allocations ", j, 16384);
- i = rand() % ARRAY_SIZE(obj);
+
+ count = 0;
+ igt_until_timeout(20) {
+ int i = rand() % ARRAY_SIZE(obj);
execbuf.buffers_ptr = to_user_pointer([i]);
execbuf.batch_start_offset = (rand() % (1ull
[Intel-gfx] [PATCH i-g-t 4/8] i915/gem_create: Verify that all new objects are clear
The kernel must not return stale information back to userspace when they
create a new object. For that purpose, we always clear objects on
creation, so verify that this is so.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
tests/i915/gem_create.c | 71 +
1 file changed, 71 insertions(+)
diff --git a/tests/i915/gem_create.c b/tests/i915/gem_create.c
index 25c5e8088..9de2263d5 100644
--- a/tests/i915/gem_create.c
+++ b/tests/i915/gem_create.c
@@ -44,6 +44,7 @@
#include
#include
#include
+#include
#include
@@ -141,6 +142,73 @@ static void invalid_nonaligned_size(int fd)
gem_close(fd, handle);
}
+static uint64_t get_npages(uint64_t *global, uint64_t npages)
+{
+ uint64_t try, old, max;
+
+ max = *global;
+ do {
+ old = max;
+ try = npages % (max / 2);
+ max -= try;
+ } while ((max = __sync_val_compare_and_swap(global, old, max)) != old);
+
+ return try;
+}
+
+struct thread_clear {
+ uint64_t max;
+ int timeout;
+ int i915;
+};
+
+static void *thread_clear(void *data)
+{
+ struct thread_clear *arg = data;
+ int i915 = arg->i915;
+
+ igt_until_timeout(arg->timeout) {
+ uint32_t handle;
+ uint64_t npages;
+
+ npages = random();
+ npages <<= 32;
+ npages |= random();
+ npages = get_npages(>max, npages);
+
+ handle = gem_create(i915, npages << 12);
+ for (uint64_t page = 0; page < npages; page++) {
+ uint64_t x;
+
+ gem_read(i915, handle,
+ page % (4096 - sizeof(x)),
+ , sizeof(x));
+ igt_assert_eq_u64(x, 0);
+ }
+ gem_close(i915, handle);
+
+ __sync_add_and_fetch(>max, npages);
+ }
+
+ return NULL;
+}
+
+static void always_clear(int i915, int timeout)
+{
+ struct thread_clear arg = {
+ .i915 = i915,
+ .timeout = timeout,
+ .max = intel_get_avail_ram_mb() << (20 - 12), /* in pages */
+ };
+ const int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
+ pthread_t thread[ncpus];
+
+ for (int i = 0; i < ncpus; i++)
+ pthread_create([i], NULL, thread_clear, );
+ for (int i = 0; i < ncpus; i++)
+ pthread_join(thread[i], NULL);
+}
+
igt_main
{
int fd = -1;
@@ -162,4 +230,7 @@ igt_main
igt_subtest("create-invalid-nonaligned")
invalid_nonaligned_size(fd);
+
+ igt_subtest("create-clear")
+ always_clear(fd, 30);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
