Messages in this thread | | | Date | Mon, 20 Jul 2009 19:51:25 -0400 (EDT) | From | Steven Rostedt <> | Subject | Re: 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
| |