On Mon, 2018-01-08 at 20:07 -0500, Steven Rostedt wrote: > On Mon, 08 Jan 2018 17:02:29 -0800 > Todd Brandt <todd.e.bra...@linux.intel.com> wrote: > > > Stephen, the problem is reversed by removing the following two > > commits, > > the one the bisect showed and the very next. So the problem is > > here: > > > > commit 1a149d7d3f45d311da1f63473736c05f30ae8a75 > > Author: Steven Rostedt (VMware) <rost...@goodmis.org> > > Date: Fri Sep 22 16:59:02 2017 -0400 > > > > ring-buffer: Rewrite trace_recursive_(un)lock() to be simpler > > This one still doesn't make sense, for why it would cause the hang. > > > > commit 12ecef0cb12102d8c034770173d2d1363cb97d52 > > Author: Steven Rostedt (VMware) <rost...@goodmis.org> > > Date: Thu Sep 21 16:22:49 2017 -0400 > > > > tracing: Reverse the order of trace_types_lock and event_mutex > > This one does. > > Can you run lockdep when you do this and see if lockdep catches > anything? If it does, it should point directly to where the inversed > locking happened.
Can you reproduce the issue there? I just want to be sure it's not something local to our machines here, as long as you have CONFIG_PM enabled it should work the same hopefully. I'll give lockdep a try here. > > -- Steve
