> This made me thing guc engine reset notification is a "handshake"
> operation and not a pure notification? Does it imply GuC will wait for
> i915 to reply what to do next meaning it won't continue to execute ContextA
> before i915 replies to engine reset notification?
> If so that would resolv
== Series Details ==
Series: series starting with [v5,1/5] x86/quirks: Fix stolen detection with
integrated + discrete GPU
URL : https://patchwork.freedesktop.org/series/98864/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11081_full -> Patchwork_22001_full
==
== Series Details ==
Series: series starting with [v5,1/5] x86/quirks: Fix stolen detection with
integrated + discrete GPU
URL : https://patchwork.freedesktop.org/series/98864/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11081 -> Patchwork_22001
The flags were only used to mark the quirk as applied when it was
requested to be called only once. Now all the users were converted to
use a static local variable, so this logic can be removed.
Signed-off-by: Lucas De Marchi
---
arch/x86/kernel/early-quirks.c | 35 ++
Remove extra parenthesis and wrap lines so it's easier to read what are
the conditions being checked. The call to the hook also had an extra
indentation: remove here to conform to coding style.
Signed-off-by: Lucas De Marchi
Reviewed-by: Rodrigo Vivi
---
arch/x86/kernel/early-quirks.c | 14
Adopt the same approach as in intel_graphics_quirks(), with a static
local variable, to control when the quirk has already been applied.
However, contrary to intel_graphics_quirks(), here we always set it as
applied as soon as it's called to avoid changing the current behavior
that is not failing.
early_pci_scan_bus() does a depth-first traversal, possibly calling
the quirk functions for each device based on vendor, device and class
from early_qrk table. intel_graphics_quirks() however uses PCI_ANY_ID
and does additional filtering in the quirk.
If there is an Intel integrated + discrete GPU
Adopt the same approach as in intel_graphics_quirks(), with a static
local variable, to control when the quirk has already been applied.
However, contrary to intel_graphics_quirks() here we always set it as
applied as soon as it's called to avoid changing the current behavior
that is not failing.
From: John Harrison
The hang test was relying on context persitence for no particular
reason. That is, it would set a bunch of background spinners running
then immediately destroy the active contexts but expect the spinners
to keep spinning. With the current implementation of context
persistence
From: John Harrison
The test was updated some engine properties but not restoring them
afterwards. That would leave the system in a non-default state which
could potentially affect subsequent tests. Fix it by using the new
save/restore engine properties helper functions.
Signed-off-by: John Harr
From: John Harrison
Although the hangman test was ensuring that *some* reset functionality
was enabled, it did not differentiate what kind. The infrastructure
required to choose between per engine reset or full GT reset was
recently added. So update this test to use it as well.
Signed-off-by: Jo
From: John Harrison
Various tests want to configure engine properties such as pre-emption
timeout and heartbeat interval. Some don't bother to restore the
original values again afterwards. So, add a helper to make it easier
to do this.
v2: Fix for platforms with no pre-emption capability.
Signe
From: John Harrison
Added a an extra step to the i915_hangman tests to check that the
system is still alive after the hang and recovery. This submits a
simple batch to each engine which does a write to memory and checks
that the write occurred.
v2: Use _device_coherent instead of _wc for mapping
From: John Harrison
As opposed to only on the non-target engines. This means that there is
some other workload present for the scheduler to switch between and so
detet the hang immediately.
Signed-off-by: John Harrison
Reviewed-by: Matthew Brost
---
tests/i915/i915_hangman.c | 10 ++
From: John Harrison
Some platforms have very long timeouts configured for some engines.
Some have them disabled completely. That makes for a very slow (or
broken) hangman test. So explicitly configure the engines to have
reasonable settings first.
Signed-off-by: John Harrison
Reviewed-by: Matth
From: John Harrison
The update to use intel_ctx_t missed a line that configures the
context to allow hanging. Fix that.
Fixes: 09c36188b ("tests/i915/gem_exec_fence: Convert to intel_ctx_t (v2)")
Signed-off-by: John Harrison
Reviewed-by: Matthew Brost
---
tests/i915/gem_exec_fence.c | 2 +-
1
From: John Harrison
The hangman framework sets up a context that is valid for all engines
and has things like banning disabled. The 'unterminated' test then
ignores it and uses the default context. Fix that.
Signed-off-by: John Harrison
Reviewed-by: Matthew Brost
---
tests/i915/i915_hangman.c
From: John Harrison
The capture test was still using old style ring_id and ring_name
(derived from the engine structure at the higher level). Update it to
just take the engine structure directly.
Signed-off-by: John Harrison
Reviewed-by: Matthew Brost
---
tests/i915/i915_hangman.c | 10 +-
From: John Harrison
The above function was checking for valid rings via the old interface.
The new scheme is to check for engines on contexts as there are now
more engines than could be supported.
Signed-off-by: John Harrison
---
lib/igt_gt.c | 6 +++---
lib/igt_gt.h
From: John Harrison
Some of the IGT framework relies on receving a uevent when a hang
occurs. So add a test that this actually works.
While testing this, noticed that hangs could sometimes be missed
because the uevent was (presumably) still in flight by the time the
handler was de-registered. So
From: John Harrison
The global context used by all the subtests for causing hangs is
marked as unbannable. However, some of the subtests set background
spinners running on all engines using a freshly created context. If
there is a test failure for any reason, all of those spinners can be
killed o
From: John Harrison
A lot of tests use almost identical code for creating a batch buffer
which does a single write to memory and another is about to be added.
Instead, move the most generic version into a common helper function.
Unfortunately, the other instances are all subtly different enough t
From: John Harrison
Fix a bunch of issues with i915_hangman and gem_exec_capture with the
ultimate aim of making them pass on GuC enabled platforms.
v2: Fixes to the store code. Add engine properties management.
v3: Fix for platforms without pre-emption.
v4: Simplify anti-ban code, support >32bi
From: John Harrison
Added descriptions of the various sub-tests and the test as a whole.
v2: Added missing linefeed (spotted by Petri)
Signed-off-by: John Harrison
Reviewed-by: Petri Latvala
---
tests/i915/i915_hangman.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff
From: John Harrison
Added a an extra step to the i915_hangman tests to check that the
system is still alive after the hang and recovery. This submits a
simple batch to each engine which does a write to memory and checks
that the write occurred.
v2: Use _device_coherent instead of _wc for mapping
On Thu, Jan 13, 2022 at 11:59:47AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The test was updated some engine properties but not restoring them
> afterwards. That would leave the system in a non-default state which
> could potentially affect subsequent tests. Fix it by usi
On Thu, Jan 13, 2022 at 11:59:46AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Some platforms have very long timeouts configured for some engines.
> Some have them disabled completely. That makes for a very slow (or
> broken) hangman test. So explicitly configure the engines
On Thu, Jan 13, 2022 at 11:59:45AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Various tests want to configure engine properties such as pre-emption
> timeout and heartbeat interval. Some don't bother to restore the
> original values again afterwards. So, add a helper to mak
On Thu, Jan 13, 2022 at 01:26:53PM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The global context used by all the subtests for causing hangs is
> marked as unbannable. However, some of the subtests set background
> spinners running on all engines using a freshly created cont
== Series Details ==
Series: drm/i915: Flip guc_id allocation partition (rev5)
URL : https://patchwork.freedesktop.org/series/98751/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11079_full -> Patchwork_22000_full
Summary
-
From: John Harrison
The global context used by all the subtests for causing hangs is
marked as unbannable. However, some of the subtests set background
spinners running on all engines using a freshly created context. If
there is a test failure for any reason, all of those spinners can be
killed o
On 1/13/2022 13:06, Matthew Brost wrote:
On Thu, Jan 13, 2022 at 11:59:44AM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
The update to use intel_ctx_t missed a line that configures the
context to allow hanging. Fix that.
Fixes: 09c36188b23f83ef9a7b5414e2a10100adc4291f
Typicall
On 1/13/2022 13:01, Matthew Brost wrote:
On Thu, Jan 13, 2022 at 11:59:43AM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
The global context used by all the subtests for causing hangs is
marked as unbannable. However, some of the subtests set background
spinners running on all en
On Thu, Jan 13, 2022 at 11:59:44AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The update to use intel_ctx_t missed a line that configures the
> context to allow hanging. Fix that.
>
> Fixes: 09c36188b23f83ef9a7b5414e2a10100adc4291f
Typically I thought the Fixes comment wa
On Thu, Jan 13, 2022 at 11:59:43AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The global context used by all the subtests for causing hangs is
> marked as unbannable. However, some of the subtests set background
> spinners running on all engines using a freshly created cont
On Thu, Jan 13, 2022 at 12:50:29PM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> A lot of tests use almost identical code for creating a batch buffer
> which does a single write to memory and another is about to be added.
> Instead, move the most generic version into a common
On Thu, Jan 13, 2022 at 11:59:42AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> As opposed to only on the non-target engines. This means that there is
> some other workload present for the scheduler to switch between and so
> detet the hang immediately.
>
> Signed-off-by: Jo
== Series Details ==
Series: Remove some hacks required for GuC 62.0.0 (rev2)
URL : https://patchwork.freedesktop.org/series/98773/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11079_full -> Patchwork_21999_full
Summary
--
From: John Harrison
A lot of tests use almost identical code for creating a batch buffer
which does a single write to memory and another is about to be added.
Instead, move the most generic version into a common helper function.
Unfortunately, the other instances are all subtly different enough t
On Thu, Jan 13, 2022 at 12:42:28PM -0800, John Harrison wrote:
> On 1/13/2022 12:30, Matthew Brost wrote:
> > On Thu, Jan 13, 2022 at 11:59:41AM -0800, john.c.harri...@intel.com wrote:
> > > From: John Harrison
> > >
> > > The hang test was relying on context persitence for no particular
> > > re
On 1/13/2022 12:30, Matthew Brost wrote:
On Thu, Jan 13, 2022 at 11:59:41AM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
The hang test was relying on context persitence for no particular
reason. That is, it would set a bunch of background spinners running
then immediately destro
On 1/13/2022 12:23, Matthew Brost wrote:
On Thu, Jan 13, 2022 at 12:27:00PM -0800, John Harrison wrote:
On 1/13/2022 12:10, Matthew Brost wrote:
On Thu, Jan 13, 2022 at 11:59:39AM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
A lot of tests use almost identical code for creatin
On Thu, Jan 13, 2022 at 11:59:41AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The hang test was relying on context persitence for no particular
> reason. That is, it would set a bunch of background spinners running
> then immediately destroy the active contexts but expect t
On Thu, Jan 06, 2022 at 12:02:36PM -0800, Juston Li wrote:
> Similar to commit b8d8436840ca ("drm/i915/gt: Hold RPM wakelock during
> PXP suspend") but to fix the same warning for unbind during shutdown:
>
> [ cut here ]
> RPM wakelock ref not held during HW access
> WARNIN
On Thu, Jan 13, 2022 at 12:27:00PM -0800, John Harrison wrote:
> On 1/13/2022 12:10, Matthew Brost wrote:
> > On Thu, Jan 13, 2022 at 11:59:39AM -0800, john.c.harri...@intel.com wrote:
> > > From: John Harrison
> > >
> > > A lot of tests use almost identical code for creating a batch buffer
> > >
On Wed, Jan 12, 2022 at 05:28:29PM -0800, Lucas De Marchi wrote:
> On Wed, Jan 12, 2022 at 07:06:45PM -0600, Bjorn Helgaas wrote:
> > On Wed, Jan 12, 2022 at 04:21:28PM -0800, Lucas De Marchi wrote:
> > > On Wed, Jan 12, 2022 at 06:08:05PM -0600, Bjorn Helgaas wrote:
> > > > On Wed, Jan 12, 2022 at
On 1/13/2022 12:10, Matthew Brost wrote:
On Thu, Jan 13, 2022 at 11:59:39AM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
A lot of tests use almost identical code for creating a batch buffer
which does a single write to memory and another is about to be added.
Instead, move the m
On Thu, Jan 13, 2022 at 11:59:40AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Added a an extra step to the i915_hangman tests to check that the
> system is still alive after the hang and recovery. This submits a
> simple batch to each engine which does a write to memory and
On Thu, Jan 13, 2022 at 06:58:47PM +0200, Jani Nikula wrote:
> On Wed, 12 Jan 2022, Rodrigo Vivi wrote:
> > I understand that I'm late to the fun here, but I got myself wondering if
> > we couldn't separated the registers in a "regs" directory
> > and find some way to organize them in IP blocks ma
== Series Details ==
Series: drm/i915: Flip guc_id allocation partition (rev5)
URL : https://patchwork.freedesktop.org/series/98751/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11079 -> Patchwork_22000
Summary
---
On Thu, Jan 13, 2022 at 11:59:39AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> A lot of tests use almost identical code for creating a batch buffer
> which does a single write to memory and another is about to be added.
> Instead, move the most generic version into a common
On Thu, 2022-01-13 at 19:59 +, Patchwork wrote:
Patch Details
Series: drm/i915/display/adlp: Implement new step in the TC voltage swing prog
sequence
URL:https://patchwork.freedesktop.org/series/98853/
State: success
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_2199
On Thu, Jan 13, 2022 at 11:59:38AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The hangman framework sets up a context that is valid for all engines
> and has things like banning disabled. The 'unterminated' test then
> ignores it and uses the default context. Fix that.
>
>
On Thu, Jan 13, 2022 at 11:59:35AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The capture test was still using old style ring_id and ring_name
> (derived from the engine structure at the higher level). Update it to
> just take the engine structure directly.
>
> Signed-off-
On Thu, 2022-01-13 at 17:56 +, Patchwork wrote:
Patch Details
Series: drm/i915/display/ehl: Update voltage swing table
URL:https://patchwork.freedesktop.org/series/98844/
State: failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21994/index.html
CI Bug Log - change
From: John Harrison
A lot of tests use almost identical code for creating a batch buffer
which does a single write to memory and another is about to be added.
Instead, move the most generic version into a common helper function.
Unfortunately, the other instances are all subtly different enough t
From: John Harrison
The global context used by all the subtests for causing hangs is
marked as unbannable. However, some of the subtests set background
spinners running on all engines using a freshly created context. If
there is a test failure for any reason, all of those spinners can be
killed o
From: John Harrison
Some platforms have very long timeouts configured for some engines.
Some have them disabled completely. That makes for a very slow (or
broken) hangman test. So explicitly configure the engines to have
reasonable settings first.
Signed-off-by: John Harrison
---
tests/i915/i9
From: John Harrison
The update to use intel_ctx_t missed a line that configures the
context to allow hanging. Fix that.
Fixes: 09c36188b23f83ef9a7b5414e2a10100adc4291f
Signed-off-by: John Harrison
---
tests/i915/gem_exec_fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
From: John Harrison
The hang test was relying on context persitence for no particular
reason. That is, it would set a bunch of background spinners running
then immediately destroy the active contexts but expect the spinners
to keep spinning. With the current implementation of context
persistence
From: John Harrison
As opposed to only on the non-target engines. This means that there is
some other workload present for the scheduler to switch between and so
detet the hang immediately.
Signed-off-by: John Harrison
---
tests/i915/i915_hangman.c | 10 ++
1 file changed, 6 insertions
From: John Harrison
The capture test was still using old style ring_id and ring_name
(derived from the engine structure at the higher level). Update it to
just take the engine structure directly.
Signed-off-by: John Harrison
---
tests/i915/i915_hangman.c | 10 +-
1 file changed, 5 inse
From: John Harrison
Although the hangman test was ensuring that *some* reset functionality
was enabled, it did not differentiate what kind. The infrastructure
required to choose between per engine reset or full GT reset was
recently added. So update this test to use it as well.
Signed-off-by: Jo
From: John Harrison
Various tests want to configure engine properties such as pre-emption
timeout and heartbeat interval. Some don't bother to restore the
original values again afterwards. So, add a helper to make it easier
to do this.
v2: Fix for platforms with no pre-emption capability.
Signe
From: John Harrison
The test was updated some engine properties but not restoring them
afterwards. That would leave the system in a non-default state which
could potentially affect subsequent tests. Fix it by using the new
save/restore engine properties helper functions.
Signed-off-by: John Harr
From: John Harrison
The hangman framework sets up a context that is valid for all engines
and has things like banning disabled. The 'unterminated' test then
ignores it and uses the default context. Fix that.
Signed-off-by: John Harrison
---
tests/i915/i915_hangman.c | 1 +
1 file changed, 1 in
From: John Harrison
Added descriptions of the various sub-tests and the test as a whole.
v2: Added missing linefeed (spotted by Petri)
Signed-off-by: John Harrison
Reviewed-by: Petri Latvala
---
tests/i915/i915_hangman.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff
From: John Harrison
Added a an extra step to the i915_hangman tests to check that the
system is still alive after the hang and recovery. This submits a
simple batch to each engine which does a write to memory and checks
that the write occurred.
Signed-off-by: John Harrison
---
tests/i915/i915_
From: John Harrison
Some of the IGT framework relies on receving a uevent when a hang
occurs. So add a test that this actually works.
While testing this, noticed that hangs could sometimes be missed
because the uevent was (presumably) still in flight by the time the
handler was de-registered. So
From: John Harrison
The above function was checking for valid rings via the old interface.
The new scheme is to check for engines on contexts as there are now
more engines than could be supported.
Signed-off-by: John Harrison
---
lib/igt_gt.c | 6 +++---
lib/igt_gt.h
From: John Harrison
Fix a bunch of issues with i915_hangman and gem_exec_capture with the
ultimate aim of making them pass on GuC enabled platforms.
v2: Fixes to the store code. Add engine properties management.
v3: Fix for platforms without pre-emption.
Signed-off-by: John Harrison
John Har
== Series Details ==
Series: drm/i915/display/adlp: Implement new step in the TC voltage swing prog
sequence
URL : https://patchwork.freedesktop.org/series/98853/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11079_full -> Patchwork_21997_full
== Series Details ==
Series: Remove some hacks required for GuC 62.0.0 (rev2)
URL : https://patchwork.freedesktop.org/series/98773/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11079 -> Patchwork_21999
Summary
---
*
== Series Details ==
Series: Remove some hacks required for GuC 62.0.0 (rev2)
URL : https://patchwork.freedesktop.org/series/98773/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0bbf21e5b612 drm/i915/selftests: Add a cancel request selftest that triggers a
reset
6c1f06c0b615 d
== Series Details ==
Series: Flush G2H handler during a GT reset
URL : https://patchwork.freedesktop.org/series/98855/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11079 -> Patchwork_21998
Summary
---
**FAILURE**
Matches BSPEC for DKL Phy.
Reviewed-by: Clint Taylor
-Clint
On 1/13/22 9:48 AM, José Roberto de Souza wrote:
TC voltage swing programming sequence was updated with a new step.
BSpec: 54956
Cc: sta...@vger.kernel.org
Cc: Jani Nikula
Cc: Clint Taylor
Cc: Imre Deak
Signed-off-by: José Rober
== Series Details ==
Series: Flush G2H handler during a GT reset
URL : https://patchwork.freedesktop.org/series/98855/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
df8c84b965e7 drm/i915: Allocate intel_engine_coredump_alloc with ALLOW_FAIL
6af3f3db9124 drm/i915/guc: Flush G2H
== Series Details ==
Series: drm/i915/display/adlp: Implement new step in the TC voltage swing prog
sequence
URL : https://patchwork.freedesktop.org/series/98853/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11079 -> Patchwork_21997
==
On 1/13/2022 10:13, Matthew Brost wrote:
Add a cancel request selftest that results in an engine reset to cancel
the request as it is non-preemptable. Also insert a NOP request after
the cancelled request and confirm that it completes successfully.
v2:
(Tvrtko)
- Skip test if preemption tim
Add a cancel request selftest that results in an engine reset to cancel
the request as it is non-preemptable. Also insert a NOP request after
the cancelled request and confirm that it completes successfully.
v2:
(Tvrtko)
- Skip test if preemption timeout compiled out
- Skip test if engine res
In the i915 there are several hacks in place to make request cancellation
work with an old version of the GuC which delivered the G2H indicating
schedule disable is done before G2H indicating a context reset. Version
69 fixes this, so we can remove these hacks.
v2:
(Checkpatch)
- s/cancelation/
Remove a hack required because schedule disable done G2H was received
before context reset G2H in GuC firmware 62.0.0. Since we have upgraded
69.0.3, this is no longer required.
Also revive selftest which proves this works before / after change.
v2:
- Address John Harrion's comments
Signed-off
== Series Details ==
Series: drm/i915/display/adlp: Implement new step in the TC voltage swing prog
sequence
URL : https://patchwork.freedesktop.org/series/98853/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be check
== Series Details ==
Series: drm/i915/display/adlp: Implement new step in the TC voltage swing prog
sequence
URL : https://patchwork.freedesktop.org/series/98853/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
79db9538db06 drm/i915/display/adlp: Implement new step in the TC vol
== Series Details ==
Series: drm/i915: Flip guc_id allocation partition (rev4)
URL : https://patchwork.freedesktop.org/series/98751/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11079 -> Patchwork_21996
Summary
---
On Thu, Jan 13, 2022 at 09:59:35AM -0800, John Harrison wrote:
> On 1/13/2022 09:34, Matthew Brost wrote:
> > On Thu, Jan 13, 2022 at 09:33:12AM -0800, John Harrison wrote:
> > > On 1/11/2022 15:11, Matthew Brost wrote:
> > > > Add a cancel request selftest that results in an engine reset to cancel
On 1/13/2022 09:34, Matthew Brost wrote:
On Thu, Jan 13, 2022 at 09:33:12AM -0800, John Harrison wrote:
On 1/11/2022 15:11, Matthew Brost wrote:
Add a cancel request selftest that results in an engine reset to cancel
the request as it is non-preemptable. Also insert a NOP request after
the canc
Now that the error capture is fully decoupled from fence signalling
(request retirement to free memory, which is turn depends on resets) we
can safely flush the G2H handler during a GT reset. This is eliminates
corner cases where GuC generated G2H (e.g. engine resets) race with a GT
reset.
Signed-
After a small fix to error capture code, we now can flush G2H during a
GT reset which simplifies code and seals some extreme corner case races.
Signed-off-by: Matthew Brost
Matthew Brost (2):
drm/i915: Allocate intel_engine_coredump_alloc with ALLOW_FAIL
drm/i915/guc: Flush G2H handler duri
Allocate intel_engine_coredump_alloc with ALLOW_FAIL rather than
GFP_KERNEL do fully decouple the error capture from fence signalling.
Fixes: 8b91cdd4f8649 ("drm/i915: Use __GFP_KSWAPD_RECLAIM in the capture code")
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
1
== Series Details ==
Series: drm/i915/display/ehl: Update voltage swing table
URL : https://patchwork.freedesktop.org/series/98844/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11079_full -> Patchwork_21994_full
Summary
--
TC voltage swing programming sequence was updated with a new step.
BSpec: 54956
Cc: sta...@vger.kernel.org
Cc: Jani Nikula
Cc: Clint Taylor
Cc: Imre Deak
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 22 ++
drivers/gpu/drm/i915/i915_re
On Thu, Jan 13, 2022 at 09:33:12AM -0800, John Harrison wrote:
> On 1/11/2022 15:11, Matthew Brost wrote:
> > Add a cancel request selftest that results in an engine reset to cancel
> > the request as it is non-preemptable. Also insert a NOP request after
> > the cancelled request and confirm that
On 1/11/2022 15:11, Matthew Brost wrote:
Add a cancel request selftest that results in an engine reset to cancel
the request as it is non-preemptable. Also insert a NOP request after
the cancelled request and confirm that it completes successfully.
v2:
(Tvrtko)
- Skip test if preemption tim
On 1/11/2022 15:11, Matthew Brost wrote:
In the i915 there are several hacks in place to make request cancelation
work with an old version of the GuC which delivered the G2H indicating
schedule disable is done before G2H indicating a context reset. Version
69 fixes this, so we can remove these ha
== Series Details ==
Series: drm/i915: Flip guc_id allocation partition (rev3)
URL : https://patchwork.freedesktop.org/series/98751/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11079 -> Patchwork_21995
Summary
---
From: John Harrison
The test was updated some engine properties but not restoring them
afterwards. That would leave the system in a non-default state which
could potentially affect subsequent tests. Fix it by using the new
save/restore engine properties helper functions.
Signed-off-by: John Harr
From: John Harrison
Added a an extra step to the i915_hangman tests to check that the
system is still alive after the hang and recovery. This submits a
simple batch to each engine which does a write to memory and checks
that the write occurred.
Signed-off-by: John Harrison
---
tests/i915/i915_
From: John Harrison
Some platforms have very long timeouts configured for some engines.
Some have them disabled completely. That makes for a very slow (or
broken) hangman test. So explicitly configure the engines to have
reasonable settings first.
Signed-off-by: John Harrison
---
tests/i915/i9
From: John Harrison
The global context used by all the subtests for causing hangs is
marked as unbannable. However, some of the subtests set background
spinners running on all engines using a freshly created context. If
there is a test failure for any reason, all of those spinners can be
killed o
1 - 100 of 156 matches
Mail list logo
