Re: 2.6.15-rt4 failure with LATENCY_TRACE on x86_64

* Re: 2.6.15-rt4 failure with LATENCY_TRACE on x86_64
       [not found] <1137103652.11354.40.camel@localhost.localdomain>
@ 2006-01-13  3:18 ` Steven Rostedt
  2006-01-13 15:06   ` Clark Williams
  0 siblings, 1 reply; 7+ messages in thread
From: Steven Rostedt @ 2006-01-13  3:18 UTC (permalink / raw)
  To: Clark Williams; +Cc: Ingo Molnar, lkml

On Thu, 2006-01-12 at 16:07 -0600, Clark Williams wrote:
> Ingo/Steve,
> 
> Did I miss a "Don't turn on latency tracing for x86_64" message
> somewhere?
> 
> I'm seeing a failure on my Athlon64 3000+ where, when I turn on
> CONFIG_LATENCY_TRACE, the init program segfaults. Doesn't happen with a
> statically linked shell like sash (e.g. init=/sbin/sash boots ok), but
> if /sbin/init or /bin/sh is used, the init program segfaults. Presumably
> any dynamically linked program will fail. 
> 
> Attached is console output for a boot failure (segfault messages
> truncated after four lines, since they're all the same) as well as the
> config files for both working and failing kernels.
> 
> I'm not sure where to start looking on this one. Barring any advise, I'm
> going to look for occurrences of CONFIG_LATENCY_TRACE, especially in
> proximity to exec.

OK, I'm actually sending you this email on a x86_64 running
2.6.15-rt4-sr2, with latency tracing on.  But unfortunately, I have a
AMD X2 that each core has it's own tsc counter that is not in sync, and
since the latency tracer uses tsc, I get garbage.  But beware, the tsc
does slow down when the cpu idles, so it gives bad results even for non
x2 systems.

I finally was able to boot this with using the PM timer, but the
beginning of my dmesg is still filled with:

read_tsc: ACK! TSC went backward! Unsynced TSCs?

Have you tried booting with idle=poll? I wonder if that would help?

-- Steve

^ permalink raw reply	[flat|nested] 7+ messages in thread