lkml.org 
[lkml]   [2009]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: s2r badness

On Tue, 21 Jul 2009, Thomas Gleixner wrote:

> On Mon, 20 Jul 2009, Steven Rostedt wrote:
> > >
> > > Just to make the list more complete. If tracing is enabled across
> > > suspend/resume you'll hit that one as well:
> > >
> > > WARNING: at /home/tglx/work/kernel/git/linux-2.6/kernel/trace/ring_buffer.c:1392 rb_reserve_next_event+0x133/0x27c()
> > >
> > > Negative timestamp delta which is probably due to sched_clock not yet
> > > adjusted to the TSC which got reset.
> >
> > Perhaps we need to prevent tracing during a "blackout period" of suspend
> > to ram?
>
> Perhaps we need to figure out why this is happening and how we best
> deal with it. Disabling functionality just because we can not deal
> with it right now is not a solution.

Heh, suspend to ram is a black magic art. There's voodoo there that causes
ulcers when you look the wrong way. For example, there's times that simply
calling smp_processor_id() will reboot the box. Hence, the tracer is very
intrusive, and we need to prevent it from doing things at certain areas.
I'm not saying disabling functionality per say, I'm just saying that we
need to make sure the tracer is not doing something in the guts of
bringing the CPU back on line when it is not ready.

Are you saying that we need to move the initialization of sched_clock up,
just to satisfy tracing? If that happens to be the issues here?

-- Steve



\
 
 \ /
  Last update: 2009-07-21 01:53    [W:0.080 / U:0.868 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site