Hi,
Here's one regression fix for windows VM hang issue on recent drivers.
Thanks
--
The following changes since commit c90b4503ccf42d9d367e843c223df44aa550e82a:
drm/i915/gvt: Clear d3_entered on elsp cmd submission. (2021-07-08 16:42:34
+0800)
are available in the Git repository at:
== Series Details ==
Series: drm/i915: Free all DMC payloads (rev2)
URL : https://patchwork.freedesktop.org/series/93521/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10462 -> Patchwork_20790
Summary
---
== Series Details ==
Series: drm/i915: Free all DMC payloads (rev2)
URL : https://patchwork.freedesktop.org/series/93521/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6af2cfb574c5 drm/i915: Free all DMC payloads
-:60: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email
Previously, AMD had an issue about noise with AMD-DG on the RKL platform
AMD provided a parameter.
#modprobe amdgpu ppfeaturemask=0xfff7bffb
I thought it's better to check and assign values in amd gpu.
Have a trouble determining the type of pch(RKL or else),
search in amd drm driver and can't
On 8/6/2021 12:46, Daniel Vetter wrote:
Seen this fly by and figured I dropped a few thoughts in here. At the
likely cost of looking a bit out of whack :-)
On Fri, Aug 6, 2021 at 8:01 PM John Harrison wrote:
On 8/2/2021 02:40, Tvrtko Ursulin wrote:
On 30/07/2021 19:13, John Harrison wrote:
On Mon, Aug 09, 2021 at 10:00:34PM +, Patchwork wrote:
== Series Details ==
Series: drm/i915: Free all DMC payloads
URL : https://patchwork.freedesktop.org/series/93521/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10461 -> Patchwork_20789
== Series Details ==
Series: drm/i915: Free all DMC payloads
URL : https://patchwork.freedesktop.org/series/93521/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10461 -> Patchwork_20789
Summary
---
**FAILURE**
== Series Details ==
Series: drm/i915: Free all DMC payloads
URL : https://patchwork.freedesktop.org/series/93521/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d21754fc284c drm/i915: Free all DMC payloads
-:60: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email
On Mon, 2021-08-09 at 12:48 -0700, Lucas De Marchi wrote:
> From: Chris Wilson
>
> Free all the DMC payloads, not just DMC_MAIN.
>
> unreferenced object 0x88ff32d4d800 (size 1024):
> comm "kworker/1:5", pid 701, jiffies 4294904239 (age 109.736s)
> hex dump (first 32 bytes):
> 40 40
From: Chris Wilson
Free all the DMC payloads, not just DMC_MAIN.
unreferenced object 0x88ff32d4d800 (size 1024):
comm "kworker/1:5", pid 701, jiffies 4294904239 (age 109.736s)
hex dump (first 32 bytes):
40 40 00 0c 03 00 00 00 00 00 00 00 00 00 00 00 @@..
00 00 00
On Mon, Aug 09, 2021 at 04:03:28PM +0200, Daniel Vetter wrote:
> On Sun, Aug 08, 2021 at 11:07:57AM -0700, Matthew Brost wrote:
> > While debugging an issue with full GT resets I went down a rabbit hole
> > thinking the scrubbing of lost G2H wasn't working correctly. This proved
> > to be
On Mon, Aug 09, 2021 at 03:38:38PM +0200, Daniel Vetter wrote:
> On Sun, Aug 08, 2021 at 11:07:56AM -0700, Matthew Brost wrote:
> > GuC submission has exposed an existing memory corruption in
> > live_lrc_isolation. We believe that some writes to the watchdog offsets
> > in the LRC (0x178 & 0x17c)
On Mon, Aug 09, 2021 at 03:35:26PM +0200, Daniel Vetter wrote:
> On Sun, Aug 08, 2021 at 11:07:55AM -0700, Matthew Brost wrote:
> > Resets are notoriously hard to get fully working and notoriously racey,
> > especially with selftests / IGTs that do all sorts of wild things that
> > would be near
On Mon, Aug 09, 2021 at 07:17:27PM +0200, Daniel Vetter wrote:
> On Tue, Aug 03, 2021 at 03:29:43PM -0700, Matthew Brost wrote:
> > Some workloads use lots of contexts that continually pin / unpin
> > contexts. With GuC submission an unpin translates to a schedule disable
> > H2G which puts
On Mon, Aug 09, 2021 at 06:36:44PM +0200, Daniel Vetter wrote:
> On Tue, Aug 03, 2021 at 03:29:22PM -0700, Matthew Brost wrote:
> > Display the workqueue status in debugfs for GuC contexts that are in
> > parent-child relationship.
> >
> > Signed-off-by: Matthew Brost
> > ---
> >
On Mon, Aug 09, 2021 at 05:36:12PM +0200, Daniel Vetter wrote:
> On Tue, Aug 03, 2021 at 03:29:18PM -0700, Matthew Brost wrote:
> > Since child contexts do not own the guc_ids or GuC context registration,
> > child contexts can simply be freed on destroy. Add
> > guc_child_context_destroy context
On Mon, Aug 09, 2021 at 05:35:25PM +0200, Daniel Vetter wrote:
> On Tue, Aug 03, 2021 at 03:29:17PM -0700, Matthew Brost wrote:
> > The heartbeat uses a single instance of a GuC submit engine (GSE) to do
> > the hang check. As such if a different GSE's state machine hangs, the
> > heartbeat cannot
On Mon, Aug 09, 2021 at 05:31:38PM +0200, Daniel Vetter wrote:
> On Tue, Aug 03, 2021 at 03:29:16PM -0700, Matthew Brost wrote:
> > Assign contexts in parent-child relationship consecutive guc_ids. This
> > is accomplished by partitioning guc_id space between ones that need to
> > be consecutive
On Mon, Aug 09, 2021 at 05:17:34PM +0200, Daniel Vetter wrote:
> On Tue, Aug 03, 2021 at 03:29:13PM -0700, Matthew Brost wrote:
> > Implement GuC parent-child context pin / unpin functions in which in any
> > contexts in the relationship are pinned all the contexts are pinned. The
> > parent owns
On Sun, Aug 8, 2021 at 2:56 AM Jason Ekstrand wrote:
>
> On August 6, 2021 15:18:59 Daniel Vetter wrote:
>
>> gem context refcounting is another exercise in least locking design it
>> seems, where most things get destroyed upon context closure (which can
>> race with anything really). Only the
On Mon, Aug 09, 2021 at 04:40:11PM +0200, Daniel Vetter wrote:
> On Mon, Aug 09, 2021 at 04:37:55PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 03, 2021 at 03:29:12PM -0700, Matthew Brost wrote:
> > > Introduce context parent-child relationship. Once this relationship is
> > > created all pinning
On Mon, Aug 09, 2021 at 04:37:55PM +0200, Daniel Vetter wrote:
> On Tue, Aug 03, 2021 at 03:29:12PM -0700, Matthew Brost wrote:
> > Introduce context parent-child relationship. Once this relationship is
> > created all pinning / unpinning operations are directed to the parent
> > context. The
On Mon, Aug 09, 2021 at 04:30:06PM +0200, Daniel Vetter wrote:
> On Tue, Aug 03, 2021 at 03:29:11PM -0700, Matthew Brost wrote:
> > Expose logical engine instance to user via query engine info IOCTL. This
> > is required for split-frame workloads as these needs to be placed on
> > engines in a
Re-reported.
-Original Message-
From: Deak, Imre
Sent: Monday, August 9, 2021 10:57 AM
To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana
Subject: Re: ✗ Fi.CI.IGT: failure for fbdev/efifb: Release PCI device's runtime
PM ref during FB destroy (rev2)
Hi,
On Mon, Aug 09,
On Mon, Aug 09, 2021 at 04:28:04PM +0200, Daniel Vetter wrote:
> On Tue, Aug 03, 2021 at 03:29:10PM -0700, Matthew Brost wrote:
> > Add logical engine mapping. This is required for split-frame, as
> > workloads need to be placed on engines in a logically contiguous manner.
> >
> > Signed-off-by:
== Series Details ==
Series: fbdev/efifb: Release PCI device's runtime PM ref during FB destroy
(rev2)
URL : https://patchwork.freedesktop.org/series/93307/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10460_full -> Patchwork_20786_full
On Mon, Aug 09, 2021 at 04:27:01PM +0200, Daniel Vetter wrote:
> On Tue, Aug 03, 2021 at 03:29:08PM -0700, Matthew Brost wrote:
> > Calling switch_to_kernel_context isn't needed if the engine PM reference
> > is taken while all contexts are pinned. By not calling
> > switch_to_kernel_context we
On Mon, Aug 09, 2021 at 04:23:42PM +0200, Daniel Vetter wrote:
> On Tue, Aug 03, 2021 at 03:29:07PM -0700, Matthew Brost wrote:
> > Taking a PM reference to prevent intel_gt_wait_for_idle from short
> > circuiting while a scheduling of user context could be enabled.
> >
> > Signed-off-by: Matthew
Hi,
On Mon, Aug 09, 2021 at 05:23:59PM +, Patchwork wrote:
> [...]
> * igt@i915_selftest@live@hangcheck:
> - shard-snb: [PASS][1] -> [INCOMPLETE][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10460/shard-snb2/igt@i915_selftest@l...@hangcheck.html
>[2]:
>
On 8/6/2021 4:18 AM, Jason Gunthorpe wrote:
The patch to move the get/put to core and the patch to convert the samples
to use vfio_device crossed in a way that this was missed. When both
patches are together the samples do not need their own get/put.
Fixes: 437e41368c01 ("vfio/mdpy: Convert
== Series Details ==
Series: fbdev/efifb: Release PCI device's runtime PM ref during FB destroy
(rev2)
URL : https://patchwork.freedesktop.org/series/93307/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10460_full -> Patchwork_20786_full
On Tue, Aug 03, 2021 at 03:29:43PM -0700, Matthew Brost wrote:
> Some workloads use lots of contexts that continually pin / unpin
> contexts. With GuC submission an unpin translates to a schedule disable
> H2G which puts pressure on both the i915 and GuC. A schedule disable can
> also block future
On Mon, Aug 09, 2021 at 07:07:44PM +0200, Daniel Vetter wrote:
> On Tue, Aug 03, 2021 at 03:29:38PM -0700, Matthew Brost wrote:
> > Certain VMA functions in the execbuf IOCTL only need to be called on
> > first or last BB of a multi-BB submission. eb_relocate() on the first
>
> eb_relocate should
On Tue, Aug 03, 2021 at 03:29:38PM -0700, Matthew Brost wrote:
> Certain VMA functions in the execbuf IOCTL only need to be called on
> first or last BB of a multi-BB submission. eb_relocate() on the first
eb_relocate should be outright disallowed on multi lrc execbuf ioctl.
There's no users of
On Mon, Aug 09, 2021 at 04:39:48PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 06:32:42PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 03, 2021 at 03:29:20PM -0700, Matthew Brost wrote:
> > > The GuC must receive requests in the order submitted for contexts in a
> > > parent-child
On Tue, Aug 03, 2021 at 03:29:37PM -0700, Matthew Brost wrote:
> For contexts with width set to two or more, we add a mode to execbuf2
> which implies there are N batch buffers in the buffer list, each of
> which will be sent to one of the engines from the engine map array
>
On Tue, Aug 03, 2021 at 03:29:36PM -0700, Matthew Brost wrote:
> Submitting to a subset of hardware contexts is not allowed, so use the
> copy engine for GPU relocations when using a parallel context.
>
> Signed-off-by: Matthew Brost
Luckily I just pushed the patches to delete all this, so you
On Mon, Aug 09, 2021 at 06:32:42PM +0200, Daniel Vetter wrote:
> On Tue, Aug 03, 2021 at 03:29:20PM -0700, Matthew Brost wrote:
> > The GuC must receive requests in the order submitted for contexts in a
> > parent-child relationship to function correctly. To ensure this, insert
> > a submit fence
On Tue, Aug 03, 2021 at 03:29:23PM -0700, Matthew Brost wrote:
> Introduce 'set parallel submit' extension to connect UAPI to GuC
> multi-lrc interface. Kernel doc in new uAPI should explain it all.
>
> Cc: Tvrtko Ursulin
> Signed-off-by: Matthew Brost
UMD merge request link + igt patchwork
Filed a new bug for the skip and re-reported.
Lakshmi.
-Original Message-
From: Deak, Imre
Sent: Monday, August 9, 2021 8:13 AM
To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana
Subject: Re: ✗ Fi.CI.BAT: failure for fbdev/efifb: Release PCI device's runtime
PM ref during
On Tue, Aug 03, 2021 at 03:29:22PM -0700, Matthew Brost wrote:
> Display the workqueue status in debugfs for GuC contexts that are in
> parent-child relationship.
>
> Signed-off-by: Matthew Brost
> ---
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 56 +--
> 1 file changed,
On Tue, Aug 03, 2021 at 03:29:20PM -0700, Matthew Brost wrote:
> The GuC must receive requests in the order submitted for contexts in a
> parent-child relationship to function correctly. To ensure this, insert
> a submit fence between the current request and last request submitted
> for requests /
On Mon, Aug 09, 2021 at 04:05:59PM +0200, Daniel Vetter wrote:
> On Fri, Aug 06, 2021 at 09:36:56AM +0300, Joonas Lahtinen wrote:
> > Hi Matt,
> >
> > Always use the dim tooling when applying patches, it will do the right
> > thing with regards to adding the S-o-b.
>
> fd.o server rejects any
== Series Details ==
Series: fbdev/efifb: Release PCI device's runtime PM ref during FB destroy
(rev2)
URL : https://patchwork.freedesktop.org/series/93307/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10460 -> Patchwork_20786
On Tue, Aug 03, 2021 at 03:29:18PM -0700, Matthew Brost wrote:
> Since child contexts do not own the guc_ids or GuC context registration,
> child contexts can simply be freed on destroy. Add
> guc_child_context_destroy context operation to do this.
>
> Signed-off-by: Matthew Brost
> ---
>
On Tue, Aug 03, 2021 at 03:29:17PM -0700, Matthew Brost wrote:
> The heartbeat uses a single instance of a GuC submit engine (GSE) to do
> the hang check. As such if a different GSE's state machine hangs, the
> heartbeat cannot detect this hang. Add timer to each GSE which in turn
> can disable
On Tue, Aug 03, 2021 at 03:29:16PM -0700, Matthew Brost wrote:
> Assign contexts in parent-child relationship consecutive guc_ids. This
> is accomplished by partitioning guc_id space between ones that need to
> be consecutive (1/16 available guc_ids) and ones that do not (15/16 of
> available
== Series Details ==
Series: DRM: i915: i915_perf: Fixed compiler warning
URL : https://patchwork.freedesktop.org/series/93511/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10460 -> Patchwork_20787
Summary
---
== Series Details ==
Series: gpu/drm/i915: Remove duplicated include of intel_region_lmem.h (rev2)
URL : https://patchwork.freedesktop.org/series/93305/
State : failure
== Summary ==
Applying: gpu/drm/i915: Remove duplicated include of intel_region_lmem.h
Using index info to reconstruct a
On Tue, Aug 03, 2021 at 03:29:13PM -0700, Matthew Brost wrote:
> Implement GuC parent-child context pin / unpin functions in which in any
> contexts in the relationship are pinned all the contexts are pinned. The
> parent owns most of the pinning / unpinning process and the children
> direct any
Hi Lakshmi,
On Mon, Aug 09, 2021 at 02:49:24PM +, Patchwork wrote:
> [...]
> Possible regressions
>
> * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-a:
> - fi-rkl-11600: [PASS][1] -> [SKIP][2]
>[1]:
>
== Series Details ==
Series: DRM: i915: i915_perf: Fixed compiler warning
URL : https://patchwork.freedesktop.org/series/93511/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f0431793a357 DRM: i915: i915_perf: Fixed compiler warning
-:22: WARNING:FROM_SIGN_OFF_MISMATCH:
== Series Details ==
Series: fbdev/efifb: Release PCI device's runtime PM ref during FB destroy
(rev2)
URL : https://patchwork.freedesktop.org/series/93307/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10460 -> Patchwork_20786
On Mon, Aug 09, 2021 at 04:37:55PM +0200, Daniel Vetter wrote:
> On Tue, Aug 03, 2021 at 03:29:12PM -0700, Matthew Brost wrote:
> > Introduce context parent-child relationship. Once this relationship is
> > created all pinning / unpinning operations are directed to the parent
> > context. The
On Tue, Aug 03, 2021 at 03:29:12PM -0700, Matthew Brost wrote:
> Introduce context parent-child relationship. Once this relationship is
> created all pinning / unpinning operations are directed to the parent
> context. The parent context is responsible for pinning all of its'
> children and
On Tue, Aug 03, 2021 at 03:29:11PM -0700, Matthew Brost wrote:
> Expose logical engine instance to user via query engine info IOCTL. This
> is required for split-frame workloads as these needs to be placed on
> engines in a logically contiguous order. The logical mapping can change
> based on
On Mon, Aug 09, 2021 at 02:29:39PM +0300, Joonas Lahtinen wrote:
> Thanks for putting the work into this. This conversion has been
> requested for a long time. For clarity, should we call the module
> i915_kvmgt?
If this was a new module that would be my preferance. But the
kvmgt module already
On Tue, Aug 03, 2021 at 03:29:10PM -0700, Matthew Brost wrote:
> Add logical engine mapping. This is required for split-frame, as
> workloads need to be placed on engines in a logically contiguous manner.
>
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c |
On Tue, Aug 03, 2021 at 03:29:08PM -0700, Matthew Brost wrote:
> Calling switch_to_kernel_context isn't needed if the engine PM reference
> is taken while all contexts are pinned. By not calling
> switch_to_kernel_context we save on issuing a request to the engine.
>
> Signed-off-by: Matthew
On Tue, Aug 03, 2021 at 03:29:07PM -0700, Matthew Brost wrote:
> Taking a PM reference to prevent intel_gt_wait_for_idle from short
> circuiting while a scheduling of user context could be enabled.
>
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
>
On Sat, Aug 07, 2021 at 06:21:10PM +0300, Imre Deak wrote:
> On Thu, Aug 05, 2021 at 12:23:21AM +0200, Daniel Vetter wrote:
> > On Mon, Aug 02, 2021 at 04:35:51PM +0300, Imre Deak wrote:
> > > Atm the EFI FB driver gets a runtime PM reference for the associated GFX
> > > PCI device during driver
On Fri, Aug 06, 2021 at 09:36:56AM +0300, Joonas Lahtinen wrote:
> Hi Matt,
>
> Always use the dim tooling when applying patches, it will do the right
> thing with regards to adding the S-o-b.
fd.o server rejects any pushes that haven't been done by dim, so how did
this get through? Matt, can
On Sun, Aug 08, 2021 at 11:07:57AM -0700, Matthew Brost wrote:
> While debugging an issue with full GT resets I went down a rabbit hole
> thinking the scrubbing of lost G2H wasn't working correctly. This proved
> to be incorrect as this was working just fine but this chase inspired me
> to write a
Duplicate include header file "intel_region_lmem.h"
line 8: #include "intel_region_lmem.h"
line 13: #include "intel_region_lmem.h"
Signed-off-by: zhouchuangao
---
drivers/gpu/drm/i915/gt/intel_region_lmem.c | 1 -
1 file changed, 1 deletion(-)
diff --git
From: Julius
Fixed compiler warning: "left shift of negative value"
Signed-off-by: Julius Victorian
---
drivers/gpu/drm/i915/i915_perf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index
On Sun, Aug 08, 2021 at 11:07:56AM -0700, Matthew Brost wrote:
> GuC submission has exposed an existing memory corruption in
> live_lrc_isolation. We believe that some writes to the watchdog offsets
> in the LRC (0x178 & 0x17c) can result in trashing of portions of the
> address space. With GuC
On Sun, Aug 08, 2021 at 11:07:55AM -0700, Matthew Brost wrote:
> Resets are notoriously hard to get fully working and notoriously racey,
> especially with selftests / IGTs that do all sorts of wild things that
> would be near impossible to hit during normal use cases. Even though
> likely
Atm the EFI FB platform driver gets a runtime PM reference for the
associated GFX PCI device during probing the EFI FB platform device and
releases it only when the platform device gets unbound.
When fbcon switches to the FB provided by the PCI device's driver (for
instance i915/drmfb), the EFI
Hi, Thomas:
Thomas Zimmermann 於 2021年6月25日 週五 下午4:22寫道：
>
> The field drm_device.irq_enabled is only used by legacy drivers
> with userspace modesetting. Don't set it in mediatek.
>
Acked-by: Chun-Kuang Hu
> Signed-off-by: Thomas Zimmermann
> Reviewed-by: Laurent Pinchart
> Acked-by: Daniel
Quoting Christoph Hellwig (2021-07-21 18:53:38)
> Instead of having an option to build the gvt code into the main i915
> module, just move it into the kvmgt.ko module. This only requires
> a new struct with three entries that the main i915 module needs to
> request before enabling VGPU
70 matches
Mail list logo
