While in real life, we could never fail to grab the newly created mutex,
ww_mutex fault injection has no way to know this. Which could result
that kernels built with CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y might fail to
acquire the new crtc lock. Which results in bad things when the locks
are dropped.
See: https://bugzilla.kernel.org/show_bug.cgi?id=83341
Signed-off-by: Rob Clark <robdclark(a)gmail.com>
---
drivers/gpu/drm/drm_crtc.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 …
[View More]deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 7d7c1fd..8bb11fa 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -682,7 +682,15 @@ int drm_crtc_init_with_planes(struct drm_device *dev, struct drm_crtc *crtc,
drm_modeset_lock_all(dev);
drm_modeset_lock_init(&crtc->mutex);
/* dropped by _unlock_all(): */
- drm_modeset_lock(&crtc->mutex, config->acquire_ctx);
+ /* NOTE: use trylock here for the benefit of ww_mutex fault
+ * injection. We cannot actually fail to grab this lock (as
+ * it has only just been created), but fault injection does
+ * not know this, which can result in the this lock failing,
+ * and hilarity when we later try to drop the locks. See:
+ * https://bugzilla.kernel.org/show_bug.cgi?id=83341
+ */
+ ret = ww_mutex_trylock(&crtc->mutex.mutex);
+ WARN_ON(ret);
ret = drm_mode_object_get(dev, &crtc->base, DRM_MODE_OBJECT_CRTC);
if (ret)
--
1.9.3
[View Less]
Hello everyone,
the following patches add UVD support for older ASICs (RV6xx, RS[78]80, RV7[79]0). For everybody wanting to test it I've also uploaded a branch to FDO: http://cgit.freedesktop.org/~deathsimple/linux/log/?h=uvd-r600-release
Additionally to the patches you need UVD firmware as well, which can be found at the usual location: http://people.freedesktop.org/~agd5f/radeon_ucode/
A small Mesa patch is needed as well, cause the older hardware doesn't support field based output of …
[View More]video frames. So unfortunately VDPAU/OpenGL interop won't work either.
We can only provide best effort support for those older ASICs, but at least on my RS[78]80 based laptop it seems to work perfectly fine.
Happy testing,
Christian.
[View Less]
On Mon, Sep 8, 2014 at 7:27 AM, Michael N. Henry <mnhenry333(a)gmail.com> wrote:
> crtc->mutex is acquired in drm_modeset_lock_crtc(). The next call
> to drm_modeset_unlock_crt() would not unlock it, causing a deadlock
> during the next call to drm_modest_lock_crtc().
> ---
> drivers/gpu/drm/drm_modeset_lock.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_modeset_lock.c b/drivers/gpu/drm/drm_modeset_lock.c
> index 474e4d1..…
[View More]fab3aa8 100644
> --- a/drivers/gpu/drm/drm_modeset_lock.c
> +++ b/drivers/gpu/drm/drm_modeset_lock.c
> @@ -236,6 +236,8 @@ void drm_modeset_unlock_crtc(struct drm_crtc *crtc)
> drm_modeset_drop_locks(ctx);
> drm_modeset_acquire_fini(ctx);
>
> + drm_modeset_unlock(&crtc->mutex);
> +
drm_mode_drop_locks should drop all mutexes (and so also the crtc
mutex acquired with ctx. Also acquire_fini should complain if you
unlock afterwards.
I suspect that some other caller completely forgets to unlock the crtc
somehow, but I can't see where that happens. Can you please re-run
with CONFIG_PROVE_LOCKING enabled in your kernel build?
And a small nitpick on your patch submission: When you submit just one
patch, please don't do a cover letter - all the information you
provide in there (backtrace, bisect result) should be part of the
commit message anyway. And your patch is missing the signed-off-by
line, so can't be merged. And please also don't forget to cc relevant
mailing lists.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=83262
Alex Deucher <agd5f(a)yahoo.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|xorg-driver-ati(a)lists.x.org |dri-devel(a)lists.freedesktop
| |.org
QA Contact|xorg-team(a)lists.x.org |
Product|xorg |DRI
Component|Driver/…
[View More]Radeon |DRM/Radeon
--- Comment #1 from Alex Deucher <agd5f(a)yahoo.com> ---
Please attach your dmesg output and your xorg log.
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_display.c between commit a4bf214ffc72
("drm/i915: Move intel_ddi_set_vc_payload_alloc(false) to
haswell_crtc_disable()") from Linus' tree and commit 575f7ab754c4
("drm/i915: Pass intel_crtc to intel_disable_pipe() and
intel_wait_for_pipe_off()") from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell …
[View More] sfr(a)canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_display.c
index 18da8349a070,b912107a1392..000000000000
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@@ -4168,7 -4253,11 +4264,7 @@@ static void ironlake_crtc_disable(struc
if (intel_crtc->config.has_pch_encoder)
intel_set_pch_fifo_underrun_reporting(dev, pipe, false);
- intel_disable_pipe(dev_priv, pipe);
+ intel_disable_pipe(intel_crtc);
-
- if (intel_crtc->config.dp_encoder_is_mst)
- intel_ddi_set_vc_payload_alloc(crtc, false);
-
ironlake_pfit_disable(intel_crtc);
for_each_encoder_on_crtc(dev, crtc, encoder)
@@@ -4231,11 -4319,8 +4326,11 @@@ static void haswell_crtc_disable(struc
if (intel_crtc->config.has_pch_encoder)
intel_set_pch_fifo_underrun_reporting(dev, TRANSCODER_A, false);
- intel_disable_pipe(dev_priv, pipe);
+ intel_disable_pipe(intel_crtc);
+ if (intel_crtc->config.dp_encoder_is_mst)
+ intel_ddi_set_vc_payload_alloc(crtc, false);
+
intel_ddi_disable_transcoder_func(dev_priv, cpu_transcoder);
ironlake_pfit_disable(intel_crtc);
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=83453
Alex Deucher <agd5f(a)yahoo.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #3 from Alex Deucher <agd5f(a)yahoo.com> ---
*** This bug has been marked as a duplicate of bug 73338 ***
--
You are receiving …
[View More]this mail because:
You are the assignee for the bug.
[View Less]
https://bugs.freedesktop.org/show_bug.cgi?id=73338
--- Comment #30 from Alex Deucher <agd5f(a)yahoo.com> ---
*** Bug 83453 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=83861
Alex Deucher <alexdeucher(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |alexdeucher(a)gmail.com
--- Comment #1 from Alex Deucher <alexdeucher(a)gmail.com> ---
Please attach your dmesg output and xorg log.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=73338
--- Comment #29 from Martin Peres <martin.peres(a)ensi-bourges.fr> ---
(In reply to comment #28)
> (In reply to comment #27)
>
> P.S. You should remember that my implementation is highly experimental and
> naive (it's even tested only on my card). I can't expose some particular
> values or allow to write them. E.g. I don't know how to enable automatic fan
> management again after I've disabled it for now. What should I …
[View More]return in
> such case?
No need to hurry, finish entirely your REing before proposing an implementation
for your hardware (all the cards radeon GPUs you have). Please then ask others
with different cards to check if your implementation works on their card too.
When you got sufficient testing, propose this patch for inclusion.
Have fun!
--
You are receiving this mail because:
You are the assignee for the bug.
[View Less]