Re: [Intel-gfx] [PATCH 33/44] drm/mcde: Don't use drm_device->dev_private
On Fri, Apr 3, 2020 at 3:59 PM Daniel Vetter wrote: > Upcasting using a container_of macro is more typesafe, faster and > easier for the compiler to optimize. > > Signed-off-by: Daniel Vetter > Cc: Linus Walleij Nice, thanks! Reviewed-by: Linus Walleij Yours, Linus Walleij ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 12/17] drm/mcde: Use mode->clock instead of reverse calculating it from the vrefresh
On Fri, Apr 3, 2020 at 10:41 PM Ville Syrjala wrote: > From: Ville Syrjälä > > htotal*vtotal*vrefresh ~= clock. So just say "clock" when we mean it. > > Cc: Linus Walleij > Cc: Sam Ravnborg > Signed-off-by: Ville Syrjälä Indeed :) Reviewed-by: Linus Walleij Yours, Linus Walleij ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Patch "drm/i915: Fix ref->mutex deadlock in i915_active_wait()" has been added to the 5.4-stable tree (rev2)
== Series Details == Series: Patch "drm/i915: Fix ref->mutex deadlock in i915_active_wait()" has been added to the 5.4-stable tree (rev2) URL : https://patchwork.freedesktop.org/series/75798/ State : failure == Summary == Patch is empty. When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Patch "drm/i915: Fix ref->mutex deadlock in i915_active_wait()" has been added to the 5.4-stable tree
This is a note to let you know that I've just added the patch titled
drm/i915: Fix ref->mutex deadlock in i915_active_wait()
to the 5.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-i915-fix-ref-mutex-deadlock-in-i915_active_wait.patch
and it can be found in the queue-5.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From sul...@kerneltoast.com Sat Apr 11 13:39:11 2020
From: Sultan Alsawaf
Date: Tue, 7 Apr 2020 13:32:22 -0700
Subject: drm/i915: Fix ref->mutex deadlock in i915_active_wait()
To: sta...@vger.kernel.org
Cc: Greg KH , Jani Nikula , Joonas
Lahtinen , Rodrigo Vivi
, David Airlie , Daniel Vetter
, Chris Wilson ,
intel-gfx@lists.freedesktop.org, dri-de...@lists.freedesktop.org, Sultan
Alsawaf
Message-ID: <20200407203222.2493-1-sul...@kerneltoast.com>
From: Sultan Alsawaf
The following deadlock exists in i915_active_wait() due to a double lock
on ref->mutex (call chain listed in order from top to bottom):
i915_active_wait();
mutex_lock_interruptible(>mutex); <-- ref->mutex first acquired
i915_active_request_retire();
node_retire();
active_retire();
mutex_lock_nested(>mutex, SINGLE_DEPTH_NESTING); <-- DEADLOCK
Fix the deadlock by skipping the second ref->mutex lock when
active_retire() is called through i915_active_request_retire().
Note that this bug only affects 5.4 and has since been fixed in 5.5.
Normally, a backport of the fix from 5.5 would be in order, but the
patch set that fixes this deadlock involves massive changes that are
neither feasible nor desirable for backporting [1][2][3]. Therefore,
this small patch was made to address the deadlock specifically for 5.4.
[1] 274cbf20fd10 ("drm/i915: Push the i915_active.retire into a worker")
[2] 093b92287363 ("drm/i915: Split i915_active.mutex into an irq-safe spinlock
for the rbtree")
[3] 750bde2fd4ff ("drm/i915: Serialise with remote retirement")
Fixes: 12c255b5dad1 ("drm/i915: Provide an i915_active.acquire callback")
Cc: # 5.4.x
Signed-off-by: Sultan Alsawaf
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/i915/i915_active.c | 29 +++--
drivers/gpu/drm/i915/i915_active.h |4 ++--
2 files changed, 21 insertions(+), 12 deletions(-)
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -121,7 +121,7 @@ static inline void debug_active_assert(s
#endif
static void
-__active_retire(struct i915_active *ref)
+__active_retire(struct i915_active *ref, bool lock)
{
struct active_node *it, *n;
struct rb_root root;
@@ -138,7 +138,8 @@ __active_retire(struct i915_active *ref)
retire = true;
}
- mutex_unlock(>mutex);
+ if (likely(lock))
+ mutex_unlock(>mutex);
if (!retire)
return;
@@ -153,21 +154,28 @@ __active_retire(struct i915_active *ref)
}
static void
-active_retire(struct i915_active *ref)
+active_retire(struct i915_active *ref, bool lock)
{
GEM_BUG_ON(!atomic_read(>count));
if (atomic_add_unless(>count, -1, 1))
return;
/* One active may be flushed from inside the acquire of another */
- mutex_lock_nested(>mutex, SINGLE_DEPTH_NESTING);
- __active_retire(ref);
+ if (likely(lock))
+ mutex_lock_nested(>mutex, SINGLE_DEPTH_NESTING);
+ __active_retire(ref, lock);
}
static void
node_retire(struct i915_active_request *base, struct i915_request *rq)
{
- active_retire(node_from_active(base)->ref);
+ active_retire(node_from_active(base)->ref, true);
+}
+
+static void
+node_retire_nolock(struct i915_active_request *base, struct i915_request *rq)
+{
+ active_retire(node_from_active(base)->ref, false);
}
static struct i915_active_request *
@@ -364,7 +372,7 @@ int i915_active_acquire(struct i915_acti
void i915_active_release(struct i915_active *ref)
{
debug_active_assert(ref);
- active_retire(ref);
+ active_retire(ref, true);
}
static void __active_ungrab(struct i915_active *ref)
@@ -391,7 +399,7 @@ void i915_active_ungrab(struct i915_acti
{
GEM_BUG_ON(!test_bit(I915_ACTIVE_GRAB_BIT, >flags));
- active_retire(ref);
+ active_retire(ref, true);
__active_ungrab(ref);
}
@@ -421,12 +429,13 @@ int i915_active_wait(struct i915_active
break;
}
- err = i915_active_request_retire(>base, BKL(ref));
+ err = i915_active_request_retire(>base, BKL(ref),
+node_retire_nolock);
if (err)
break;
}
- __active_retire(ref);
+ __active_retire(ref, true);
if (err)
return err;
--- a/drivers/gpu/drm/i915/i915_active.h
+++
Re: [Intel-gfx] [PATCH v2] drm/i915: Fix ref->mutex deadlock in i915_active_wait()
On Fri, Apr 10, 2020 at 07:17:38AM -0700, Sultan Alsawaf wrote:
> On Fri, Apr 10, 2020 at 11:08:38AM +0200, Greg KH wrote:
> > On Tue, Apr 07, 2020 at 12:18:09AM -0700, Sultan Alsawaf wrote:
> > > From: Sultan Alsawaf
> > >
> > > The following deadlock exists in i915_active_wait() due to a double lock
> > > on ref->mutex (call chain listed in order from top to bottom):
> > > i915_active_wait();
> > > mutex_lock_interruptible(>mutex); <-- ref->mutex first acquired
> > > i915_active_request_retire();
> > > node_retire();
> > > active_retire();
> > > mutex_lock_nested(>mutex, SINGLE_DEPTH_NESTING); <-- DEADLOCK
> > >
> > > Fix the deadlock by skipping the second ref->mutex lock when
> > > active_retire() is called through i915_active_request_retire().
> > >
> > > Note that this bug only affects 5.4 and has since been fixed in 5.5.
> > > Normally, a backport of the fix from 5.5 would be in order, but the
> > > patch set that fixes this deadlock involves massive changes that are
> > > neither feasible nor desirable for backporting [1][2][3]. Therefore,
> > > this small patch was made to address the deadlock specifically for 5.4.
> > >
> > > [1] 274cbf20fd10 ("drm/i915: Push the i915_active.retire into a worker")
> > > [2] 093b92287363 ("drm/i915: Split i915_active.mutex into an irq-safe
> > > spinlock for the rbtree")
> > > [3] 750bde2fd4ff ("drm/i915: Serialise with remote retirement")
> > >
> > > Fixes: 12c255b5dad1 ("drm/i915: Provide an i915_active.acquire callback")
> > > Cc: # 5.4.x
> > > Signed-off-by: Sultan Alsawaf
> > > ---
> > > drivers/gpu/drm/i915/i915_active.c | 27 +++
> > > drivers/gpu/drm/i915/i915_active.h | 4 ++--
> > > 2 files changed, 25 insertions(+), 6 deletions(-)
> >
> > Now queued up, thanks.
> >
> > greg k-h
>
> I'm sorry, I meant the v3 [1]. Apologies for the confusion. The v3 was picked
> into Ubuntu so that's what we're rolling with.
Ok, thanks, hopefully now I picked upthe right one...
greg k-h
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-tip:drm-tip 8/10] include/net/ax25.h:125:2: error: redefinition of enumerator 'AX25_PROTO_DAMA_MASTER'
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: dd69e63dc11c8fdabcc029b27f16e80be504ffc8
commit: c7f407a0e923c43488a7f6793d5c456addf0e8e5 [8/10] Merge remote-tracking
branch 'drm-intel/topic/core-for-CI' into drm-tip
config: x86_64-allyesconfig (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
c6eb584c64872fbb779df14acd31c1f3947f6e52)
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout c7f407a0e923c43488a7f6793d5c456addf0e8e5
# save the attached .config to linux build tree
COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
In file included from net/ipv4/arp.c:110:
>> include/net/ax25.h:125:2: error: redefinition of enumerator
>> 'AX25_PROTO_DAMA_MASTER'
AX25_PROTO_MAX = __AX25_PROTO_MAX -1
^
include/net/ax25.h:121:24: note: expanded from macro 'AX25_PROTO_MAX'
#define AX25_PROTO_MAX AX25_PROTO_DAMA_MASTER
^
include/net/ax25.h:120:2: note: previous definition is here
AX25_PROTO_DAMA_MASTER,
^
1 error generated.
--
>> drivers/xen/xen-acpi-memhotplug.c:48:7: error: implicit declaration of
>> function 'HYPERVISOR_dom0_op' [-Werror,-Wimplicit-function-declaration]
rc = HYPERVISOR_dom0_op();
^
drivers/xen/xen-acpi-memhotplug.c:48:7: note: did you mean
'HYPERVISOR_dm_op'?
arch/x86/include/asm/xen/hypercall.h:439:1: note: 'HYPERVISOR_dm_op'
declared here
HYPERVISOR_dm_op(
^
1 error generated.
--
>> drivers/regulator/mt6358-regulator.c:5:10: fatal error:
>> 'linux/mfd/mt6358/registers.h' file not found
#include
^~
1 error generated.
vim +/AX25_PROTO_DAMA_MASTER +125 include/net/ax25.h
^1da177e4c3f415 Linus Torvalds 2005-04-16 113
^1da177e4c3f415 Linus Torvalds 2005-04-16 114 enum {
^1da177e4c3f415 Linus Torvalds 2005-04-16 115 AX25_PROTO_STD_SIMPLEX,
^1da177e4c3f415 Linus Torvalds 2005-04-16 116 AX25_PROTO_STD_DUPLEX,
c7c694d196a39af Ralf Baechle 2006-03-19 117 #ifdef CONFIG_AX25_DAMA_SLAVE
^1da177e4c3f415 Linus Torvalds 2005-04-16 118 AX25_PROTO_DAMA_SLAVE,
c7c694d196a39af Ralf Baechle 2006-03-19 119 #ifdef CONFIG_AX25_DAMA_MASTER
c7c694d196a39af Ralf Baechle 2006-03-19 120 AX25_PROTO_DAMA_MASTER,
c7c694d196a39af Ralf Baechle 2006-03-19 121 #define AX25_PROTO_MAX
AX25_PROTO_DAMA_MASTER
c7c694d196a39af Ralf Baechle 2006-03-19 122 #endif
c7c694d196a39af Ralf Baechle 2006-03-19 123 #endif
c7c694d196a39af Ralf Baechle 2006-03-19 124 __AX25_PROTO_MAX,
c7c694d196a39af Ralf Baechle 2006-03-19 @125 AX25_PROTO_MAX =
__AX25_PROTO_MAX -1
^1da177e4c3f415 Linus Torvalds 2005-04-16 126 };
^1da177e4c3f415 Linus Torvalds 2005-04-16 127
:: The code at line 125 was first introduced by commit
:: c7c694d196a39af6e644e24279953d04f30362db [AX.25]: Fix potencial memory
hole.
:: TO: Ralf Baechle DL5RB
:: CC: David S. Miller
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: peel dma-fence-chains wait fences
On 10/04/2020 19:51, Venkata Sandeep Dhanalakota wrote:
From: Lionel Landwerlin
To allow faster engine to engine synchronization, peel the layer of
dma-fence-chain to expose potential i915 fences so that the
i915-request code can emit HW semaphore wait/signal operations in the
ring which is faster than waking up the host to submit unblocked
workloads after interrupt notification.
Signed-off-by: Lionel Landwerlin
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 39 +--
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 8dd651cdca39..e43b76d7e9fd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2508,6 +2508,7 @@ await_fence_array(struct i915_execbuffer *eb,
for (n = 0; n < nfences; n++) {
struct drm_syncobj *syncobj;
+ struct dma_fence_chain *chain;
unsigned int flags;
syncobj = ptr_unpack_bits(fences[n].syncobj, , 2);
@@ -2515,10 +2516,40 @@ await_fence_array(struct i915_execbuffer *eb,
if (!fences[n].dma_fence)
continue;
- err = i915_request_await_dma_fence(eb->request,
- fences[n].dma_fence);
- if (err < 0)
- return err;
+ /*
+* If we're dealing with a dma-fence-chain, peel the chain by
+* adding all of the unsignaled fences
+* (dma_fence_chain_for_each does that for us) the chain
+* points to.
+*
+* This enables us to identify waits on i915 fences and allows
+* for faster engine-to-engine synchronization using HW
+* semaphores.
+*/
+ chain = to_dma_fence_chain(fences[n].dma_fence);
+ if (chain) {
+ struct dma_fence *iter;
+
+ dma_fence_chain_for_each(iter, fences[n].dma_fence) {
The kbuild bot made me think of an interesting case.
It is possible to build a chain where the first element isn't a
dma_fence_chain.
We should handle this here like this :
if (iter_chain)
err = i915_request_await_dma_fence(eb->request, iter_chain->fence);
else
err = i915_request_await_dma_fence(eb->request, iter);
if (err < 0) {
dma_fence_put(iter);
return err;
}
+ struct dma_fence_chain *iter_chain =
+ to_dma_fence_chain(iter);
+
+ GEM_BUG_ON(!iter_chain);
+
+ err = i915_request_await_dma_fence(eb->request,
+
iter_chain->fence);
+ if (err < 0) {
+ dma_fence_put(iter);
+ return err;
+ }
+ }
+
+ } else {
+ err = i915_request_await_dma_fence(eb->request,
+ fences[n].dma_fence);
+ if (err < 0)
+ return err;
+ }
}
return 0;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Linus, please revert 7dc8f11437: regression in 5.7-rc0, hangs while attempting to run X
Hi!
> > > Beyond the fix already submitted?
> >
> > I did not get that one, can I have a pointer?
>
> What's the status of this one?
I tried updating my kernel on April 3, that one did not work, but it
did not include 721017cf4bd8.
> I'm assuming the fix is commit 721017cf4bd8 ("drm/i915/gem: Ignore
> readonly failures when updating relics"), but didn't see a reply to
> the query or a confirmation of things working..
I pulled latest tree from Linus, and this one has 721017cf4bd8. Let my
try to revert my revert, and test... yes, this one seems okay.
Something changed in the X, now it seems that only one monitor is used
for login, not both... but it now works.
Best regards,
Pavel
PS: Hmm. This is not helpful. I guess this is "N".
*
* VDPA drivers
*
VDPA drivers (VDPA_MENU) [N/y/?] (NEW) ?
There is no help available for this option.
Symbol: VDPA_MENU [=n]
Type : bool
Defined at drivers/vdpa/Kconfig:9
Prompt: VDPA drivers
Location:
-> Device Drivers
*
* VHOST drivers
*
VHOST drivers (VHOST_MENU) [Y/n/?] (NEW) ?
There is no help available for this option.
Symbol: VHOST_MENU [=y]
Type : bool
Defined at drivers/vhost/Kconfig:21
Prompt: VHOST drivers
Location:
-> Device Drivers
> Btw, Chris, that __put_user() not testing the error should at least
> have a comment. We don't have a working "__must_check" for those
> things (because they are subtle macros, not functions), but if we did,
> we'd get a compiler warning for not checking the error value.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for SAGV support for Gen12+ (rev18)
== Series Details == Series: SAGV support for Gen12+ (rev18) URL : https://patchwork.freedesktop.org/series/75129/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8289 -> Patchwork_17276 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17276 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17276, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17276/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17276: ### IGT changes ### Possible regressions * igt@i915_selftest@live@execlists: - fi-skl-lmem:[PASS][1] -> [DMESG-WARN][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8289/fi-skl-lmem/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17276/fi-skl-lmem/igt@i915_selftest@l...@execlists.html Known issues Here are the changes found in Patchwork_17276 that come from known issues: ### IGT changes ### Possible fixes * igt@kms_flip@basic-flip-vs-wf_vblank: - fi-skl-lmem:[DMESG-WARN][3] ([i915#1688]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8289/fi-skl-lmem/igt@kms_flip@basic-flip-vs-wf_vblank.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17276/fi-skl-lmem/igt@kms_flip@basic-flip-vs-wf_vblank.html Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [FAIL][5] ([i915#62] / [i915#95]) -> [SKIP][6] ([fdo#109271]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8289/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17276/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1688]: https://gitlab.freedesktop.org/drm/intel/issues/1688 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (52 -> 47) -- Additional (1): fi-kbl-7560u Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8289 -> Patchwork_17276 CI-20190529: 20190529 CI_DRM_8289: 81e3d7ff72672b6aeadbf9c0b9cc514cec9c889d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5586: 29fad328e6a1b105c8d688cafe19b1b5c19ad0c8 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17276: d05fb4a0457b591b3f67b57bd9f5786c4efe4add @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == d05fb4a0457b drm/i915: Enable SAGV support for Gen12 08b2bfe6c74c drm/i915: Restrict qgv points which don't have enough bandwidth. e1d400340158 drm/i915: Rename bw_state to new_bw_state d7dfb591ab1a drm/i915: Added required new PCode commands 86c74315ca04 drm/i915: Add TGL+ SAGV support 1d27dc3371c2 drm/i915: Separate icl and skl SAGV checking 3d65a6833e4d drm/i915: Use bw state for per crtc SAGV evaluation b7dc3af9b55a drm/i915: Add pre/post plane updates for SAGV 340b37dd96c3 drm/i915: Prepare to extract gen specific functions from intel_can_enable_sagv 5f292c54ef03 drm/i915: Add intel_atomic_get_bw_*_state helpers b247b1150e51 drm/i915: Introduce skl_plane_wm_level accessor. dd9d5971ba9b drm/i915: Eliminate magic numbers "0" and "1" from color plane e1a65ab6533f drm/i915: Start passing latency as parameter == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17276/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
