Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1453567 > unrolled thread

Re: [git pull] drm for v4.8

Started byLinus Torvalds <torvalds@linux-foundation.org>
First post2016-08-02 05:30 +0200
Last post2016-08-02 14:30 +0200
Articles 12 — 5 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [git pull] drm for v4.8 Linus Torvalds <torvalds@linux-foundation.org> - 2016-08-02 05:30 +0200
    Re: [git pull] drm for v4.8 Ville Syrjälä <ville.syrjala@linux.intel.com> - 2016-08-02 10:20 +0200
      Re: [git pull] drm for v4.8 Jani Nikula <jani.nikula@linux.intel.com> - 2016-08-02 17:50 +0200
      Re: [git pull] drm for v4.8 Linus Torvalds <torvalds@linux-foundation.org> - 2016-08-02 18:50 +0200
        Re: [git pull] drm for v4.8 Ville Syrjälä <ville.syrjala@linux.intel.com> - 2016-08-02 20:40 +0200
        Re: [git pull] drm for v4.8 Daniel Vetter <daniel@ffwll.ch> - 2016-08-02 21:20 +0200
      Re: [git pull] drm for v4.8 Linus Torvalds <torvalds@linux-foundation.org> - 2016-08-02 20:20 +0200
    Re: [git pull] drm for v4.8 Daniel Vetter <daniel@ffwll.ch> - 2016-08-02 11:50 +0200
    Re: [git pull] drm for v4.8 Jiri Kosina <jikos@kernel.org> - 2016-08-02 14:10 +0200
      Re: [git pull] drm for v4.8 Jani Nikula <jani.nikula@linux.intel.com> - 2016-08-02 14:30 +0200
        Re: [git pull] drm for v4.8 Jiri Kosina <jikos@kernel.org> - 2016-08-02 16:10 +0200
      Re: [git pull] drm for v4.8 Jiri Kosina <jikos@kernel.org> - 2016-08-02 14:30 +0200

#1453567 — Re: [git pull] drm for v4.8

FromLinus Torvalds <torvalds@linux-foundation.org>
Date2016-08-02 05:30 +0200
SubjectRe: [git pull] drm for v4.8
Message-ID<s1yyZ-7cW-1@gated-at.bofh.it>
On Mon, Aug 1, 2016 at 9:32 PM, Dave Airlie <airlied@linux.ie> wrote:
>
> This is the main drm pull request for 4.8, I'm down with a cold at the moment
> so hopefully this isn't in too bad a state, I finished pulling stuff last
> week mostly (nouveau fixes just went in today), so only this message should
> be influenced by illness. Apologies to anyone who's major feature I missed :-)
>
> i915:
>         BXT support enabled by default
>         GVT-g infrastructure
>         GuC command submission and fixes
>         BXT workarounds
>         SKL/BKL workarounds
>         Demidlayering device registration
>         Thundering herd fixes
>         Missing pci ids
>         Atomic updates

Hmm. I did the merge and pushed it out, but testing it on my laptop
shows some very annoying flickering problem.

The screen goes dark for a very short while (one frame? Who knows?
Seems longer occasionally). I have no idea what triggers it, but it
happens quite a lot when it happens. Like once every second or two.
And it seems to happen most of the time, although right now it happens
to be behaving nicely, so sometimes it goes for a while without the
flickering.

Things *work*, but the flickering is nasty enough to make the end
result painful to use.

The only thing I see in dmesg that looks bad is

   [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR*
uncleared fifo underrun on pipe A
   [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A
FIFO underrun

but I've seen that before, and it happens a couple of times during
boot. Not once per second.

This is my old Vaio 11 Pro, now running Fedora 24 (up-to-date as of today).

So it's bog-standard intel graphics (i5-4200U - Haswell ULT).

Suggestions to try?

             Linus

[toc] | [next] | [standalone]

#1453660

FromVille Syrjälä <ville.syrjala@linux.intel.com>
Date2016-08-02 10:20 +0200
Message-ID<s1D5E-1T7-9@gated-at.bofh.it>
In reply to#1453567
On Tue, Aug 02, 2016 at 10:00:12AM +0200, Daniel Vetter wrote:
> On Tue, Aug 2, 2016 at 4:26 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > On Mon, Aug 1, 2016 at 9:32 PM, Dave Airlie <airlied@linux.ie> wrote:
> >>
> >> This is the main drm pull request for 4.8, I'm down with a cold at the moment
> >> so hopefully this isn't in too bad a state, I finished pulling stuff last
> >> week mostly (nouveau fixes just went in today), so only this message should
> >> be influenced by illness. Apologies to anyone who's major feature I missed :-)
> >>
> >> i915:
> >>         BXT support enabled by default
> >>         GVT-g infrastructure
> >>         GuC command submission and fixes
> >>         BXT workarounds
> >>         SKL/BKL workarounds
> >>         Demidlayering device registration
> >>         Thundering herd fixes
> >>         Missing pci ids
> >>         Atomic updates
> >
> > Hmm. I did the merge and pushed it out, but testing it on my laptop
> > shows some very annoying flickering problem.
> >
> > The screen goes dark for a very short while (one frame? Who knows?
> > Seems longer occasionally). I have no idea what triggers it, but it
> > happens quite a lot when it happens. Like once every second or two.
> > And it seems to happen most of the time, although right now it happens
> > to be behaving nicely, so sometimes it goes for a while without the
> > flickering.
> >
> > Things *work*, but the flickering is nasty enough to make the end
> > result painful to use.
> >
> > The only thing I see in dmesg that looks bad is
> >
> >    [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR*
> > uncleared fifo underrun on pipe A
> >    [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A
> > FIFO underrun
> >
> > but I've seen that before, and it happens a couple of times during
> > boot. Not once per second.
> >
> > This is my old Vaio 11 Pro, now running Fedora 24 (up-to-date as of today).
> >
> > So it's bog-standard intel graphics (i5-4200U - Haswell ULT).
> >
> > Suggestions to try?
> 
> psr or fbc are the likely culprits. More likely fbc if the underruns
> correlate with the flicker (but note that by default we only report
> them once per modest, needs to be reset with a dpms or
> suspend/resume). Driver should even pick up the new module option
> settings at runtime (but again you need to force a modeset, just
> suspend/resume quickly), so fast to test.

I think FBC is still disabled by default on HSW.

So PSR seems more likely. The underruns might point at some watermark
fail though :(

I have a couple of pending PSR patches you may want to try as well,
if i915.enable_psr=0 helps.

First set is here:
git://github.com/vsyrjala/linux.git psr_setup_time_2
This should be perfectly safe to go in actually, as it will only result
in disabling PSR with certain panels.

The second set is here:
git://github.com/vsyrjala/linux.git psr_fixes_2
This one I think is causing some kind of slight regression on one
machine in our CI system. Still not sure what's going on there.

-- 
Ville Syrjälä
Intel OTC

[toc] | [prev] | [next] | [standalone]

#1454806

FromJani Nikula <jani.nikula@linux.intel.com>
Date2016-08-02 17:50 +0200
Message-ID<s1K78-6pf-5@gated-at.bofh.it>
In reply to#1453660
On Tue, 02 Aug 2016, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Tue, Aug 2, 2016 at 4:10 AM, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
>>
>> I have a couple of pending PSR patches you may want to try as well,
>> if i915.enable_psr=0 helps.
>
> Yes. i915.enable_psr=0 seems to make the bad flickering go away.
>
> I'll try your git trees out later, but what exactly changed with
> regards to psr lately? It's set as a "dangerous" option, and even just
> clearing it caused
>
>   Setting dangerous option enable_psr - tainting kernel
>
> which seems entirely bogus.

The warning comes from kernel/params.c for module_param_named_unsafe()
which has no way of knowing which values are safe, and complains if the
option is set at all.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

[toc] | [prev] | [next] | [standalone]

#1454995

FromLinus Torvalds <torvalds@linux-foundation.org>
Date2016-08-02 18:50 +0200
Message-ID<s1L3b-725-11@gated-at.bofh.it>
In reply to#1453660
On Tue, Aug 2, 2016 at 4:10 AM, Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> So PSR seems more likely. The underruns might point at some watermark
> fail though :(
>
> I have a couple of pending PSR patches you may want to try as well,
> if i915.enable_psr=0 helps.
>
> First set is here:
> git://github.com/vsyrjala/linux.git psr_setup_time_2
> This should be perfectly safe to go in actually, as it will only result
> in disabling PSR with certain panels.

This first git pull fixes it for me, as far as I can tell. I'm not
sure that the problem is 100% reproducible, but I booted into each
kernel twice, and the current git tree is broken, while with your
psr_setup_time_2 branch pulled it works.  So it does seem to be the
fix.

> The second set is here:
> git://github.com/vsyrjala/linux.git psr_fixes_2

I didn't even test that one.

Should I just pull that psr_setup_time2 branch for real? I'd like to
get a real pull request with explanations etc, but other than that it
looks good to go.

            Linus

[toc] | [prev] | [next] | [standalone]

#1455362

FromVille Syrjälä <ville.syrjala@linux.intel.com>
Date2016-08-02 20:40 +0200
Message-ID<s1MLE-8fV-41@gated-at.bofh.it>
In reply to#1454995
On Tue, Aug 02, 2016 at 08:01:14PM +0200, Daniel Vetter wrote:
> On Tue, Aug 2, 2016 at 6:40 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > On Tue, Aug 2, 2016 at 4:10 AM, Ville Syrjälä
> > <ville.syrjala@linux.intel.com> wrote:
> >>
> >> So PSR seems more likely. The underruns might point at some watermark
> >> fail though :(
> >>
> >> I have a couple of pending PSR patches you may want to try as well,
> >> if i915.enable_psr=0 helps.
> >>
> >> First set is here:
> >> git://github.com/vsyrjala/linux.git psr_setup_time_2
> >> This should be perfectly safe to go in actually, as it will only result
> >> in disabling PSR with certain panels.
> >
> > This first git pull fixes it for me, as far as I can tell. I'm not
> > sure that the problem is 100% reproducible, but I booted into each
> > kernel twice, and the current git tree is broken, while with your
> > psr_setup_time_2 branch pulled it works.  So it does seem to be the
> > fix.
> >
> >> The second set is here:
> >> git://github.com/vsyrjala/linux.git psr_fixes_2
> >
> > I didn't even test that one.
> >
> > Should I just pull that psr_setup_time2 branch for real? I'd like to
> > get a real pull request with explanations etc, but other than that it
> > looks good to go.
> 
> Hm, I reviewed all the patches from Ville already. I gues they were
> stuck because we didn't have someone who reported that it's fixed,
> plus they lacked an ack from Dave for the 2 core patches.

+ they were part of a series that included a rotten apple responsible
  for a BAT regression

> tbh I'd just
> apply them all to drm-intel-fixes and then send out a pull for that
> (there's two more bugfix patches on it which missed Dave's main pull
> by a notch). Dave/Jani?
> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 
Ville Syrjälä
Intel OTC

[toc] | [prev] | [next] | [standalone]

#1455419

FromDaniel Vetter <daniel@ffwll.ch>
Date2016-08-02 21:20 +0200
Message-ID<s1MLE-8fV-43@gated-at.bofh.it>
In reply to#1454995
On Tue, Aug 2, 2016 at 6:40 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, Aug 2, 2016 at 4:10 AM, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
>>
>> So PSR seems more likely. The underruns might point at some watermark
>> fail though :(
>>
>> I have a couple of pending PSR patches you may want to try as well,
>> if i915.enable_psr=0 helps.
>>
>> First set is here:
>> git://github.com/vsyrjala/linux.git psr_setup_time_2
>> This should be perfectly safe to go in actually, as it will only result
>> in disabling PSR with certain panels.
>
> This first git pull fixes it for me, as far as I can tell. I'm not
> sure that the problem is 100% reproducible, but I booted into each
> kernel twice, and the current git tree is broken, while with your
> psr_setup_time_2 branch pulled it works.  So it does seem to be the
> fix.
>
>> The second set is here:
>> git://github.com/vsyrjala/linux.git psr_fixes_2
>
> I didn't even test that one.
>
> Should I just pull that psr_setup_time2 branch for real? I'd like to
> get a real pull request with explanations etc, but other than that it
> looks good to go.

Hm, I reviewed all the patches from Ville already. I gues they were
stuck because we didn't have someone who reported that it's fixed,
plus they lacked an ack from Dave for the 2 core patches. tbh I'd just
apply them all to drm-intel-fixes and then send out a pull for that
(there's two more bugfix patches on it which missed Dave's main pull
by a notch). Dave/Jani?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[toc] | [prev] | [next] | [standalone]

#1455309

FromLinus Torvalds <torvalds@linux-foundation.org>
Date2016-08-02 20:20 +0200
Message-ID<s1K78-6pf-7@gated-at.bofh.it>
In reply to#1453660
On Tue, Aug 2, 2016 at 4:10 AM, Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> I have a couple of pending PSR patches you may want to try as well,
> if i915.enable_psr=0 helps.

Yes. i915.enable_psr=0 seems to make the bad flickering go away.

I'll try your git trees out later, but what exactly changed with
regards to psr lately? It's set as a "dangerous" option, and even just
clearing it caused

  Setting dangerous option enable_psr - tainting kernel

which seems entirely bogus.

              Linus

[toc] | [prev] | [next] | [standalone]

#1453710

FromDaniel Vetter <daniel@ffwll.ch>
Date2016-08-02 11:50 +0200
Message-ID<s1D5E-1T7-11@gated-at.bofh.it>
In reply to#1453567
On Tue, Aug 2, 2016 at 4:26 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, Aug 1, 2016 at 9:32 PM, Dave Airlie <airlied@linux.ie> wrote:
>>
>> This is the main drm pull request for 4.8, I'm down with a cold at the moment
>> so hopefully this isn't in too bad a state, I finished pulling stuff last
>> week mostly (nouveau fixes just went in today), so only this message should
>> be influenced by illness. Apologies to anyone who's major feature I missed :-)
>>
>> i915:
>>         BXT support enabled by default
>>         GVT-g infrastructure
>>         GuC command submission and fixes
>>         BXT workarounds
>>         SKL/BKL workarounds
>>         Demidlayering device registration
>>         Thundering herd fixes
>>         Missing pci ids
>>         Atomic updates
>
> Hmm. I did the merge and pushed it out, but testing it on my laptop
> shows some very annoying flickering problem.
>
> The screen goes dark for a very short while (one frame? Who knows?
> Seems longer occasionally). I have no idea what triggers it, but it
> happens quite a lot when it happens. Like once every second or two.
> And it seems to happen most of the time, although right now it happens
> to be behaving nicely, so sometimes it goes for a while without the
> flickering.
>
> Things *work*, but the flickering is nasty enough to make the end
> result painful to use.
>
> The only thing I see in dmesg that looks bad is
>
>    [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR*
> uncleared fifo underrun on pipe A
>    [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A
> FIFO underrun
>
> but I've seen that before, and it happens a couple of times during
> boot. Not once per second.
>
> This is my old Vaio 11 Pro, now running Fedora 24 (up-to-date as of today).
>
> So it's bog-standard intel graphics (i5-4200U - Haswell ULT).
>
> Suggestions to try?

psr or fbc are the likely culprits. More likely fbc if the underruns
correlate with the flicker (but note that by default we only report
them once per modest, needs to be reset with a dpms or
suspend/resume). Driver should even pick up the new module option
settings at runtime (but again you need to force a modeset, just
suspend/resume quickly), so fast to test.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[toc] | [prev] | [next] | [standalone]

#1453980

FromJiri Kosina <jikos@kernel.org>
Date2016-08-02 14:10 +0200
Message-ID<s1GGe-4fp-15@gated-at.bofh.it>
In reply to#1453567
On Mon, 1 Aug 2016, Linus Torvalds wrote:

> > This is the main drm pull request for 4.8, I'm down with a cold at the moment
> > so hopefully this isn't in too bad a state, I finished pulling stuff last
> > week mostly (nouveau fixes just went in today), so only this message should
> > be influenced by illness. Apologies to anyone who's major feature I missed :-)
> >
> > i915:
> >         BXT support enabled by default
> >         GVT-g infrastructure
> >         GuC command submission and fixes
> >         BXT workarounds
> >         SKL/BKL workarounds
> >         Demidlayering device registration
> >         Thundering herd fixes
> >         Missing pci ids
> >         Atomic updates
> 
> Hmm. I did the merge and pushed it out, but testing it on my laptop
> shows some very annoying flickering problem.

In addition to that, what I see with current git (HEAD == 731c7d3a205, 
i.e. the drm merge) is lockdep report during bootup about AB-BA between 
mode_config.mutex and fb_notifier_list rwsem; will probably not have time 
to look into it more (look at the code and / or bisect) until tomorrow, so 
sending out early as a heads-up.

Also, trying to suspend the machine to disk hangs, with the "suspend" LED 
constantly blinking, LCD being blank, but the machine never actually 
powering off. Not sure whether it might not be the very deadlock actually 
triggering for real.


[    8.731638] fbcon: inteldrmfb (fb0) is primary device

[    8.732611] ======================================================
[    8.732612] [ INFO: possible circular locking dependency detected ]
[    8.732614] 4.7.0-10753-g731c7d3 #459 Not tainted
[    8.732614] -------------------------------------------------------
[    8.732615] kworker/u8:3/60 is trying to acquire lock:
[    8.732650]  (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffc02bfd00>] drm_modeset_lock_all+0x40/0x120 [drm]
[    8.732651] 
but task is already holding lock:
[    8.732657]  ((fb_notifier_list).rwsem){++++.+}, at: [<ffffffff8d08fe2a>] __blocking_notifier_call_chain+0x3a/0x70
[    8.732658] 
which lock already depends on the new lock.

[    8.732658] 
the existing dependency chain (in reverse order) is:
[    8.732661] 
-> #1 ((fb_notifier_list).rwsem){++++.+}:
[    8.732665]        [<ffffffff8d0c22d0>] lock_acquire+0xb0/0x1e0
[    8.732669]        [<ffffffff8d6a0b25>] down_write+0x55/0xc0
[    8.732671]        [<ffffffff8d08ffb1>] blocking_notifier_chain_register+0x21/0xb0
[    8.732674]        [<ffffffff8d3d1318>] fb_register_client+0x18/0x20
[    8.732676]        [<ffffffff8d3d0b88>] backlight_device_register+0x138/0x250
[    8.732746]        [<ffffffffc0568912>] intel_backlight_device_register+0xa2/0x160 [i915]
[    8.732791]        [<ffffffffc053735e>] intel_connector_register+0xe/0x10 [i915]
[    8.732809]        [<ffffffffc02ae389>] drm_connector_register+0x49/0x80 [drm]
[    8.732827]        [<ffffffffc02b28a0>] drm_modeset_register_all+0x1d0/0x260 [drm]
[    8.732843]        [<ffffffffc02a9c22>] drm_dev_register+0xc2/0xd0 [drm]
[    8.732878]        [<ffffffffc04a6ce5>] i915_driver_load+0x745/0x13e0 [i915]
[    8.732914]        [<ffffffffc04b173f>] i915_pci_probe+0x4f/0x70 [i915]
[    8.732917]        [<ffffffff8d3af7d5>] local_pci_probe+0x45/0xa0
[    8.732920]        [<ffffffff8d3b0bf1>] pci_device_probe+0xe1/0x130
[    8.732923]        [<ffffffff8d489be8>] driver_probe_device+0x1a8/0x460
[    8.732925]        [<ffffffff8d489f6d>] __driver_attach+0xcd/0xf0
[    8.732927]        [<ffffffff8d4878a4>] bus_for_each_dev+0x64/0xa0
[    8.732929]        [<ffffffff8d4894ee>] driver_attach+0x1e/0x20
[    8.732931]        [<ffffffff8d488f83>] bus_add_driver+0x1d3/0x290
[    8.732933]        [<ffffffff8d48ad30>] driver_register+0x60/0xe0
[    8.732935]        [<ffffffff8d3af100>] __pci_register_driver+0x60/0x70
[    8.732972]        [<ffffffffc05ec05d>] i915_init+0x5d/0x64 [i915]
[    8.732975]        [<ffffffff8d00041d>] do_one_initcall+0x3d/0x160
[    8.732979]        [<ffffffff8d182bfd>] do_init_module+0x60/0x1dc
[    8.732982]        [<ffffffff8d107a5e>] load_module+0x142e/0x1bf0
[    8.732984]        [<ffffffff8d108449>] SYSC_finit_module+0xa9/0xd0
[    8.732986]        [<ffffffff8d10848e>] SyS_finit_module+0xe/0x10
[    8.732989]        [<ffffffff8d6a38e9>] entry_SYSCALL_64_fastpath+0x1c/0xac
[    8.732992] 
-> #0 (&dev->mode_config.mutex){+.+.+.}:
[    8.732995]        [<ffffffff8d0c1e7c>] __lock_acquire+0x16cc/0x1700
[    8.732997]        [<ffffffff8d0c22d0>] lock_acquire+0xb0/0x1e0
[    8.732999]        [<ffffffff8d69f2d1>] mutex_lock_nested+0x71/0x390
[    8.733019]        [<ffffffffc02bfd00>] drm_modeset_lock_all+0x40/0x120 [drm]
[    8.733034]        [<ffffffffc047640b>] drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80 [drm_kms_helper]
[    8.733043]        [<ffffffffc047648c>] drm_fb_helper_set_par+0x2c/0x50 [drm_kms_helper]
[    8.733088]        [<ffffffffc05476aa>] intel_fbdev_set_par+0x1a/0x60 [i915]
[    8.733091]        [<ffffffff8d3ce2b8>] fbcon_init+0x4d8/0x550
[    8.733094]        [<ffffffff8d450526>] visual_init+0xd6/0x130
[    8.733097]        [<ffffffff8d452ab6>] do_bind_con_driver+0x146/0x310
[    8.733099]        [<ffffffff8d452f66>] do_take_over_console+0x106/0x180
[    8.733101]        [<ffffffff8d3c9777>] do_fbcon_takeover+0x57/0xb0
[    8.733104]        [<ffffffff8d3cedd6>] fbcon_event_notify+0x726/0x870
[    8.733106]        [<ffffffff8d08fbfe>] notifier_call_chain+0x4e/0xa0
[    8.733109]        [<ffffffff8d08fe43>] __blocking_notifier_call_chain+0x53/0x70
[    8.733111]        [<ffffffff8d08fe76>] blocking_notifier_call_chain+0x16/0x20
[    8.733113]        [<ffffffff8d3d135b>] fb_notifier_call_chain+0x1b/0x20
[    8.733116]        [<ffffffff8d3d3379>] register_framebuffer+0x239/0x320
[    8.733126]        [<ffffffffc047670a>] drm_fb_helper_initial_config+0x25a/0x3a3 [drm_kms_helper]
[    8.733169]        [<ffffffffc0548938>] intel_fbdev_initial_config+0x18/0x30 [i915]
[    8.733172]        [<ffffffff8d091aaa>] async_run_entry_fn+0x4a/0x140
[    8.733174]        [<ffffffff8d08771e>] process_one_work+0x1de/0x670
[    8.733176]        [<ffffffff8d087cd5>] worker_thread+0x125/0x4a0
[    8.733178]        [<ffffffff8d08e7e2>] kthread+0xf2/0x110
[    8.733181]        [<ffffffff8d6a3b2f>] ret_from_fork+0x1f/0x40
[    8.733181] 
other info that might help us debug this:

[    8.733182]  Possible unsafe locking scenario:

[    8.733183]        CPU0                    CPU1
[    8.733183]        ----                    ----
[    8.733185]   lock((fb_notifier_list).rwsem);
[    8.733186]                                lock(&dev->mode_config.mutex);
[    8.733187]                                lock((fb_notifier_list).rwsem);
[    8.733188]   lock(&dev->mode_config.mutex);
[    8.733189] 
 *** DEADLOCK ***

[    8.733190] 6 locks held by kworker/u8:3/60:
[    8.733194]  #0:  ("events_unbound"){.+.+.+}, at: [<ffffffff8d08769f>] process_one_work+0x15f/0x670
[    8.733198]  #1:  ((&entry->work)){+.+.+.}, at: [<ffffffff8d08769f>] process_one_work+0x15f/0x670
[    8.733201]  #2:  (registration_lock){+.+.+.}, at: [<ffffffff8d3d3167>] register_framebuffer+0x27/0x320
[    8.733205]  #3:  (console_lock){+.+.+.}, at: [<ffffffff8d3d3396>] register_framebuffer+0x256/0x320
[    8.733208]  #4:  (&fb_info->lock){+.+.+.}, at: [<ffffffff8d3d178d>] lock_fb_info+0x1d/0x40
[    8.733212]  #5:  ((fb_notifier_list).rwsem){++++.+}, at: [<ffffffff8d08fe2a>] __blocking_notifier_call_chain+0x3a/0x70
[    8.733212] 
stack backtrace:
[    8.733214] CPU: 1 PID: 60 Comm: kworker/u8:3 Not tainted 4.7.0-10753-g731c7d3 #459
[    8.733215] Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008
[    8.733218] Workqueue: events_unbound async_run_entry_fn
[    8.733221]  0000000000000000 ffff95f0b77537d8 ffffffff8d36c09e ffffffff8e822d00
[    8.733224]  ffffffff8e822d00 ffff95f0b7753818 ffffffff8d18205b ffff95f0b7753850
[    8.733226]  ffff95f0b774d718 0000000000000005 0000000000000006 ffff95f0b774cd40
[    8.733227] Call Trace:
[    8.733230]  [<ffffffff8d36c09e>] dump_stack+0x67/0x99
[    8.733232]  [<ffffffff8d18205b>] print_circular_bug+0x200/0x20e
[    8.733235]  [<ffffffff8d0c1e7c>] __lock_acquire+0x16cc/0x1700
[    8.733238]  [<ffffffff8d0a17c8>] ? sched_clock_local+0x18/0x80
[    8.733240]  [<ffffffff8d0c22d0>] lock_acquire+0xb0/0x1e0
[    8.733260]  [<ffffffffc02bfd00>] ? drm_modeset_lock_all+0x40/0x120 [drm]
[    8.733262]  [<ffffffff8d69f2d1>] mutex_lock_nested+0x71/0x390
[    8.733281]  [<ffffffffc02bfd00>] ? drm_modeset_lock_all+0x40/0x120 [drm]
[    8.733301]  [<ffffffffc02bfd00>] ? drm_modeset_lock_all+0x40/0x120 [drm]
[    8.733304]  [<ffffffff8d1ec87c>] ? kmem_cache_alloc_trace+0x25c/0x320
[    8.733322]  [<ffffffffc02bfce5>] ? drm_modeset_lock_all+0x25/0x120 [drm]
[    8.733341]  [<ffffffffc02bfd00>] drm_modeset_lock_all+0x40/0x120 [drm]
[    8.733351]  [<ffffffffc047640b>] drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80 [drm_kms_helper]
[    8.733360]  [<ffffffffc047648c>] drm_fb_helper_set_par+0x2c/0x50 [drm_kms_helper]
[    8.733403]  [<ffffffffc05476aa>] intel_fbdev_set_par+0x1a/0x60 [i915]
[    8.733406]  [<ffffffff8d3ce2b8>] fbcon_init+0x4d8/0x550
[    8.733408]  [<ffffffff8d450526>] visual_init+0xd6/0x130
[    8.733410]  [<ffffffff8d452ab6>] do_bind_con_driver+0x146/0x310
[    8.733413]  [<ffffffff8d452f66>] do_take_over_console+0x106/0x180
[    8.733415]  [<ffffffff8d3c9777>] do_fbcon_takeover+0x57/0xb0
[    8.733417]  [<ffffffff8d3cedd6>] fbcon_event_notify+0x726/0x870
[    8.733419]  [<ffffffff8d08fbfe>] notifier_call_chain+0x4e/0xa0
[    8.733422]  [<ffffffff8d08fe43>] __blocking_notifier_call_chain+0x53/0x70
[    8.733424]  [<ffffffff8d08fe76>] blocking_notifier_call_chain+0x16/0x20
[    8.733426]  [<ffffffff8d3d135b>] fb_notifier_call_chain+0x1b/0x20
[    8.733427]  [<ffffffff8d3d3379>] register_framebuffer+0x239/0x320
[    8.733430]  [<ffffffff8d4817c0>] ? vga_switcheroo_client_fb_set+0x60/0x70
[    8.733440]  [<ffffffffc047670a>] drm_fb_helper_initial_config+0x25a/0x3a3 [drm_kms_helper]
[    8.733483]  [<ffffffffc0548938>] intel_fbdev_initial_config+0x18/0x30 [i915]
[    8.733484]  [<ffffffff8d091aaa>] async_run_entry_fn+0x4a/0x140
[    8.733486]  [<ffffffff8d08771e>] process_one_work+0x1de/0x670
[    8.733488]  [<ffffffff8d08769f>] ? process_one_work+0x15f/0x670
[    8.733490]  [<ffffffff8d087cd5>] worker_thread+0x125/0x4a0
[    8.733492]  [<ffffffff8d087bb0>] ? process_one_work+0x670/0x670
[    8.733494]  [<ffffffff8d08e7e2>] kthread+0xf2/0x110
[    8.733497]  [<ffffffff8d6a3b2f>] ret_from_fork+0x1f/0x40
[    8.733499]  [<ffffffff8d08e6f0>] ? kthread_create_on_node+0x220/0x220

-- 
Jiri Kosina
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1454067

FromJani Nikula <jani.nikula@linux.intel.com>
Date2016-08-02 14:30 +0200
Message-ID<s1GZA-4ne-19@gated-at.bofh.it>
In reply to#1453980
On Tue, 02 Aug 2016, Jiri Kosina <jikos@kernel.org> wrote:
> On Mon, 1 Aug 2016, Linus Torvalds wrote:
>
>> > This is the main drm pull request for 4.8, I'm down with a cold at the moment
>> > so hopefully this isn't in too bad a state, I finished pulling stuff last
>> > week mostly (nouveau fixes just went in today), so only this message should
>> > be influenced by illness. Apologies to anyone who's major feature I missed :-)
>> >
>> > i915:
>> >         BXT support enabled by default
>> >         GVT-g infrastructure
>> >         GuC command submission and fixes
>> >         BXT workarounds
>> >         SKL/BKL workarounds
>> >         Demidlayering device registration
>> >         Thundering herd fixes
>> >         Missing pci ids
>> >         Atomic updates
>> 
>> Hmm. I did the merge and pushed it out, but testing it on my laptop
>> shows some very annoying flickering problem.
>
> In addition to that, what I see with current git (HEAD == 731c7d3a205, 
> i.e. the drm merge) is lockdep report during bootup about AB-BA between 
> mode_config.mutex and fb_notifier_list rwsem; will probably not have time 
> to look into it more (look at the code and / or bisect) until tomorrow, so 
> sending out early as a heads-up.
>
> Also, trying to suspend the machine to disk hangs, with the "suspend" LED 
> constantly blinking, LCD being blank, but the machine never actually 
> powering off. Not sure whether it might not be the very deadlock actually 
> triggering for real.

There was [1] before my vacation to fix this, but it doesn't seem to
have gone anywhere since. And it doesn't refer what caused the lockdep
splat to begin with.

BR,
Jani.

[1] http://patchwork.freedesktop.org/patch/msgid/1467286256-8870-1-git-send-email-chris@chris-wilson.co.uk

>
>
> [    8.731638] fbcon: inteldrmfb (fb0) is primary device
>
> [    8.732611] ======================================================
> [    8.732612] [ INFO: possible circular locking dependency detected ]
> [    8.732614] 4.7.0-10753-g731c7d3 #459 Not tainted
> [    8.732614] -------------------------------------------------------
> [    8.732615] kworker/u8:3/60 is trying to acquire lock:
> [    8.732650]  (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffc02bfd00>] drm_modeset_lock_all+0x40/0x120 [drm]
> [    8.732651] 
> but task is already holding lock:
> [    8.732657]  ((fb_notifier_list).rwsem){++++.+}, at: [<ffffffff8d08fe2a>] __blocking_notifier_call_chain+0x3a/0x70
> [    8.732658] 
> which lock already depends on the new lock.
>
> [    8.732658] 
> the existing dependency chain (in reverse order) is:
> [    8.732661] 
> -> #1 ((fb_notifier_list).rwsem){++++.+}:
> [    8.732665]        [<ffffffff8d0c22d0>] lock_acquire+0xb0/0x1e0
> [    8.732669]        [<ffffffff8d6a0b25>] down_write+0x55/0xc0
> [    8.732671]        [<ffffffff8d08ffb1>] blocking_notifier_chain_register+0x21/0xb0
> [    8.732674]        [<ffffffff8d3d1318>] fb_register_client+0x18/0x20
> [    8.732676]        [<ffffffff8d3d0b88>] backlight_device_register+0x138/0x250
> [    8.732746]        [<ffffffffc0568912>] intel_backlight_device_register+0xa2/0x160 [i915]
> [    8.732791]        [<ffffffffc053735e>] intel_connector_register+0xe/0x10 [i915]
> [    8.732809]        [<ffffffffc02ae389>] drm_connector_register+0x49/0x80 [drm]
> [    8.732827]        [<ffffffffc02b28a0>] drm_modeset_register_all+0x1d0/0x260 [drm]
> [    8.732843]        [<ffffffffc02a9c22>] drm_dev_register+0xc2/0xd0 [drm]
> [    8.732878]        [<ffffffffc04a6ce5>] i915_driver_load+0x745/0x13e0 [i915]
> [    8.732914]        [<ffffffffc04b173f>] i915_pci_probe+0x4f/0x70 [i915]
> [    8.732917]        [<ffffffff8d3af7d5>] local_pci_probe+0x45/0xa0
> [    8.732920]        [<ffffffff8d3b0bf1>] pci_device_probe+0xe1/0x130
> [    8.732923]        [<ffffffff8d489be8>] driver_probe_device+0x1a8/0x460
> [    8.732925]        [<ffffffff8d489f6d>] __driver_attach+0xcd/0xf0
> [    8.732927]        [<ffffffff8d4878a4>] bus_for_each_dev+0x64/0xa0
> [    8.732929]        [<ffffffff8d4894ee>] driver_attach+0x1e/0x20
> [    8.732931]        [<ffffffff8d488f83>] bus_add_driver+0x1d3/0x290
> [    8.732933]        [<ffffffff8d48ad30>] driver_register+0x60/0xe0
> [    8.732935]        [<ffffffff8d3af100>] __pci_register_driver+0x60/0x70
> [    8.732972]        [<ffffffffc05ec05d>] i915_init+0x5d/0x64 [i915]
> [    8.732975]        [<ffffffff8d00041d>] do_one_initcall+0x3d/0x160
> [    8.732979]        [<ffffffff8d182bfd>] do_init_module+0x60/0x1dc
> [    8.732982]        [<ffffffff8d107a5e>] load_module+0x142e/0x1bf0
> [    8.732984]        [<ffffffff8d108449>] SYSC_finit_module+0xa9/0xd0
> [    8.732986]        [<ffffffff8d10848e>] SyS_finit_module+0xe/0x10
> [    8.732989]        [<ffffffff8d6a38e9>] entry_SYSCALL_64_fastpath+0x1c/0xac
> [    8.732992] 
> -> #0 (&dev->mode_config.mutex){+.+.+.}:
> [    8.732995]        [<ffffffff8d0c1e7c>] __lock_acquire+0x16cc/0x1700
> [    8.732997]        [<ffffffff8d0c22d0>] lock_acquire+0xb0/0x1e0
> [    8.732999]        [<ffffffff8d69f2d1>] mutex_lock_nested+0x71/0x390
> [    8.733019]        [<ffffffffc02bfd00>] drm_modeset_lock_all+0x40/0x120 [drm]
> [    8.733034]        [<ffffffffc047640b>] drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80 [drm_kms_helper]
> [    8.733043]        [<ffffffffc047648c>] drm_fb_helper_set_par+0x2c/0x50 [drm_kms_helper]
> [    8.733088]        [<ffffffffc05476aa>] intel_fbdev_set_par+0x1a/0x60 [i915]
> [    8.733091]        [<ffffffff8d3ce2b8>] fbcon_init+0x4d8/0x550
> [    8.733094]        [<ffffffff8d450526>] visual_init+0xd6/0x130
> [    8.733097]        [<ffffffff8d452ab6>] do_bind_con_driver+0x146/0x310
> [    8.733099]        [<ffffffff8d452f66>] do_take_over_console+0x106/0x180
> [    8.733101]        [<ffffffff8d3c9777>] do_fbcon_takeover+0x57/0xb0
> [    8.733104]        [<ffffffff8d3cedd6>] fbcon_event_notify+0x726/0x870
> [    8.733106]        [<ffffffff8d08fbfe>] notifier_call_chain+0x4e/0xa0
> [    8.733109]        [<ffffffff8d08fe43>] __blocking_notifier_call_chain+0x53/0x70
> [    8.733111]        [<ffffffff8d08fe76>] blocking_notifier_call_chain+0x16/0x20
> [    8.733113]        [<ffffffff8d3d135b>] fb_notifier_call_chain+0x1b/0x20
> [    8.733116]        [<ffffffff8d3d3379>] register_framebuffer+0x239/0x320
> [    8.733126]        [<ffffffffc047670a>] drm_fb_helper_initial_config+0x25a/0x3a3 [drm_kms_helper]
> [    8.733169]        [<ffffffffc0548938>] intel_fbdev_initial_config+0x18/0x30 [i915]
> [    8.733172]        [<ffffffff8d091aaa>] async_run_entry_fn+0x4a/0x140
> [    8.733174]        [<ffffffff8d08771e>] process_one_work+0x1de/0x670
> [    8.733176]        [<ffffffff8d087cd5>] worker_thread+0x125/0x4a0
> [    8.733178]        [<ffffffff8d08e7e2>] kthread+0xf2/0x110
> [    8.733181]        [<ffffffff8d6a3b2f>] ret_from_fork+0x1f/0x40
> [    8.733181] 
> other info that might help us debug this:
>
> [    8.733182]  Possible unsafe locking scenario:
>
> [    8.733183]        CPU0                    CPU1
> [    8.733183]        ----                    ----
> [    8.733185]   lock((fb_notifier_list).rwsem);
> [    8.733186]                                lock(&dev->mode_config.mutex);
> [    8.733187]                                lock((fb_notifier_list).rwsem);
> [    8.733188]   lock(&dev->mode_config.mutex);
> [    8.733189] 
>  *** DEADLOCK ***
>
> [    8.733190] 6 locks held by kworker/u8:3/60:
> [    8.733194]  #0:  ("events_unbound"){.+.+.+}, at: [<ffffffff8d08769f>] process_one_work+0x15f/0x670
> [    8.733198]  #1:  ((&entry->work)){+.+.+.}, at: [<ffffffff8d08769f>] process_one_work+0x15f/0x670
> [    8.733201]  #2:  (registration_lock){+.+.+.}, at: [<ffffffff8d3d3167>] register_framebuffer+0x27/0x320
> [    8.733205]  #3:  (console_lock){+.+.+.}, at: [<ffffffff8d3d3396>] register_framebuffer+0x256/0x320
> [    8.733208]  #4:  (&fb_info->lock){+.+.+.}, at: [<ffffffff8d3d178d>] lock_fb_info+0x1d/0x40
> [    8.733212]  #5:  ((fb_notifier_list).rwsem){++++.+}, at: [<ffffffff8d08fe2a>] __blocking_notifier_call_chain+0x3a/0x70
> [    8.733212] 
> stack backtrace:
> [    8.733214] CPU: 1 PID: 60 Comm: kworker/u8:3 Not tainted 4.7.0-10753-g731c7d3 #459
> [    8.733215] Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008
> [    8.733218] Workqueue: events_unbound async_run_entry_fn
> [    8.733221]  0000000000000000 ffff95f0b77537d8 ffffffff8d36c09e ffffffff8e822d00
> [    8.733224]  ffffffff8e822d00 ffff95f0b7753818 ffffffff8d18205b ffff95f0b7753850
> [    8.733226]  ffff95f0b774d718 0000000000000005 0000000000000006 ffff95f0b774cd40
> [    8.733227] Call Trace:
> [    8.733230]  [<ffffffff8d36c09e>] dump_stack+0x67/0x99
> [    8.733232]  [<ffffffff8d18205b>] print_circular_bug+0x200/0x20e
> [    8.733235]  [<ffffffff8d0c1e7c>] __lock_acquire+0x16cc/0x1700
> [    8.733238]  [<ffffffff8d0a17c8>] ? sched_clock_local+0x18/0x80
> [    8.733240]  [<ffffffff8d0c22d0>] lock_acquire+0xb0/0x1e0
> [    8.733260]  [<ffffffffc02bfd00>] ? drm_modeset_lock_all+0x40/0x120 [drm]
> [    8.733262]  [<ffffffff8d69f2d1>] mutex_lock_nested+0x71/0x390
> [    8.733281]  [<ffffffffc02bfd00>] ? drm_modeset_lock_all+0x40/0x120 [drm]
> [    8.733301]  [<ffffffffc02bfd00>] ? drm_modeset_lock_all+0x40/0x120 [drm]
> [    8.733304]  [<ffffffff8d1ec87c>] ? kmem_cache_alloc_trace+0x25c/0x320
> [    8.733322]  [<ffffffffc02bfce5>] ? drm_modeset_lock_all+0x25/0x120 [drm]
> [    8.733341]  [<ffffffffc02bfd00>] drm_modeset_lock_all+0x40/0x120 [drm]
> [    8.733351]  [<ffffffffc047640b>] drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80 [drm_kms_helper]
> [    8.733360]  [<ffffffffc047648c>] drm_fb_helper_set_par+0x2c/0x50 [drm_kms_helper]
> [    8.733403]  [<ffffffffc05476aa>] intel_fbdev_set_par+0x1a/0x60 [i915]
> [    8.733406]  [<ffffffff8d3ce2b8>] fbcon_init+0x4d8/0x550
> [    8.733408]  [<ffffffff8d450526>] visual_init+0xd6/0x130
> [    8.733410]  [<ffffffff8d452ab6>] do_bind_con_driver+0x146/0x310
> [    8.733413]  [<ffffffff8d452f66>] do_take_over_console+0x106/0x180
> [    8.733415]  [<ffffffff8d3c9777>] do_fbcon_takeover+0x57/0xb0
> [    8.733417]  [<ffffffff8d3cedd6>] fbcon_event_notify+0x726/0x870
> [    8.733419]  [<ffffffff8d08fbfe>] notifier_call_chain+0x4e/0xa0
> [    8.733422]  [<ffffffff8d08fe43>] __blocking_notifier_call_chain+0x53/0x70
> [    8.733424]  [<ffffffff8d08fe76>] blocking_notifier_call_chain+0x16/0x20
> [    8.733426]  [<ffffffff8d3d135b>] fb_notifier_call_chain+0x1b/0x20
> [    8.733427]  [<ffffffff8d3d3379>] register_framebuffer+0x239/0x320
> [    8.733430]  [<ffffffff8d4817c0>] ? vga_switcheroo_client_fb_set+0x60/0x70
> [    8.733440]  [<ffffffffc047670a>] drm_fb_helper_initial_config+0x25a/0x3a3 [drm_kms_helper]
> [    8.733483]  [<ffffffffc0548938>] intel_fbdev_initial_config+0x18/0x30 [i915]
> [    8.733484]  [<ffffffff8d091aaa>] async_run_entry_fn+0x4a/0x140
> [    8.733486]  [<ffffffff8d08771e>] process_one_work+0x1de/0x670
> [    8.733488]  [<ffffffff8d08769f>] ? process_one_work+0x15f/0x670
> [    8.733490]  [<ffffffff8d087cd5>] worker_thread+0x125/0x4a0
> [    8.733492]  [<ffffffff8d087bb0>] ? process_one_work+0x670/0x670
> [    8.733494]  [<ffffffff8d08e7e2>] kthread+0xf2/0x110
> [    8.733497]  [<ffffffff8d6a3b2f>] ret_from_fork+0x1f/0x40
> [    8.733499]  [<ffffffff8d08e6f0>] ? kthread_create_on_node+0x220/0x220

-- 
Jani Nikula, Intel Open Source Technology Center

[toc] | [prev] | [next] | [standalone]

#1454488

FromJiri Kosina <jikos@kernel.org>
Date2016-08-02 16:10 +0200
Message-ID<s1Iym-5ut-35@gated-at.bofh.it>
In reply to#1454067
On Tue, 2 Aug 2016, Jani Nikula wrote:

> >> > This is the main drm pull request for 4.8, I'm down with a cold at the moment
> >> > so hopefully this isn't in too bad a state, I finished pulling stuff last
> >> > week mostly (nouveau fixes just went in today), so only this message should
> >> > be influenced by illness. Apologies to anyone who's major feature I missed :-)
> >> >
> >> > i915:
> >> >         BXT support enabled by default
> >> >         GVT-g infrastructure
> >> >         GuC command submission and fixes
> >> >         BXT workarounds
> >> >         SKL/BKL workarounds
> >> >         Demidlayering device registration
> >> >         Thundering herd fixes
> >> >         Missing pci ids
> >> >         Atomic updates
> >> 
> >> Hmm. I did the merge and pushed it out, but testing it on my laptop
> >> shows some very annoying flickering problem.
> >
> > In addition to that, what I see with current git (HEAD == 731c7d3a205, 
> > i.e. the drm merge) is lockdep report during bootup about AB-BA between 
> > mode_config.mutex and fb_notifier_list rwsem; will probably not have time 
> > to look into it more (look at the code and / or bisect) until tomorrow, so 
> > sending out early as a heads-up.
> >
> > Also, trying to suspend the machine to disk hangs, with the "suspend" LED 
> > constantly blinking, LCD being blank, but the machine never actually 
> > powering off. Not sure whether it might not be the very deadlock actually 
> > triggering for real.
> 
> There was [1] before my vacation to fix this, but it doesn't seem to
> have gone anywhere since. And it doesn't refer what caused the lockdep
> splat to begin with.

Confirmed, that patch fixes the lockdep splat, so for that part

	Tested-by: Jiri Kosina <jkosina@suse.cz>

-- 
Jiri Kosina
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1454084

FromJiri Kosina <jikos@kernel.org>
Date2016-08-02 14:30 +0200
Message-ID<s1GZB-4ne-79@gated-at.bofh.it>
In reply to#1453980
On Tue, 2 Aug 2016, Jiri Kosina wrote:

> In addition to that, what I see with current git (HEAD == 731c7d3a205, 
> i.e. the drm merge) is lockdep report during bootup about AB-BA between 
> mode_config.mutex and fb_notifier_list rwsem; will probably not have time 
> to look into it more (look at the code and / or bisect) until tomorrow, so 
> sending out early as a heads-up.
> 
> Also, trying to suspend the machine to disk hangs, with the "suspend" LED 
> constantly blinking, LCD being blank, but the machine never actually 
> powering off. Not sure whether it might not be the very deadlock actually 
> triggering for real.

Ok, I tried HEAD == 7a66ecf (per-drm merge kernel from yesterday), and it 
doesn't produce the AB-BA warning (so it's really introduced by the last 
merge), but still has the suspend issue, so those are two separate issues.

-- 
Jiri Kosina
SUSE Labs

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web