[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1227562985.7622.5.camel@localhost.localdomain>
Date: Mon, 24 Nov 2008 16:43:05 -0500
From: Steven Rostedt <srostedt@...hat.com>
To: Ingo Molnar <mingo@...e.hu>
Cc: "Rafael J. Wysocki" <rjw@...k.pl>,
Peter Teoh <htmldeveloper@...il.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] tracing: allow tracing of suspend/resume & hibernation
code again
On Sun, 2008-11-23 at 10:41 +0100, Ingo Molnar wrote:
> * Rafael J. Wysocki <rjw@...k.pl> wrote:
>
> > > Q2: how to ftrace s2ram and resume? I attempted to do it, but the
> > > trace output is always filled with "resume" related functions when
> > > it started up, which is only logical.
> >
> > The tracing is disabled during suspend/resume, so you can't.
>
> i think we could lift this restriction now that dftrace is gone for
> good - which was causing most of the trouble.
The suspend resume problem did not happen with the dtrace. But whenever
there is a trace happening. It would fail with the stack tracer on with
the static function tracer.
The problem is that there are several functions in resume that are
called without first setting up smp_processor_id(). That is, if you
call smp_processor_id() it will crash the system. The function tracer
uses smp_processor_id() to stop recursion (per_cpu disabled variable).
Anything that actually tries to use the ring buffer will also crash,
since it too will use smp_processor_id to find the per cpu ring buffer
to write to.
-- Steve
>
> 41108eb10142e0552f2de1e4c0675b108c5f018f
> f42ac38c59e0a03d6da0c24a63fb211393f484b0
>
> Completely untested patch below. Peter, does it work for you?
>
--
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