lkml.org 
[lkml]   [2008]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: ftraced and suspend to ram
    Date
    On Friday, 22 of August 2008, Marcin Slusarz wrote:
    > On Fri, Aug 22, 2008 at 09:23:43AM +0200, Pavel Machek wrote:
    > > >
    > > > * Rafael J. Wysocki <rjw@sisk.pl> wrote:
    > > >
    > > > > > > The code in question is the ftraced() function in
    > > > > > > kernel/trace/ftrace.c
    > > > > >
    > > > > > Thanks, I'll have a look in a while.
    > > > >
    > > > > Can you try the appended patch, please?
    > > >
    > > > makes sense - i've applied it to tip/tracing/urgent, see the tidied up
    > > > commit below.
    > > >
    > > > It should be no big issue not being able to trace across suspend+resume
    > > > - and that restriction will go away with Steve's build-time based mcount
    > > > patching mechanism in v2.6.28.
    > >
    > > Patch looks okay to me, but I'm not sure if another issue is not
    > > hiding under it. Did anyone actually test ftrace + suspend after
    > > applying this?
    >
    > I just tested this patch - it didn't help ;(
    >
    > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
    > index 49f4c3f..02e41b2 100644
    > --- a/kernel/trace/ftrace.c
    > +++ b/kernel/trace/ftrace.c
    > @@ -27,6 +27,7 @@
    > #include <linux/ctype.h>
    > #include <linux/hash.h>
    > #include <linux/list.h>
    > +#include <linux/freezer.h>
    >
    > #include <asm/ftrace.h>

    This is needed to fix compilation, sorry for the omission.

    Still, did you test ftrace + suspend with the original patch and your fix
    applied and if you did, then what happend?

    Rafael


    \
     
     \ /
      Last update: 2008-08-22 18:39    [W:3.929 / U:0.124 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site