Re: [drm-intel-nightly] 2016y-07m-14d-21h-13m-02s UTC: locking dependency: drm_modeset_lock_all() || __blocking_notifier_call_chain

4 messages, 3 authors, 2016-08-17 · open the first message on its own page

Re: [drm-intel-nightly] 2016y-07m-14d-21h-13m-02s UTC: locking dependency: drm_modeset_lock_all() || __blocking_notifier_call_chain

From: Chris Wilson <hidden>
Date: 2016-07-15 08:40:57

On Fri, Jul 15, 2016 at 08:00:25AM +0200, Sedat Dilek wrote:
Hi,

I see the below call-trace with latest d-i-n, guess latest linux-next
will cause same issues.
( Beyond this, there exist also a build failure which me and Stephen
have reported. )
The call-trace is reproducible with my setup and seen on every boot.

Not sure if this is a problem in intel-gfx or fbdev.
Personally, I blamed backlight,
https://patchwork.freedesktop.org/patch/95769/
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [drm-intel-nightly] 2016y-07m-14d-21h-13m-02s UTC: locking dependency: drm_modeset_lock_all() || __blocking_notifier_call_chain

From: Sedat Dilek <hidden>
Date: 2016-07-15 10:37:59

On Fri, Jul 15, 2016 at 10:40 AM, Chris Wilson [off-list ref] wrote:
On Fri, Jul 15, 2016 at 08:00:25AM +0200, Sedat Dilek wrote:
quoted
Hi,

I see the below call-trace with latest d-i-n, guess latest linux-next
will cause same issues.
( Beyond this, there exist also a build failure which me and Stephen
have reported. )
The call-trace is reproducible with my setup and seen on every boot.

Not sure if this is a problem in intel-gfx or fbdev.
Personally, I blamed backlight,
https://patchwork.freedesktop.org/patch/95769/
Thanks, I try the patch when I am at home in front of my machine.

- sed@ -

Re: [drm-intel-nightly] 2016y-07m-14d-21h-13m-02s UTC: locking dependency: drm_modeset_lock_all() || __blocking_notifier_call_chain

From: Sedat Dilek <hidden>
Date: 2016-08-17 19:27:02

On Fri, Jul 15, 2016 at 10:40 AM, Chris Wilson [off-list ref] wrote:
On Fri, Jul 15, 2016 at 08:00:25AM +0200, Sedat Dilek wrote:
quoted
Hi,

I see the below call-trace with latest d-i-n, guess latest linux-next
will cause same issues.
( Beyond this, there exist also a build failure which me and Stephen
have reported. )
The call-trace is reproducible with my setup and seen on every boot.

Not sure if this is a problem in intel-gfx or fbdev.
Personally, I blamed backlight,
https://patchwork.freedesktop.org/patch/95769/
[ CC Peter, Johannes and Thorsten "The regression reporter" ]

Peter has 2 fixes from Johannes in peterz/queue.git#locking/urgent
which fix the issue for me.

[1/2] Revert "drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference"
[2/2] locking/barriers: suppress sparse warnings in lockless_dereference()

I tried today's Linus tree with those two fixes.

Chris backlight fix is no more needed here.

- Sedat -

[1] http://git.kernel.org/cgit/linux/kernel/git/peterz/queue.git/commit/?h=locking/urgent&idùd089b7830bbaa6ccaad29dff5fbb01d2a69945
[2] http://git.kernel.org/cgit/linux/kernel/git/peterz/queue.git/commit/?h=locking/urgent&id04f7121995e8ca341427d848c0c8d267147720

Re: [drm-intel-nightly] 2016y-07m-14d-21h-13m-02s UTC: locking dependency: drm_modeset_lock_all() || __blocking_notifier_call_chain

From: Johannes Berg <johannes@sipsolutions.net>
Date: 2016-08-17 19:36:51

On Wed, 2016-08-17 at 19:27 +0000, Sedat Dilek wrote:
 
quoted
quoted
The call-trace is reproducible with my setup and seen on every
boot.
Might have been nice to keep the backtrace when adding new people :)

I found it here:
https://lists.freedesktop.org/archives/intel-gfx/2016-July/100695.html
[ CC Peter, Johannes and Thorsten "The regression reporter" ]

Peter has 2 fixes from Johannes in peterz/queue.git#locking/urgent
which fix the issue for me.

[1/2] Revert "drm/fb-helper: Reduce READ_ONCE(master) to
lockless_dereference"
[2/2] locking/barriers: suppress sparse warnings in
lockless_dereference()
I don't see how those could fix it. The second one is a pure compile-
time issue, so it's completely irrelevant - it should not change code
generation in any way.

The first one, reverting to READ_ONCE(), does change the code a bit,
but since lockless_dereference() has no lockdep involvement, I don't
see how that could have any impact on a lockdep report.

Judging from the lockdep report, you have a pretty simple ABBA deadlock
there, but I really don't see how the changes could have any impact.

johannes
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help