[Bug 47351] [KMS: Mobility Radeon HD 6620G] Blank screen on boot
https://bugzilla.kernel.org/show_bug.cgi?id=47351 Nick changed: What|Removed |Added CC||ka.n...@mail.ru --- Comment #7 from Nick 2013-04-30 11:39:28 --- Yes, I'm quite sure my laptop is mux-less, so I guess the card actually works but cannot output anything... I've 1.13.4 installed (and 1.14.1 is available in portage softmasked). Is there any chance I could make use of this? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 57281] Radeon: Bad performance and power consumption
https://bugzilla.kernel.org/show_bug.cgi?id=57281 --- Comment #4 from Nick 2013-04-30 11:53:07 --- Created an attachment (id=100301) --> (https://bugzilla.kernel.org/attachment.cgi?id=100301) dmesg output -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 57281] Radeon: Bad performance and power consumption
https://bugzilla.kernel.org/show_bug.cgi?id=57281 --- Comment #5 from Nick 2013-04-30 11:53:33 --- Created an attachment (id=100311) --> (https://bugzilla.kernel.org/attachment.cgi?id=100311) Xorg.0.log -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #29 from Hristo Venev --- I just noticed a regression: the GPU halts when cold boot was done by fglrx and driver is switched to radeon. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 57281] Radeon: Bad performance and power consumption
https://bugzilla.kernel.org/show_bug.cgi?id=57281 --- Comment #6 from Nick 2013-04-30 12:14:25 --- (In reply to comment #3) > (In reply to comment #0) > > After upgrading my AMD E-450-based notebook to a newer one (HP 4545s > > A4-3300-based) i noticed that in spite of noticeable higher clock rate the > > video performance is about 15-20% worse than on E-450. > > How did you measure that? - gtkperf (which is the only "test" that shows an improvement about 30%) - compiz benchmark (shows a regression) - glxgears in both "dafault window" and full-screen modes - shows a regression, too. (Yes, I'm aware it's NOT a benchmark, for instance I noticed it's very dependent on CPU part: simple change of a CPU governor may change figures dramatically, and so on...) But in my case (I use exactly the same environment except the hardware) its numbers apparently correspond well to what I "look and feel" while using the computer: how smooth the cube rotates, firefox scrolls, etc. Unfortunately, it *is* slower, hotter and gives a shorter battery life... And while I found open source driver on E-450 quite usable, I've to switch to fglrx on my new notebook so far -- having all it's disadvantages and headaches... BTW, if you can suggest a reliable benchmark, I could do the measurements... -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 47351] [KMS: Mobility Radeon HD 6620G] Blank screen on boot
https://bugzilla.kernel.org/show_bug.cgi?id=47351 --- Comment #8 from Alex Deucher 2013-04-30 12:57:39 --- (In reply to comment #7) > Yes, I'm quite sure my laptop is mux-less, so I guess the card actually works > but cannot output anything... > I've 1.13.4 installed (and 1.14.1 is available in portage softmasked). Is > there > any chance I could make use of this? You can use xrandr to configure it using the -setprovideroutputsource and -setprovideroffloadsink parameters -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 47351] [KMS: Mobility Radeon HD 6620G] Blank screen on boot
https://bugzilla.kernel.org/show_bug.cgi?id=47351 --- Comment #9 from Nick 2013-04-30 13:18:22 --- Thank you! -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 57281] Radeon: Bad performance and power consumption
https://bugzilla.kernel.org/show_bug.cgi?id=57281 --- Comment #7 from Michel Dänzer 2013-04-30 13:32:46 --- Does not enabling Option "BackingStore" in xorg.conf help? The high power usage might be due to the discrete GPU being powered on, but the X server isn't using it, so it doesn't help performance. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [RFC] mutex: w/w mutex slowpath debugging
Injects EDEADLK conditions at pseudo-random interval, with exponential
backoff up to UINT_MAX (to ensure that every lock operation still
completes in a reasonable time).
This way we can test the wound slowpath even for ww mutex users where
contention is never expected, and the ww deadlock avoidance algorithm
is only needed for correctness against malicious userspace. An example
would be protecting kernel modesetting properties, which thanks to
single-threaded X isn't really expected to contend, ever.
I've looked into using the CONFIG_FAULT_INJECTION infrastructure, but
decided against it for two reasons:
- EDEADLK handling is mandatory for ww mutex users and should never
affect the outcome of a syscall. This is in contrast to -ENOMEM
injection. So fine configurability isn't required.
- The fault injection framework only allows to set a simple
probability for failure. Now the probability that a ww mutex acquire
stage with N locks will never complete (due to too many injected
EDEADLK backoffs) is zero. But the expected number of ww_mutex_lock
operations for the completely uncontended case would be O(exp(N)).
The per-acuiqire ctx exponential backoff solution choosen here only
results in O(log N) overhead due to injection and so O(log N * N)
lock operations. This way we can fail with high probability (and so
have good test coverage even for fancy backoff and lock acquisition
paths) without running into patalogical cases.
Note that EDEADLK will only ever be injected when we managed to
acquire the lock. This prevents any behaviour changes for users which
rely on the EALREADY semantics.
Signed-off-by: Daniel Vetter
---
include/linux/mutex.h |8
kernel/mutex.c| 31 +++
lib/Kconfig.debug | 10 ++
3 files changed, 49 insertions(+)
diff --git a/include/linux/mutex.h b/include/linux/mutex.h
index 004f863..82d56ec 100644
--- a/include/linux/mutex.h
+++ b/include/linux/mutex.h
@@ -93,6 +93,10 @@ struct ww_acquire_ctx {
#ifdef CONFIG_DEBUG_LOCK_ALLOC
struct lockdep_map dep_map;
#endif
+#ifdef CONFIG_DEBUG_WW_MUTEX_SLOWPATH
+ unsigned deadlock_inject_interval;
+ unsigned deadlock_inject_countdown;
+#endif
};
struct ww_mutex {
@@ -278,6 +282,10 @@ static inline void ww_acquire_init(struct ww_acquire_ctx
*ctx,
&ww_class->acquire_key, 0);
mutex_acquire(&ctx->dep_map, 0, 0, _RET_IP_);
#endif
+#ifdef CONFIG_DEBUG_WW_MUTEX_SLOWPATH
+ ctx->deadlock_inject_interval = ctx->stamp & 0xf;
+ ctx->deadlock_inject_countdown = ctx->deadlock_inject_interval;
+#endif
}
/**
diff --git a/kernel/mutex.c b/kernel/mutex.c
index 66807c7..1cc3487 100644
--- a/kernel/mutex.c
+++ b/kernel/mutex.c
@@ -827,6 +827,35 @@ int __sched mutex_trylock(struct mutex *lock)
EXPORT_SYMBOL(mutex_trylock);
#ifndef CONFIG_DEBUG_LOCK_ALLOC
+
+#ifdef CONFIG_DEBUG_WW_MUTEX_SLOWPATH
+static int __sched
+ww_mutex_deadlock_injection(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
+{
+ if (ctx->deadlock_inject_countdown-- == 0) {
+ tmp = ctx->deadlock_inject_interval;
+ if (tmp > UINT_MAX/4)
+ tmp = UINT_MAX;
+ else
+ tmp = tmp*2 + tmp + tmp/2;
+
+ ctx->deadlock_inject_interval = tmp;
+ ctx->deadlock_inject_countdown = tmp;
+
+ ww_mutex_unlock(lock);
+
+ return -EDEADLK;
+ }
+
+ return 0;
+}
+#else
+static int __sched
+ww_mutex_deadlock_injection(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
+{
+ return 0;
+}
+#endif
int __sched
ww_mutex_lock(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
{
@@ -839,6 +868,7 @@ ww_mutex_lock(struct ww_mutex *lock, struct ww_acquire_ctx
*ctx)
if (likely(!ret)) {
ww_mutex_set_context_fastpath(lock, ctx);
mutex_set_owner(&lock->base);
+ return ww_mutex_deadlock_injection(lock, ctx);
} else
ret = __ww_mutex_lock_slowpath(lock, ctx);
return ret;
@@ -857,6 +887,7 @@ ww_mutex_lock_interruptible(struct ww_mutex *lock, struct
ww_acquire_ctx *ctx)
if (likely(!ret)) {
ww_mutex_set_context_fastpath(lock, ctx);
mutex_set_owner(&lock->base);
+ return ww_mutex_deadlock_injection(lock, ctx);
} else
ret = __ww_mutex_lock_interruptible_slowpath(lock, ctx);
return ret;
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 28be08c..8c41f73 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -547,6 +547,16 @@ config DEBUG_MUTEXES
This feature allows mutex semantics violations to be detected and
reported.
+config DEBUG_WW_MUTEX_SLOWPATH
+ bool "Wait/wound mutex debugging: Slowpath testing"
+ depends on DEBUG_KERNEL
+ help
+This feature enables slowpath testing for w/w mutex users by
+
Re: [PATCH v3 2/3] mutex: add support for wound/wait style locks, v3
On Sun, Apr 28, 2013 at 07:04:07PM +0200, Maarten Lankhorst wrote:
> Changes since RFC patch v1:
> - Updated to use atomic_long instead of atomic, since the reservation_id was
> a long.
> - added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
> - removed mutex_locked_set_reservation_id (or w/e it was called)
> Changes since RFC patch v2:
> - remove use of __mutex_lock_retval_arg, add warnings when using wrong
> combination of
>mutex_(,reserve_)lock/unlock.
> Changes since v1:
> - Add __always_inline to __mutex_lock_common, otherwise reservation paths
> can be
>triggered from normal locks, because __builtin_constant_p might evaluate
> to false
>for the constant 0 in that case. Tests for this have been added in the
> next patch.
> - Updated documentation slightly.
> Changes since v2:
> - Renamed everything to ww_mutex. (mlankhorst)
> - Added ww_acquire_ctx and ww_class. (mlankhorst)
> - Added a lot of checks for wrong api usage. (mlankhorst)
> - Documentation updates. (danvet)
While writing the kerneldoc I've carefully check that all restrictions are
enforced through debug checks somehow. I think that with full mutex debug
(including lockdep) enabled, plus the slowpath injector patch I've just
posted, _all_ interface abuse will be catched at runtime as long as all
the single-threaded/uncontended cases are exercises sufficiently.
So I think we've fully achieved level 5 on the Rusty API safety scale
here. Higher levels seem pretty hard given that the concepts are rather
fancy, but I think with the new (and much more consitent) naming, plus the
explicit introduction as (more abstruct) structures for ww_class and
ww_acquire_context the interface is about as intuitive as it gets.
So all together I'm pretty happy with what the interface looks like. And
one quick bikeshed below on the implementation.
-Daniel
>
> Signed-off-by: Maarten Lankhorst
> Signed-off-by: Daniel Vetter
> ---
> Documentation/ww-mutex-design.txt | 322 +++
> include/linux/mutex-debug.h |1
> include/linux/mutex.h | 257 +
> kernel/mutex.c| 445
> -
> lib/debug_locks.c |2
> 5 files changed, 1010 insertions(+), 17 deletions(-)
> create mode 100644 Documentation/ww-mutex-design.txt
[snip]
> +/*
> + * after acquiring lock with fastpath or when we lost out in contested
> + * slowpath, set ctx and wake up any waiters so they can recheck.
> + *
> + * This function is never called when CONFIG_DEBUG_LOCK_ALLOC is set,
> + * as the fastpath and opportunistic spinning are disabled in that case.
> + */
> +static __always_inline void
> +ww_mutex_set_context_fastpath(struct ww_mutex *lock,
> +struct ww_acquire_ctx *ctx)
> +{
> + unsigned long flags;
> + struct mutex_waiter *cur;
> +
> + ww_mutex_lock_acquired(lock, ctx, false);
> +
> + lock->ctx = ctx;
> + smp_mb__after_atomic_dec();
I think this should be
+ smp_mb__after_atomic_dec();
+ lock->ctx = ctx;
+ smp_mb();
Also I wonder a bit how much this hurts the fastpath, and whether we
should just shovel the ctx into the atomic field with a cmpxcht, like the
rt mutex code does with the current pointer.
> +
> + /*
> + * Check if lock is contended, if not there is nobody to wake up
> + */
> + if (likely(atomic_read(&lock->base.count) == 0))
> + return;
> +
> + /*
> + * Uh oh, we raced in fastpath, wake up everyone in this case,
> + * so they can see the new ctx
> + */
> + spin_lock_mutex(&lock->base.wait_lock, flags);
> + list_for_each_entry(cur, &lock->base.wait_list, list) {
> + debug_mutex_wake_waiter(&lock->base, cur);
> + wake_up_process(cur->task);
> + }
> + spin_unlock_mutex(&lock->base.wait_lock, flags);
> +}
> +
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59592] Radeon HD 5670: reproducable GPU lockups with htile enabled
https://bugs.freedesktop.org/show_bug.cgi?id=59592 --- Comment #10 from n...@detonation.org --- Sorry for the late reply. Took me some time to get my test setup working after a distribution upgrade. It seems like your patch does indeed fix the problem. I've played around with FlightGear for several hours without any lockups whatsoever with R600_HYPERZ=1. Before I tried it without your patch and got an immediate lockup. It seems like your patch is already committed to master. After upgrading to current master it continues to work flawlessly. Thanks! -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: abuse of dumb ioctls in exynos
On Mon, Apr 29, 2013 at 12:31 PM, Dave Airlie wrote: >> The reason we (currently) use the dumb buffer interface is because it >> does pretty much exactly what we need it to, as we only want linear >> RGB buffers: > > Except in the cases where it doesn't do what you want, and possibly in > the future where it does less of what you want. You've started on a > slippery slope, and I'm stopping you before you make things worse. > > You are going to have to get SoC kernel drivers to add an ioctl that > you can use, if you insist on trying to mangle all the different code > paths into a single userspace driver, then you are going to take a lot > of pain. Its the old helper library vs midlayer, you are inventing a > DDX midlayer when you should be inventing a DDX helper library. No argue there, but it would make sense to have a common set of ioctls for buffer management. The dumb buffer interface is for generic userspace but for non-generic cases there is still a need for something to prevent code duplication for the SoC people. We could have a "less dumb" interface with support for common stuff like scanout bufs, offscreen bufs, cursor bufs, CMA, overlays, etc, and with room for driver specific flags. There could also be a generic interface for 2d acceleration (solid and copy) and the sync stuff needed for it. For stuff that doesn't fit our interface there is always the possibility to add ioctls. I think the abuse of the dumb buffer interface is an indication that there is a need for something like this. -Patrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/6] drm: drm_rect and clipping for intel sprite planes v2
On Wed, Apr 24, 2013 at 06:52:33PM +0300, ville.syrj...@linux.intel.com wrote:
> Here's the latest version of my plane clipping stuff.
>
> I think it should be ready for merging. Laurent reviewed the first patch,
> and Chris reviewed the whole set.
>
> I didn't hear any bikeshedding about the location of the drm_rect
> stuff from anyone, so I'm assuming it's all good.
Entire pile merged to dinq with Dave's irc ack.
-Daniel
>
> Ville Syrjälä (6):
> drm: Add struct drm_rect and assorted utility functions
> drm: Add drm_rect_calc_{hscale, vscale}() utility functions
> drm: Add drm_rect_debug_print()
> drm: Add drm_rect_equals()
> drm/i915: Implement proper clipping for video sprites
> drm/i915: Relax the sprite scaling limits checks
>
> Documentation/DocBook/drm.tmpl | 2 +
> drivers/gpu/drm/Makefile| 3 +-
> drivers/gpu/drm/drm_rect.c | 295
>
> drivers/gpu/drm/i915/intel_sprite.c | 202 ++--
> include/drm/drm_rect.h | 160 +++
> 5 files changed, 615 insertions(+), 47 deletions(-)
> create mode 100644 drivers/gpu/drm/drm_rect.c
> create mode 100644 include/drm/drm_rect.h
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: abuse of dumb ioctls in exynos
>> Except in the cases where it doesn't do what you want, and possibly in >> the future where it does less of what you want. You've started on a >> slippery slope, and I'm stopping you before you make things worse. >> >> You are going to have to get SoC kernel drivers to add an ioctl that >> you can use, if you insist on trying to mangle all the different code >> paths into a single userspace driver, then you are going to take a lot >> of pain. Its the old helper library vs midlayer, you are inventing a >> DDX midlayer when you should be inventing a DDX helper library. > > No argue there, but it would make sense to have a common set of ioctls for > buffer management. The dumb buffer interface is for generic userspace but for > non-generic cases there is still a need for something to prevent code > duplication for the SoC people. No it means SoC people need to duplicate more code in userspace. Adding restrictive interfaces to do dumb buffer allocation is never going to end well, someone will always come up with a new buffer type that is slightly different than the previous ones you came up with for their special SoC. The old TTM APIs we had tried to do this generically, and it was too messy. I'm not sure if I can say this plainer: THIS IS NOT A GOOD IDEA AND I WON'T MERGE IT. You also defeated any hope of me taking you seriously when you suggested adding generic accel interfaces for 2D, because acceleration doesn't belong in the kernel, Lets get this straight, drm isn't fbdev, it isn't an unmaintained free for all fastest hack wins. If I catch this sort of bullshit happening in drm drivers I'll be pulling maintainer plugs out. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [RFC] mutex: w/w mutex slowpath debugging
Injects EDEADLK conditions at pseudo-random interval, with exponential
backoff up to UINT_MAX (to ensure that every lock operation still
completes in a reasonable time).
This way we can test the wound slowpath even for ww mutex users where
contention is never expected, and the ww deadlock avoidance algorithm
is only needed for correctness against malicious userspace. An example
would be protecting kernel modesetting properties, which thanks to
single-threaded X isn't really expected to contend, ever.
I've looked into using the CONFIG_FAULT_INJECTION infrastructure, but
decided against it for two reasons:
- EDEADLK handling is mandatory for ww mutex users and should never
affect the outcome of a syscall. This is in contrast to -ENOMEM
injection. So fine configurability isn't required.
- The fault injection framework only allows to set a simple
probability for failure. Now the probability that a ww mutex acquire
stage with N locks will never complete (due to too many injected
EDEADLK backoffs) is zero. But the expected number of ww_mutex_lock
operations for the completely uncontended case would be O(exp(N)).
The per-acuiqire ctx exponential backoff solution choosen here only
results in O(log N) overhead due to injection and so O(log N * N)
lock operations. This way we can fail with high probability (and so
have good test coverage even for fancy backoff and lock acquisition
paths) without running into patalogical cases.
Note that EDEADLK will only ever be injected when we managed to
acquire the lock. This prevents any behaviour changes for users which
rely on the EALREADY semantics.
v2: Drop the cargo-culted __sched (I should read docs next time
around) and annotate the non-debug case with inline to prevent gcc
from doing something horrible.
Cc: Steven Rostedt
Signed-off-by: Daniel Vetter
---
include/linux/mutex.h |8
kernel/mutex.c| 32
lib/Kconfig.debug | 10 ++
3 files changed, 50 insertions(+)
diff --git a/include/linux/mutex.h b/include/linux/mutex.h
index 004f863..82d56ec 100644
--- a/include/linux/mutex.h
+++ b/include/linux/mutex.h
@@ -93,6 +93,10 @@ struct ww_acquire_ctx {
#ifdef CONFIG_DEBUG_LOCK_ALLOC
struct lockdep_map dep_map;
#endif
+#ifdef CONFIG_DEBUG_WW_MUTEX_SLOWPATH
+ unsigned deadlock_inject_interval;
+ unsigned deadlock_inject_countdown;
+#endif
};
struct ww_mutex {
@@ -278,6 +282,10 @@ static inline void ww_acquire_init(struct ww_acquire_ctx
*ctx,
&ww_class->acquire_key, 0);
mutex_acquire(&ctx->dep_map, 0, 0, _RET_IP_);
#endif
+#ifdef CONFIG_DEBUG_WW_MUTEX_SLOWPATH
+ ctx->deadlock_inject_interval = ctx->stamp & 0xf;
+ ctx->deadlock_inject_countdown = ctx->deadlock_inject_interval;
+#endif
}
/**
diff --git a/kernel/mutex.c b/kernel/mutex.c
index 66807c7..816fdfc 100644
--- a/kernel/mutex.c
+++ b/kernel/mutex.c
@@ -827,6 +827,36 @@ int __sched mutex_trylock(struct mutex *lock)
EXPORT_SYMBOL(mutex_trylock);
#ifndef CONFIG_DEBUG_LOCK_ALLOC
+
+#ifdef CONFIG_DEBUG_WW_MUTEX_SLOWPATH
+static int
+ww_mutex_deadlock_injection(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
+{
+ if (ctx->deadlock_inject_countdown-- == 0) {
+ tmp = ctx->deadlock_inject_interval;
+ if (tmp > UINT_MAX/4)
+ tmp = UINT_MAX;
+ else
+ tmp = tmp*2 + tmp + tmp/2;
+
+ ctx->deadlock_inject_interval = tmp;
+ ctx->deadlock_inject_countdown = tmp;
+
+ ww_mutex_unlock(lock);
+
+ return -EDEADLK;
+ }
+
+ return 0;
+}
+#else
+static inline int
+ww_mutex_deadlock_injection(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
+{
+ return 0;
+}
+#endif
+
int __sched
ww_mutex_lock(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
{
@@ -839,6 +869,7 @@ ww_mutex_lock(struct ww_mutex *lock, struct ww_acquire_ctx
*ctx)
if (likely(!ret)) {
ww_mutex_set_context_fastpath(lock, ctx);
mutex_set_owner(&lock->base);
+ return ww_mutex_deadlock_injection(lock, ctx);
} else
ret = __ww_mutex_lock_slowpath(lock, ctx);
return ret;
@@ -857,6 +888,7 @@ ww_mutex_lock_interruptible(struct ww_mutex *lock, struct
ww_acquire_ctx *ctx)
if (likely(!ret)) {
ww_mutex_set_context_fastpath(lock, ctx);
mutex_set_owner(&lock->base);
+ return ww_mutex_deadlock_injection(lock, ctx);
} else
ret = __ww_mutex_lock_interruptible_slowpath(lock, ctx);
return ret;
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 28be08c..8c41f73 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -547,6 +547,16 @@ config DEBUG_MUTEXES
This feature allows mutex semantics violations to be detected and
reported.
+config DEBUG_WW_MUTEX_SLOWPATH
Re: abuse of dumb ioctls in exynos
On Tue, Apr 30, 2013 at 10:19 PM, Dave Airlie wrote: >>> Except in the cases where it doesn't do what you want, and possibly in >>> the future where it does less of what you want. You've started on a >>> slippery slope, and I'm stopping you before you make things worse. >>> >>> You are going to have to get SoC kernel drivers to add an ioctl that >>> you can use, if you insist on trying to mangle all the different code >>> paths into a single userspace driver, then you are going to take a lot >>> of pain. Its the old helper library vs midlayer, you are inventing a >>> DDX midlayer when you should be inventing a DDX helper library. >> >> No argue there, but it would make sense to have a common set of ioctls for >> buffer management. The dumb buffer interface is for generic userspace but for >> non-generic cases there is still a need for something to prevent code >> duplication for the SoC people. > > No it means SoC people need to duplicate more code in userspace. > > Adding restrictive interfaces to do dumb buffer allocation is never > going to end well, > someone will always come up with a new buffer type that is slightly > different than > the previous ones you came up with for their special SoC. The old TTM > APIs we had > tried to do this generically, and it was too messy. I'm not sure if I > can say this plainer: > THIS IS NOT A GOOD IDEA AND I WON'T MERGE IT. I certainly don't have the big picture of this and I trust you in your decision. My idea was not to have a restrictive interface but to have something thin for the most common parts and allow it to be extended for every use case. But if it didn't work before there is little point in doing the same mistake again. And ofc there is no such thing as a non restrictive generic interface. > You also defeated any hope of me taking you seriously when you suggested > adding > generic accel interfaces for 2D, because acceleration doesn't belong > in the kernel, > Lets get this straight, drm isn't fbdev, it isn't an unmaintained free > for all fastest hack > wins. If I catch this sort of bullshit happening in drm drivers I'll > be pulling maintainer > plugs out. Don't worry, there are no such patches coming your way. Thanks Patrik ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60553] [trine2] wrong colors when executed fullscreen
https://bugs.freedesktop.org/show_bug.cgi?id=60553 Laurent carlier changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Laurent carlier --- It seem now fixed with: 3.1 (Core Profile) Mesa 9.2.0 (git-c4bea00) So, closing -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64096] New: LLVM RV790 etqw regression since R600: Packetize instructions
https://bugs.freedesktop.org/show_bug.cgi?id=64096 Priority: medium Bug ID: 64096 Assignee: dri-devel@lists.freedesktop.org Summary: LLVM RV790 etqw regression since R600: Packetize instructions Severity: normal Classification: Unclassified OS: All Reporter: adf.li...@gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa rv790 with etqw getting a green tint in levels on current llvm/mesa heads. llvm bisected to below, while actually sitting on that there are more corruptions than just the tint. commit 25f259cde28860ea76c2f5628010968945a28edb Author: Vincent Lejeune Date: Tue Apr 30 00:14:27 2013 + R600: Packetize instructions git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180760 91177308-0d34-0410-b5e6-96231b3b80d8 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64096] LLVM RV790 etqw regression since R600: Packetize instructions
https://bugs.freedesktop.org/show_bug.cgi?id=64096 --- Comment #1 from Andy Furniss --- Testing further some of the mesa demos are also wrong - not that I have re- bisected, just assume same issue, on heads - gloss = blank. gears, fbo_firecube, gearbox = too dark. shadowtex = shadow misaligned -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
radeon pm bug?
Hi, In radeon_atombios.c file, radeon_atombios_parse_power_table_6 function, the power state is selected using the state array index: power_state = (union pplib_power_state *)&state_array->states[i]; The state array has variable sized states which size should be computed as said in the atombios.h file, definition of ATOM_PPLIB_STATE_V2 struct. Bug? regards, -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64099] New: Mesa 9.0.3 implementation error: In _mesa_DeleteHashTable, found non-freed data
https://bugs.freedesktop.org/show_bug.cgi?id=64099 Priority: medium Bug ID: 64099 Assignee: dri-devel@lists.freedesktop.org Summary: Mesa 9.0.3 implementation error: In _mesa_DeleteHashTable, found non-freed data Severity: minor Classification: Unclassified OS: Linux (All) Reporter: bogoman...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: 9.0 Component: Drivers/Gallium/r600 Product: Mesa I'm playing around with GL, and I'm receiving this message when my application ends: "Mesa 9.0.3 implementation error: In _mesa_DeleteHashTable, found non-freed data Please report at bugs.freedesktop.org" The problem seems to be with GL_ARB_debug_output, since the message only appears if I make a call to glDebugMessageInsertARB during my application. If you need any more information, please ask. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: fix dmabuf vmap support
From: Dave Airlie Sometimes that extra semicolon can really be hard to spot. Cc: Imre Deak Signed-off-by: Dave Airlie --- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/i915_gem_dmabuf.c index 30485e9..dc53a52 100644 --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c @@ -129,7 +129,7 @@ static void *i915_gem_dmabuf_vmap(struct dma_buf *dma_buf) goto error; i = 0; - for_each_sg_page(obj->pages->sgl, &sg_iter, obj->pages->nents, 0); + for_each_sg_page(obj->pages->sgl, &sg_iter, obj->pages->nents, 0) pages[i++] = sg_page_iter_page(&sg_iter); obj->dma_buf_vmapping = vmap(pages, i, 0, PAGE_KERNEL); -- 1.8.1.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: manual merge of the drm-intel tree with the drm tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/i915_reg.h between commit a65851af5938 ("drm/i915:
Make data/link N value power of two") from the drm tree and commit
72419203cab9 ("drm/i915: hw state readout support for fdi m/n") from the
drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/i915_reg.h
index 83f9c26,b5d87bd..000
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@@ -2652,11 -2774,11 +2774,12 @@@
#define _PIPEB_GMCH_DATA_M0x71050
/* Transfer unit size for display port - 1, default is 0x3f (for TU size 64)
*/
-#define PIPE_GMCH_DATA_M_TU_SIZE_MASK (0x3f << 25)
-#define PIPE_GMCH_DATA_M_TU_SIZE_SHIFT 25
+#define TU_SIZE(x) (((x)-1) << 25) /* default size 64 */
+#define TU_SIZE_MASK (0x3f << 25)
+ #define TU_SIZE_SHIFT25
-#define PIPE_GMCH_DATA_M_MASK (0xff)
+#define DATA_LINK_M_N_MASK (0xff)
+#define DATA_LINK_N_MAX (0x80)
#define _PIPEA_GMCH_DATA_N0x70054
#define _PIPEB_GMCH_DATA_N0x71054
pgpY45IHSKOJ9.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/udl: avoid swiotlb for imported vmap buffers.
Since we ask the dmabuf owner to map the dma-buf into our device
address space, but for udl at present that is the CPU address space,
since we don't DMA directly from the mapped buffer.
However if we don't set a dma mask on the usb device, the mapping
ends up using swiotlb on machines that have it enabled, which
is less than desireable.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/udl/udl_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 0ce2d71..6770e1b 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -293,6 +293,7 @@ int udl_driver_load(struct drm_device *dev, unsigned long
flags)
udl->ddev = dev;
dev->dev_private = udl;
+ dma_set_mask(dev->dev, DMA_BIT_MASK(64));
if (!udl_parse_vendor_descriptor(dev, dev->usbdev)) {
DRM_ERROR("firmware not recognized. Assume incompatible
device\n");
goto err;
--
1.8.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
drm-openchrome status (or will it be in Kernel 3.10?)
On Tue, Apr 30, 2013 at 2:17 AM, Johannes Obermayr wrote: > Hi James, > > Linus recently released Kernel 3.9, merge window for Kernel 3.10 has been > opened, and the question is whether drm-openchrome will be part of the new > Kernel version. Johannes, you misunderstand merge window. The merge window is for stuff to go from toplevel maintainers to Linus, not for new stuff to appear and be merged. Dave.
drm-openchrome status (or will it be in Kernel 3.10?)
On Tue, Apr 30, 2013 at 7:27 AM, Johannes Obermayr wrote: > Am Dienstag, 30. April 2013, 06:06:22 schrieb Dave Airlie: >> On Tue, Apr 30, 2013 at 2:17 AM, Johannes Obermayr >> wrote: >> > Hi James, >> > >> > Linus recently released Kernel 3.9, merge window for Kernel 3.10 has been >> > opened, and the question is whether drm-openchrome will be part of the new >> > Kernel version. >> >> Johannes, >> >> you misunderstand merge window. The merge window is for stuff to go >> from toplevel maintainers to Linus, not for new stuff to appear and be >> merged. > > Dave, > > I know you maintain also a merge window for drm stuff which starts at ~ rc6. > > But I am unsure when it closes: When Linus opens his merge window or when you > forward your main drm pull request to Linus. > First case means it is definitely too late for drm-openchrome in 3.10. Second > case means there can be hope (depending on James' answer) ... > > But regarding your answer I assume first case is right. Once Linus opens his window, I won't accept anything major that hasn't been posted to the list for review before. I generally have a lag time of hoovering up on the list stuff, but something like this that has never been posted would have no hope. Dave.
[PATCH] mgag200 code cleanup patches
>> >> Christopher Harvey (3): >> drm/mgag200: Remove pointless call to drm_fb_get_bpp_depth >> drm/mgag200: Pass driver specific mga_device in driver functions >> drm/mgag200: Remove extra variable assigns >> >> drivers/gpu/drm/mgag200/mgag200_fb.c | 3 --- >> drivers/gpu/drm/mgag200/mgag200_main.c | 2 -- >> drivers/gpu/drm/mgag200/mgag200_mode.c | 7 +++ >> 3 files changed, 3 insertions(+), 9 deletions(-) > > the drm-next branch is what gets merged into merge windows, right? > http://cgit.freedesktop.org/~airlied/linux/ > Yes I just merged them all here now, and pushed out the branch. Dave.
[Bug 26345] [845G] CPU/GPU incoherency
https://bugs.freedesktop.org/show_bug.cgi?id=26345 --- Comment #159 from Gy?rgy Ball? --- Something is broken in the 3.8 kernel. When I'm using it, the colour depth is low, and my system freezes when I try to suspend the computer. I don't know if it caused by the applied workaround or not, but the problem gone if I downgrade to kernel version 3.7. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130430/15906769/attachment.html>
[PATCH 4/4] ARM: EXYNOS: remove parent device for hdmiphy clock
On Mon, Apr 29, 2013 at 11:07 PM, Sylwester Nawrocki
wrote:
> Hi,
>
> On 04/29/2013 07:04 PM, Sean Paul wrote:
>> On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma
>> wrote:
>>> Hdmiphy clock flows from hdmiphy hw to hdmi ip and mixer. It is commonly
>>> accessed among hdmi and hdmiphy driver. During power cycle, each of these
>>> driver decrements the ref-count and ensures that last user disables the
>>> clock. Setting parrent device to none ensure that both the drivers gets
>>> access to the clock.
>>>
>>
>> This seems like the wrong solution. I think you should be trying to
>> isolate its usage to one driver, instead of removing devname.
>
> And files:
> arch/arm/mach-exynos/clock-exynos4.c
> arch/arm/mach-exynos/clock-exynos5.c
>
> are not existent in linux-next for some time already. Since 3.10 the
> common clock API driver is used. It also shows that very few people
> actually test their patches against -next... :(
>
> Regards,
> Sylwester
>
>> Sean
>>
Thanks Sean, Sylwester,
I will rebase drm hdmi driver to pinctrl, CCF and then post this series
with suggested rework.
regards,
Rahul Sharma.
>>> Signed-off-by: Rahul Sharma
>>> ---
>>> arch/arm/mach-exynos/clock-exynos4.c |1 -
>>> arch/arm/mach-exynos/clock-exynos5.c |1 -
>>> 2 files changed, 2 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-exynos/clock-exynos4.c
>>> b/arch/arm/mach-exynos/clock-exynos4.c
>>> index 8a8468d..a43afcd 100644
>>> --- a/arch/arm/mach-exynos/clock-exynos4.c
>>> +++ b/arch/arm/mach-exynos/clock-exynos4.c
>>> @@ -562,7 +562,6 @@ static struct clk exynos4_init_clocks_off[] = {
>>> .ctrlbit= (1 << 3),
>>> }, {
>>> .name = "hdmiphy",
>>> - .devname= "exynos4-hdmi",
>>> .enable = exynos4_clk_hdmiphy_ctrl,
>>> .ctrlbit= (1 << 0),
>>> }, {
>>> diff --git a/arch/arm/mach-exynos/clock-exynos5.c
>>> b/arch/arm/mach-exynos/clock-exynos5.c
>>> index b0ea31f..4f39027 100644
>>> --- a/arch/arm/mach-exynos/clock-exynos5.c
>>> +++ b/arch/arm/mach-exynos/clock-exynos5.c
>>> @@ -690,7 +690,6 @@ static struct clk exynos5_init_clocks_off[] = {
>>> .ctrlbit= (1 << 6),
>>> }, {
>>> .name = "hdmiphy",
>>> - .devname= "exynos5-hdmi",
>>> .enable = exynos5_clk_hdmiphy_ctrl,
>>> .ctrlbit= (1 << 0),
>>> }, {
>>> --
>>> 1.7.10.4
>
--
Regards,
Rahul Sharma,
email to: rahul.sharma at samsung.com
Samsung India.
[Bug 26345] [845G] CPU/GPU incoherency
https://bugs.freedesktop.org/show_bug.cgi?id=26345 --- Comment #160 from Jani Nikula --- (In reply to comment #159) > Something is broken in the 3.8 kernel. When I'm using it, the colour depth > is low, and my system freezes when I try to suspend the computer. I don't > know if it caused by the applied workaround or not, but the problem gone if > I downgrade to kernel version 3.7. Please file a new bug with a detailed description of your symptoms instead of cluttering this one. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130430/b7c3006b/attachment.html>
[Bug 47351] [KMS: Mobility Radeon HD 6620G] Blank screen on boot
https://bugzilla.kernel.org/show_bug.cgi?id=47351 Nick changed: What|Removed |Added CC||ka.nick at mail.ru --- Comment #7 from Nick 2013-04-30 11:39:28 --- Yes, I'm quite sure my laptop is mux-less, so I guess the card actually works but cannot output anything... I've 1.13.4 installed (and 1.14.1 is available in portage softmasked). Is there any chance I could make use of this? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 57281] Radeon: Bad performance and power consumption
https://bugzilla.kernel.org/show_bug.cgi?id=57281 --- Comment #4 from Nick 2013-04-30 11:53:07 --- Created an attachment (id=100301) --> (https://bugzilla.kernel.org/attachment.cgi?id=100301) dmesg output -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 57281] Radeon: Bad performance and power consumption
https://bugzilla.kernel.org/show_bug.cgi?id=57281 --- Comment #5 from Nick 2013-04-30 11:53:33 --- Created an attachment (id=100311) --> (https://bugzilla.kernel.org/attachment.cgi?id=100311) Xorg.0.log -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #29 from Hristo Venev --- I just noticed a regression: the GPU halts when cold boot was done by fglrx and driver is switched to radeon. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130430/8f1d641d/attachment.html>
[Bug 57281] Radeon: Bad performance and power consumption
https://bugzilla.kernel.org/show_bug.cgi?id=57281 --- Comment #6 from Nick 2013-04-30 12:14:25 --- (In reply to comment #3) > (In reply to comment #0) > > After upgrading my AMD E-450-based notebook to a newer one (HP 4545s > > A4-3300-based) i noticed that in spite of noticeable higher clock rate the > > video performance is about 15-20% worse than on E-450. > > How did you measure that? - gtkperf (which is the only "test" that shows an improvement about 30%) - compiz benchmark (shows a regression) - glxgears in both "dafault window" and full-screen modes - shows a regression, too. (Yes, I'm aware it's NOT a benchmark, for instance I noticed it's very dependent on CPU part: simple change of a CPU governor may change figures dramatically, and so on...) But in my case (I use exactly the same environment except the hardware) its numbers apparently correspond well to what I "look and feel" while using the computer: how smooth the cube rotates, firefox scrolls, etc. Unfortunately, it *is* slower, hotter and gives a shorter battery life... And while I found open source driver on E-450 quite usable, I've to switch to fglrx on my new notebook so far -- having all it's disadvantages and headaches... BTW, if you can suggest a reliable benchmark, I could do the measurements... -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 47351] [KMS: Mobility Radeon HD 6620G] Blank screen on boot
https://bugzilla.kernel.org/show_bug.cgi?id=47351 --- Comment #8 from Alex Deucher 2013-04-30 12:57:39 --- (In reply to comment #7) > Yes, I'm quite sure my laptop is mux-less, so I guess the card actually works > but cannot output anything... > I've 1.13.4 installed (and 1.14.1 is available in portage softmasked). Is > there > any chance I could make use of this? You can use xrandr to configure it using the -setprovideroutputsource and -setprovideroffloadsink parameters -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 47351] [KMS: Mobility Radeon HD 6620G] Blank screen on boot
https://bugzilla.kernel.org/show_bug.cgi?id=47351 --- Comment #9 from Nick 2013-04-30 13:18:22 --- Thank you! -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 57281] Radeon: Bad performance and power consumption
https://bugzilla.kernel.org/show_bug.cgi?id=57281 --- Comment #7 from Michel D?nzer 2013-04-30 13:32:46 --- Does not enabling Option "BackingStore" in xorg.conf help? The high power usage might be due to the discrete GPU being powered on, but the X server isn't using it, so it doesn't help performance. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH] [RFC] mutex: w/w mutex slowpath debugging
Injects EDEADLK conditions at pseudo-random interval, with exponential
backoff up to UINT_MAX (to ensure that every lock operation still
completes in a reasonable time).
This way we can test the wound slowpath even for ww mutex users where
contention is never expected, and the ww deadlock avoidance algorithm
is only needed for correctness against malicious userspace. An example
would be protecting kernel modesetting properties, which thanks to
single-threaded X isn't really expected to contend, ever.
I've looked into using the CONFIG_FAULT_INJECTION infrastructure, but
decided against it for two reasons:
- EDEADLK handling is mandatory for ww mutex users and should never
affect the outcome of a syscall. This is in contrast to -ENOMEM
injection. So fine configurability isn't required.
- The fault injection framework only allows to set a simple
probability for failure. Now the probability that a ww mutex acquire
stage with N locks will never complete (due to too many injected
EDEADLK backoffs) is zero. But the expected number of ww_mutex_lock
operations for the completely uncontended case would be O(exp(N)).
The per-acuiqire ctx exponential backoff solution choosen here only
results in O(log N) overhead due to injection and so O(log N * N)
lock operations. This way we can fail with high probability (and so
have good test coverage even for fancy backoff and lock acquisition
paths) without running into patalogical cases.
Note that EDEADLK will only ever be injected when we managed to
acquire the lock. This prevents any behaviour changes for users which
rely on the EALREADY semantics.
Signed-off-by: Daniel Vetter
---
include/linux/mutex.h |8
kernel/mutex.c| 31 +++
lib/Kconfig.debug | 10 ++
3 files changed, 49 insertions(+)
diff --git a/include/linux/mutex.h b/include/linux/mutex.h
index 004f863..82d56ec 100644
--- a/include/linux/mutex.h
+++ b/include/linux/mutex.h
@@ -93,6 +93,10 @@ struct ww_acquire_ctx {
#ifdef CONFIG_DEBUG_LOCK_ALLOC
struct lockdep_map dep_map;
#endif
+#ifdef CONFIG_DEBUG_WW_MUTEX_SLOWPATH
+ unsigned deadlock_inject_interval;
+ unsigned deadlock_inject_countdown;
+#endif
};
struct ww_mutex {
@@ -278,6 +282,10 @@ static inline void ww_acquire_init(struct ww_acquire_ctx
*ctx,
&ww_class->acquire_key, 0);
mutex_acquire(&ctx->dep_map, 0, 0, _RET_IP_);
#endif
+#ifdef CONFIG_DEBUG_WW_MUTEX_SLOWPATH
+ ctx->deadlock_inject_interval = ctx->stamp & 0xf;
+ ctx->deadlock_inject_countdown = ctx->deadlock_inject_interval;
+#endif
}
/**
diff --git a/kernel/mutex.c b/kernel/mutex.c
index 66807c7..1cc3487 100644
--- a/kernel/mutex.c
+++ b/kernel/mutex.c
@@ -827,6 +827,35 @@ int __sched mutex_trylock(struct mutex *lock)
EXPORT_SYMBOL(mutex_trylock);
#ifndef CONFIG_DEBUG_LOCK_ALLOC
+
+#ifdef CONFIG_DEBUG_WW_MUTEX_SLOWPATH
+static int __sched
+ww_mutex_deadlock_injection(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
+{
+ if (ctx->deadlock_inject_countdown-- == 0) {
+ tmp = ctx->deadlock_inject_interval;
+ if (tmp > UINT_MAX/4)
+ tmp = UINT_MAX;
+ else
+ tmp = tmp*2 + tmp + tmp/2;
+
+ ctx->deadlock_inject_interval = tmp;
+ ctx->deadlock_inject_countdown = tmp;
+
+ ww_mutex_unlock(lock);
+
+ return -EDEADLK;
+ }
+
+ return 0;
+}
+#else
+static int __sched
+ww_mutex_deadlock_injection(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
+{
+ return 0;
+}
+#endif
int __sched
ww_mutex_lock(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
{
@@ -839,6 +868,7 @@ ww_mutex_lock(struct ww_mutex *lock, struct ww_acquire_ctx
*ctx)
if (likely(!ret)) {
ww_mutex_set_context_fastpath(lock, ctx);
mutex_set_owner(&lock->base);
+ return ww_mutex_deadlock_injection(lock, ctx);
} else
ret = __ww_mutex_lock_slowpath(lock, ctx);
return ret;
@@ -857,6 +887,7 @@ ww_mutex_lock_interruptible(struct ww_mutex *lock, struct
ww_acquire_ctx *ctx)
if (likely(!ret)) {
ww_mutex_set_context_fastpath(lock, ctx);
mutex_set_owner(&lock->base);
+ return ww_mutex_deadlock_injection(lock, ctx);
} else
ret = __ww_mutex_lock_interruptible_slowpath(lock, ctx);
return ret;
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 28be08c..8c41f73 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -547,6 +547,16 @@ config DEBUG_MUTEXES
This feature allows mutex semantics violations to be detected and
reported.
+config DEBUG_WW_MUTEX_SLOWPATH
+ bool "Wait/wound mutex debugging: Slowpath testing"
+ depends on DEBUG_KERNEL
+ help
+This feature enables slowpath testing for w/w mutex users by
+
[PATCH v3 2/3] mutex: add support for wound/wait style locks, v3
On Sun, Apr 28, 2013 at 07:04:07PM +0200, Maarten Lankhorst wrote:
> Changes since RFC patch v1:
> - Updated to use atomic_long instead of atomic, since the reservation_id was
> a long.
> - added mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow
> - removed mutex_locked_set_reservation_id (or w/e it was called)
> Changes since RFC patch v2:
> - remove use of __mutex_lock_retval_arg, add warnings when using wrong
> combination of
>mutex_(,reserve_)lock/unlock.
> Changes since v1:
> - Add __always_inline to __mutex_lock_common, otherwise reservation paths
> can be
>triggered from normal locks, because __builtin_constant_p might evaluate
> to false
>for the constant 0 in that case. Tests for this have been added in the
> next patch.
> - Updated documentation slightly.
> Changes since v2:
> - Renamed everything to ww_mutex. (mlankhorst)
> - Added ww_acquire_ctx and ww_class. (mlankhorst)
> - Added a lot of checks for wrong api usage. (mlankhorst)
> - Documentation updates. (danvet)
While writing the kerneldoc I've carefully check that all restrictions are
enforced through debug checks somehow. I think that with full mutex debug
(including lockdep) enabled, plus the slowpath injector patch I've just
posted, _all_ interface abuse will be catched at runtime as long as all
the single-threaded/uncontended cases are exercises sufficiently.
So I think we've fully achieved level 5 on the Rusty API safety scale
here. Higher levels seem pretty hard given that the concepts are rather
fancy, but I think with the new (and much more consitent) naming, plus the
explicit introduction as (more abstruct) structures for ww_class and
ww_acquire_context the interface is about as intuitive as it gets.
So all together I'm pretty happy with what the interface looks like. And
one quick bikeshed below on the implementation.
-Daniel
>
> Signed-off-by: Maarten Lankhorst
> Signed-off-by: Daniel Vetter
> ---
> Documentation/ww-mutex-design.txt | 322 +++
> include/linux/mutex-debug.h |1
> include/linux/mutex.h | 257 +
> kernel/mutex.c| 445
> -
> lib/debug_locks.c |2
> 5 files changed, 1010 insertions(+), 17 deletions(-)
> create mode 100644 Documentation/ww-mutex-design.txt
[snip]
> +/*
> + * after acquiring lock with fastpath or when we lost out in contested
> + * slowpath, set ctx and wake up any waiters so they can recheck.
> + *
> + * This function is never called when CONFIG_DEBUG_LOCK_ALLOC is set,
> + * as the fastpath and opportunistic spinning are disabled in that case.
> + */
> +static __always_inline void
> +ww_mutex_set_context_fastpath(struct ww_mutex *lock,
> +struct ww_acquire_ctx *ctx)
> +{
> + unsigned long flags;
> + struct mutex_waiter *cur;
> +
> + ww_mutex_lock_acquired(lock, ctx, false);
> +
> + lock->ctx = ctx;
> + smp_mb__after_atomic_dec();
I think this should be
+ smp_mb__after_atomic_dec();
+ lock->ctx = ctx;
+ smp_mb();
Also I wonder a bit how much this hurts the fastpath, and whether we
should just shovel the ctx into the atomic field with a cmpxcht, like the
rt mutex code does with the current pointer.
> +
> + /*
> + * Check if lock is contended, if not there is nobody to wake up
> + */
> + if (likely(atomic_read(&lock->base.count) == 0))
> + return;
> +
> + /*
> + * Uh oh, we raced in fastpath, wake up everyone in this case,
> + * so they can see the new ctx
> + */
> + spin_lock_mutex(&lock->base.wait_lock, flags);
> + list_for_each_entry(cur, &lock->base.wait_list, list) {
> + debug_mutex_wake_waiter(&lock->base, cur);
> + wake_up_process(cur->task);
> + }
> + spin_unlock_mutex(&lock->base.wait_lock, flags);
> +}
> +
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 59592] Radeon HD 5670: reproducable GPU lockups with htile enabled
https://bugs.freedesktop.org/show_bug.cgi?id=59592 --- Comment #10 from nine at detonation.org --- Sorry for the late reply. Took me some time to get my test setup working after a distribution upgrade. It seems like your patch does indeed fix the problem. I've played around with FlightGear for several hours without any lockups whatsoever with R600_HYPERZ=1. Before I tried it without your patch and got an immediate lockup. It seems like your patch is already committed to master. After upgrading to current master it continues to work flawlessly. Thanks! -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130430/c09690bf/attachment.html>
abuse of dumb ioctls in exynos
On Mon, Apr 29, 2013 at 12:31 PM, Dave Airlie wrote: >> The reason we (currently) use the dumb buffer interface is because it >> does pretty much exactly what we need it to, as we only want linear >> RGB buffers: > > Except in the cases where it doesn't do what you want, and possibly in > the future where it does less of what you want. You've started on a > slippery slope, and I'm stopping you before you make things worse. > > You are going to have to get SoC kernel drivers to add an ioctl that > you can use, if you insist on trying to mangle all the different code > paths into a single userspace driver, then you are going to take a lot > of pain. Its the old helper library vs midlayer, you are inventing a > DDX midlayer when you should be inventing a DDX helper library. No argue there, but it would make sense to have a common set of ioctls for buffer management. The dumb buffer interface is for generic userspace but for non-generic cases there is still a need for something to prevent code duplication for the SoC people. We could have a "less dumb" interface with support for common stuff like scanout bufs, offscreen bufs, cursor bufs, CMA, overlays, etc, and with room for driver specific flags. There could also be a generic interface for 2d acceleration (solid and copy) and the sync stuff needed for it. For stuff that doesn't fit our interface there is always the possibility to add ioctls. I think the abuse of the dumb buffer interface is an indication that there is a need for something like this. -Patrik
[PATCH 0/6] drm: drm_rect and clipping for intel sprite planes v2
On Wed, Apr 24, 2013 at 06:52:33PM +0300, ville.syrjala at linux.intel.com
wrote:
> Here's the latest version of my plane clipping stuff.
>
> I think it should be ready for merging. Laurent reviewed the first patch,
> and Chris reviewed the whole set.
>
> I didn't hear any bikeshedding about the location of the drm_rect
> stuff from anyone, so I'm assuming it's all good.
Entire pile merged to dinq with Dave's irc ack.
-Daniel
>
> Ville Syrj?l? (6):
> drm: Add struct drm_rect and assorted utility functions
> drm: Add drm_rect_calc_{hscale, vscale}() utility functions
> drm: Add drm_rect_debug_print()
> drm: Add drm_rect_equals()
> drm/i915: Implement proper clipping for video sprites
> drm/i915: Relax the sprite scaling limits checks
>
> Documentation/DocBook/drm.tmpl | 2 +
> drivers/gpu/drm/Makefile| 3 +-
> drivers/gpu/drm/drm_rect.c | 295
>
> drivers/gpu/drm/i915/intel_sprite.c | 202 ++--
> include/drm/drm_rect.h | 160 +++
> 5 files changed, 615 insertions(+), 47 deletions(-)
> create mode 100644 drivers/gpu/drm/drm_rect.c
> create mode 100644 include/drm/drm_rect.h
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] [RFC] mutex: w/w mutex slowpath debugging
Injects EDEADLK conditions at pseudo-random interval, with exponential
backoff up to UINT_MAX (to ensure that every lock operation still
completes in a reasonable time).
This way we can test the wound slowpath even for ww mutex users where
contention is never expected, and the ww deadlock avoidance algorithm
is only needed for correctness against malicious userspace. An example
would be protecting kernel modesetting properties, which thanks to
single-threaded X isn't really expected to contend, ever.
I've looked into using the CONFIG_FAULT_INJECTION infrastructure, but
decided against it for two reasons:
- EDEADLK handling is mandatory for ww mutex users and should never
affect the outcome of a syscall. This is in contrast to -ENOMEM
injection. So fine configurability isn't required.
- The fault injection framework only allows to set a simple
probability for failure. Now the probability that a ww mutex acquire
stage with N locks will never complete (due to too many injected
EDEADLK backoffs) is zero. But the expected number of ww_mutex_lock
operations for the completely uncontended case would be O(exp(N)).
The per-acuiqire ctx exponential backoff solution choosen here only
results in O(log N) overhead due to injection and so O(log N * N)
lock operations. This way we can fail with high probability (and so
have good test coverage even for fancy backoff and lock acquisition
paths) without running into patalogical cases.
Note that EDEADLK will only ever be injected when we managed to
acquire the lock. This prevents any behaviour changes for users which
rely on the EALREADY semantics.
v2: Drop the cargo-culted __sched (I should read docs next time
around) and annotate the non-debug case with inline to prevent gcc
from doing something horrible.
Cc: Steven Rostedt
Signed-off-by: Daniel Vetter
---
include/linux/mutex.h |8
kernel/mutex.c| 32
lib/Kconfig.debug | 10 ++
3 files changed, 50 insertions(+)
diff --git a/include/linux/mutex.h b/include/linux/mutex.h
index 004f863..82d56ec 100644
--- a/include/linux/mutex.h
+++ b/include/linux/mutex.h
@@ -93,6 +93,10 @@ struct ww_acquire_ctx {
#ifdef CONFIG_DEBUG_LOCK_ALLOC
struct lockdep_map dep_map;
#endif
+#ifdef CONFIG_DEBUG_WW_MUTEX_SLOWPATH
+ unsigned deadlock_inject_interval;
+ unsigned deadlock_inject_countdown;
+#endif
};
struct ww_mutex {
@@ -278,6 +282,10 @@ static inline void ww_acquire_init(struct ww_acquire_ctx
*ctx,
&ww_class->acquire_key, 0);
mutex_acquire(&ctx->dep_map, 0, 0, _RET_IP_);
#endif
+#ifdef CONFIG_DEBUG_WW_MUTEX_SLOWPATH
+ ctx->deadlock_inject_interval = ctx->stamp & 0xf;
+ ctx->deadlock_inject_countdown = ctx->deadlock_inject_interval;
+#endif
}
/**
diff --git a/kernel/mutex.c b/kernel/mutex.c
index 66807c7..816fdfc 100644
--- a/kernel/mutex.c
+++ b/kernel/mutex.c
@@ -827,6 +827,36 @@ int __sched mutex_trylock(struct mutex *lock)
EXPORT_SYMBOL(mutex_trylock);
#ifndef CONFIG_DEBUG_LOCK_ALLOC
+
+#ifdef CONFIG_DEBUG_WW_MUTEX_SLOWPATH
+static int
+ww_mutex_deadlock_injection(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
+{
+ if (ctx->deadlock_inject_countdown-- == 0) {
+ tmp = ctx->deadlock_inject_interval;
+ if (tmp > UINT_MAX/4)
+ tmp = UINT_MAX;
+ else
+ tmp = tmp*2 + tmp + tmp/2;
+
+ ctx->deadlock_inject_interval = tmp;
+ ctx->deadlock_inject_countdown = tmp;
+
+ ww_mutex_unlock(lock);
+
+ return -EDEADLK;
+ }
+
+ return 0;
+}
+#else
+static inline int
+ww_mutex_deadlock_injection(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
+{
+ return 0;
+}
+#endif
+
int __sched
ww_mutex_lock(struct ww_mutex *lock, struct ww_acquire_ctx *ctx)
{
@@ -839,6 +869,7 @@ ww_mutex_lock(struct ww_mutex *lock, struct ww_acquire_ctx
*ctx)
if (likely(!ret)) {
ww_mutex_set_context_fastpath(lock, ctx);
mutex_set_owner(&lock->base);
+ return ww_mutex_deadlock_injection(lock, ctx);
} else
ret = __ww_mutex_lock_slowpath(lock, ctx);
return ret;
@@ -857,6 +888,7 @@ ww_mutex_lock_interruptible(struct ww_mutex *lock, struct
ww_acquire_ctx *ctx)
if (likely(!ret)) {
ww_mutex_set_context_fastpath(lock, ctx);
mutex_set_owner(&lock->base);
+ return ww_mutex_deadlock_injection(lock, ctx);
} else
ret = __ww_mutex_lock_interruptible_slowpath(lock, ctx);
return ret;
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 28be08c..8c41f73 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -547,6 +547,16 @@ config DEBUG_MUTEXES
This feature allows mutex semantics violations to be detected and
reported.
+config DEBUG_WW_MUTEX_SLOWPATH
+
abuse of dumb ioctls in exynos
On Tue, Apr 30, 2013 at 10:19 PM, Dave Airlie wrote: >>> Except in the cases where it doesn't do what you want, and possibly in >>> the future where it does less of what you want. You've started on a >>> slippery slope, and I'm stopping you before you make things worse. >>> >>> You are going to have to get SoC kernel drivers to add an ioctl that >>> you can use, if you insist on trying to mangle all the different code >>> paths into a single userspace driver, then you are going to take a lot >>> of pain. Its the old helper library vs midlayer, you are inventing a >>> DDX midlayer when you should be inventing a DDX helper library. >> >> No argue there, but it would make sense to have a common set of ioctls for >> buffer management. The dumb buffer interface is for generic userspace but for >> non-generic cases there is still a need for something to prevent code >> duplication for the SoC people. > > No it means SoC people need to duplicate more code in userspace. > > Adding restrictive interfaces to do dumb buffer allocation is never > going to end well, > someone will always come up with a new buffer type that is slightly > different than > the previous ones you came up with for their special SoC. The old TTM > APIs we had > tried to do this generically, and it was too messy. I'm not sure if I > can say this plainer: > THIS IS NOT A GOOD IDEA AND I WON'T MERGE IT. I certainly don't have the big picture of this and I trust you in your decision. My idea was not to have a restrictive interface but to have something thin for the most common parts and allow it to be extended for every use case. But if it didn't work before there is little point in doing the same mistake again. And ofc there is no such thing as a non restrictive generic interface. > You also defeated any hope of me taking you seriously when you suggested > adding > generic accel interfaces for 2D, because acceleration doesn't belong > in the kernel, > Lets get this straight, drm isn't fbdev, it isn't an unmaintained free > for all fastest hack > wins. If I catch this sort of bullshit happening in drm drivers I'll > be pulling maintainer > plugs out. Don't worry, there are no such patches coming your way. Thanks Patrik
[Bug 60553] [trine2] wrong colors when executed fullscreen
https://bugs.freedesktop.org/show_bug.cgi?id=60553 Laurent carlier changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Laurent carlier --- It seem now fixed with: 3.1 (Core Profile) Mesa 9.2.0 (git-c4bea00) So, closing -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130430/8e01289e/attachment.html>
[Bug 64096] New: LLVM RV790 etqw regression since R600: Packetize instructions
https://bugs.freedesktop.org/show_bug.cgi?id=64096 Priority: medium Bug ID: 64096 Assignee: dri-devel at lists.freedesktop.org Summary: LLVM RV790 etqw regression since R600: Packetize instructions Severity: normal Classification: Unclassified OS: All Reporter: adf.lists at gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa rv790 with etqw getting a green tint in levels on current llvm/mesa heads. llvm bisected to below, while actually sitting on that there are more corruptions than just the tint. commit 25f259cde28860ea76c2f5628010968945a28edb Author: Vincent Lejeune Date: Tue Apr 30 00:14:27 2013 + R600: Packetize instructions git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 180760 91177308-0d34-0410-b5e6-96231b3b80d8 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130430/f9a6d23d/attachment.html>
[Bug 64096] LLVM RV790 etqw regression since R600: Packetize instructions
https://bugs.freedesktop.org/show_bug.cgi?id=64096 --- Comment #1 from Andy Furniss --- Testing further some of the mesa demos are also wrong - not that I have re- bisected, just assume same issue, on heads - gloss = blank. gears, fbo_firecube, gearbox = too dark. shadowtex = shadow misaligned -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130430/bb8363a6/attachment.html>
