Messages in this thread Patch in this message | | | Date | Wed, 13 Aug 2008 09:19:05 +0200 | From | Ingo Molnar <> | Subject | Re: [git pull] ftrace for v2.6.27 |
| |
* Bruce Duncan <bwduncan@gmail.com> wrote:
> Hi Ingo, Steven, everyone, > > [ Please CC me in replies ] > > I have just tracked down a regression in 2.6.27-rc2 wrt 2.6.26. Commit > 77a2b37d227483fe52aead242652aee406c25bf0 (ftrace: startup tester on > dynamic tracing.) causes my laptop to fail to resume from S3 (it > simply reboots about a second after the resume starts and the display > never shows anything). > > The patch doesn't revert with patch -R (I don't know if there's a > cleverer way to ask git to revert it), but the problem goes away if I > turn off CONFIG_DYNAMIC_FTRACE. > > The commit and bisect log are attached. Please can you help me to > debug this?
could you please send your .config file as well?
Suspend+resume bugs are notoriously hard to debug (there's no console output in most cases), so i guess the best way to debug this is for Steve or me to try to reproduce it. Could you send the output of this script:
http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh
that will tell us what kind of hw you have.
and could you perhaps try the patch below? The patch disables on the fly dynamic code patching - which is the primary suspect here. If it makes a difference on your box then a theory would be that ftraced runs too soon after suspend+resume.
Ingo
-----------------------> Subject: ftrace: debug From: Ingo Molnar <mingo@elte.hu> Date: Wed Aug 13 09:17:12 CEST 2008
Signed-off-by: Ingo Molnar <mingo@elte.hu> --- kernel/trace/ftrace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/kernel/trace/ftrace.c =================================================================== --- linux.orig/kernel/trace/ftrace.c +++ linux/kernel/trace/ftrace.c @@ -811,7 +811,7 @@ static int ftraced(void *ignore) /* check once a second */ schedule_timeout(HZ); - if (unlikely(ftrace_disabled)) + if (1) continue; mutex_lock(&ftrace_sysctl_lock);
| |