On Wed, Oct 22, 2014 at 11:53:49AM +0200, Jiri Kosina wrote:
> > The reason for CCing Ingo and Peter is that I can't make any sense of one
> > of the stacktraces lockdep is providing.
> >
> > Please have a look at the very first stacktrace in the dump, where lockdep
> > is trying to explain wher
On Thu, Oct 23, 2014 at 10:11:25AM +0200, Borislav Petkov wrote:
> On Wed, Oct 22, 2014 at 02:09:43PM -0700, Paul E. McKenney wrote:
> > > Yes, this works. FWIW, please feel free to add
> > >
> > > Reported-and-tested-by: Jiri Kosina
> > >
> > > once merging it.
> >
> > Done, and thank you f
On Wed, Oct 22, 2014 at 02:09:43PM -0700, Paul E. McKenney wrote:
> > Yes, this works. FWIW, please feel free to add
> >
> > Reported-and-tested-by: Jiri Kosina
> >
> > once merging it.
>
> Done, and thank you for both the bug report and the testing!
Works here too.
Tested-by: Borislav P
On Wed, Oct 22, 2014 at 10:57:25PM +0200, Jiri Kosina wrote:
> On Wed, 22 Oct 2014, Paul E. McKenney wrote:
>
> > rcu: More on deadlock between CPU hotplug and expedited grace periods
> >
> > Commit dd56af42bd82 (rcu: Eliminate deadlock between CPU hotplug and
> > expedited grace periods) was inc
On Wed, 22 Oct 2014, Paul E. McKenney wrote:
> rcu: More on deadlock between CPU hotplug and expedited grace periods
>
> Commit dd56af42bd82 (rcu: Eliminate deadlock between CPU hotplug and
> expedited grace periods) was incomplete. Although it did eliminate
> deadlocks involving synchronize_sch
On Wed, Oct 22, 2014 at 09:54:33AM -0700, Paul E. McKenney wrote:
> On Wed, Oct 22, 2014 at 07:38:37AM -0700, Paul E. McKenney wrote:
> > On Wed, Oct 22, 2014 at 11:53:49AM +0200, Jiri Kosina wrote:
> > > On Tue, 21 Oct 2014, Jiri Kosina wrote:
> > >
> > > > Hi,
> > > >
> > > > I am seeing the lo
On Wed, Oct 22, 2014 at 08:40:21PM +0200, Jiri Kosina wrote:
> Yes, it's 100% reliable for me.
FWIW, I see that same splat here too, after a suspend-to-disk run:
...
[60077.352314] PM: Hibernation mode set to 'shutdown'
[60077.467384] PM: Syncing filesystems ... done.
[60077.479538] Freezing user
On Wed, 22 Oct 2014, Steven Rostedt wrote:
> > > > -> #1 (cpu_hotplug.lock#2){+.+.+.}:
> > > > [] lock_acquire+0xac/0x130
> > > > [] mutex_lock_nested+0x5c/0x3b0
> > > > [] cpuidle_pause+0x12/0x30
> > > > [] dpm_suspend_noirq+0x44/0x340
> > > > [] dpm_suspen
On Tue, 21 Oct 2014 17:04:17 +0200 (CEST)
Jiri Kosina wrote:
> On Tue, 21 Oct 2014, Steven Rostedt wrote:
>
> > > Please have a look at the very first stacktrace in the dump, where
> > > lockdep
> > > is trying to explain where cpu_hotplug.lock#2 has been acquired. It seems
> > > to imply tha
On Wed, 22 Oct 2014, Steven Rostedt wrote:
> > Still, the lockdep stacktrace is bogus and didn't really help
> > understanding this. Any idea why it's wrong?
>
> Could possibly be from a tail call?
Doesn't seem so:
(gdb) disassemble cpuidle_pause
Dump of assembler code for function cpuidle_pau
On Wed, 22 Oct 2014 11:53:49 +0200 (CEST)
Jiri Kosina wrote:
> Still, the lockdep stacktrace is bogus and didn't really help
> understanding this. Any idea why it's wrong?
Could possibly be from a tail call?
>
> > ==
> > [ INFO: possible
On Wed, Oct 22, 2014 at 07:38:37AM -0700, Paul E. McKenney wrote:
> On Wed, Oct 22, 2014 at 11:53:49AM +0200, Jiri Kosina wrote:
> > On Tue, 21 Oct 2014, Jiri Kosina wrote:
> >
> > > Hi,
> > >
> > > I am seeing the lockdep report below when resuming from suspend-to-disk
> > > with current Linus'
On 10/22/2014 04:36 PM, Jiri Kosina wrote:
On Wed, 22 Oct 2014, Daniel Lezcano wrote:
I am seeing the lockdep report below when resuming from suspend-to-disk
with current Linus' tree (c2661b80609).
The reason for CCing Ingo and Peter is that I can't make any sense of one
of the stacktraces loc
On Wed, Oct 22, 2014 at 11:53:49AM +0200, Jiri Kosina wrote:
> On Tue, 21 Oct 2014, Jiri Kosina wrote:
>
> > Hi,
> >
> > I am seeing the lockdep report below when resuming from suspend-to-disk
> > with current Linus' tree (c2661b80609).
> >
> > The reason for CCing Ingo and Peter is that I can'
On Wed, 22 Oct 2014, Daniel Lezcano wrote:
> > > I am seeing the lockdep report below when resuming from suspend-to-disk
> > > with current Linus' tree (c2661b80609).
> > >
> > > The reason for CCing Ingo and Peter is that I can't make any sense of one
> > > of the stacktraces lockdep is providin
On 10/22/2014 11:53 AM, Jiri Kosina wrote:
On Tue, 21 Oct 2014, Jiri Kosina wrote:
Hi,
I am seeing the lockdep report below when resuming from suspend-to-disk
with current Linus' tree (c2661b80609).
The reason for CCing Ingo and Peter is that I can't make any sense of one
of the stacktraces l
On Wed, 22 Oct 2014, Jiri Kosina wrote:
> Still, the lockdep stacktrace is bogus and didn't really help
> understanding this. Any idea why it's wrong?
>
> > ==
> > [ INFO: possible circular locking dependency detected ]
> > 3.18.0-rc1-00069-
On Tue, 21 Oct 2014, Jiri Kosina wrote:
> Hi,
>
> I am seeing the lockdep report below when resuming from suspend-to-disk
> with current Linus' tree (c2661b80609).
>
> The reason for CCing Ingo and Peter is that I can't make any sense of one
> of the stacktraces lockdep is providing.
>
> Plea
On Tue, Oct 21, 2014 at 06:04:52PM +0200, Jiri Kosina wrote:
> On Tue, 21 Oct 2014, Paul E. McKenney wrote:
>
> > > Looks like this indeed is something that lockdep *should* report (*),
> > > although I would be suprised that stack unwinder would be so confused
> > > by this -- there is no way f
On Tue, 21 Oct 2014, Paul E. McKenney wrote:
> > Looks like this indeed is something that lockdep *should* report (*),
> > although I would be suprised that stack unwinder would be so confused
> > by this -- there is no way for synchronize_sched_expedited() to be
> > inlined all the way to cpui
On Tue, Oct 21, 2014 at 05:21:21PM +0200, Jiri Kosina wrote:
> On Tue, 21 Oct 2014, Dave Jones wrote:
>
> > > I am seeing the lockdep report below when resuming from suspend-to-disk
> > > with current Linus' tree (c2661b80609).
> > >
> > > The reason for CCing Ingo and Peter is that I can't
On Tue, 21 Oct 2014, Dave Jones wrote:
> > I am seeing the lockdep report below when resuming from suspend-to-disk
> > with current Linus' tree (c2661b80609).
> >
> > The reason for CCing Ingo and Peter is that I can't make any sense of one
> > of the stacktraces lockdep is providing.
> >
On Tue, Oct 21, 2014 at 01:09:04PM +0200, Jiri Kosina wrote:
> Hi,
>
> I am seeing the lockdep report below when resuming from suspend-to-disk
> with current Linus' tree (c2661b80609).
>
> The reason for CCing Ingo and Peter is that I can't make any sense of one
> of the stacktraces lock
On Tue, 21 Oct 2014, Steven Rostedt wrote:
> > Please have a look at the very first stacktrace in the dump, where lockdep
> > is trying to explain where cpu_hotplug.lock#2 has been acquired. It seems
> > to imply that cpuidle_pause() is taking cpu_hotplug.lock, but that's not
> > the case at al
On Tue, Oct 21, 2014 at 01:09:04PM +0200, Jiri Kosina wrote:
> Hi,
>
> I am seeing the lockdep report below when resuming from suspend-to-disk
> with current Linus' tree (c2661b80609).
>
> The reason for CCing Ingo and Peter is that I can't make any sense of one
> of the stacktraces lockdep is
Hi,
I am seeing the lockdep report below when resuming from suspend-to-disk
with current Linus' tree (c2661b80609).
The reason for CCing Ingo and Peter is that I can't make any sense of one
of the stacktraces lockdep is providing.
Please have a look at the very first stacktrace in the dump, wh
26 matches
Mail list logo
