[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141205134933.GM1630@arm.com>
Date: Fri, 5 Dec 2014 13:49:33 +0000
From: Will Deacon <will.deacon@....com>
To: Dave Jones <davej@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"Kirill A. Shutemov" <kirill@...temov.name>,
Tejun Heo <tj@...nel.org>,
Andy Lutomirski <luto@...capital.net>,
Don Zickus <dzickus@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Linux Kernel <linux-kernel@...r.kernel.org>,
the arch/x86 maintainers <x86@...nel.org>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: frequent lockups in 3.18rc4
On Thu, Dec 04, 2014 at 02:56:31PM +0000, Dave Jones wrote:
> On Thu, Dec 04, 2014 at 10:51:03AM +0000, Will Deacon wrote:
>
> > and, as before, it has a weird child process that I can't backtrace:
> >
> > trinity-c1 R running task 0 861 811 0x00000000
> > Call trace:
>
> When I get these, ftrace is a godsend.
>
> cd /sys/kernel/debug/tracing/
> echo 861 >> set_ftrace_pid
> echo function_graph >> current_tracer
> echo 1 >> tracing_on
> wait a little while
> cat trace > trace.txt
>
> repeat last two steps if necessary
>
> (assuming it's stuck in kernel space, which /proc/861/stack should
> be able to confirm. Usually when I see this problem, that just shows
> 0xffffffffffffffff)
That would be great if I had a working shell :)
I tried enabling the thing before starting trinity, in the hope of dumping
the buffer using sysrq, but now I seem to have hit an unrelated panic in
the ftrace code.
Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists