On Fri, 2006-12-01 at 09:08 +0100, Ingo Molnar wrote: > * Fernando Lopez-Lezcano <[EMAIL PROTECTED]> wrote: > could you try the patch below? It changes trace entries to be measured > via get_cycles() again [which should be must faster than pmtimer on your > CPU], but keeps the latency tracing timestamps (the timestamp of the > start/end of critical sections) on pmtimer again. This should give us > accurate latency measurements, but fast trace entries. > > you can still revert to the conservative timestamping behavior via: > > echo 0 > /proc/sys/kernel/trace_use_raw_cycles > > note: you can probably get a higher quality of 'overview trace' via: > > echo 0 > /proc/sys/kernel/mcount_enabled > echo 1 > /proc/sys/kernel/stackframe_tracing
If I do this I get a lockup or an instant reboot. But it looks like something is wrong. I'm not getting traces at all and the preempt_max_latency remains stubbornly at 0. I'll try with the previous kernel but I'll just turn on tracing for all activity, not just within the jackd client activation cycle. It looks like the xruns are happening elsewhere. -- Fernando PS: this is what I'm using to "arm" the trace (from the trace-it.c example): ----- #!/bin/bash # echo 1 > /proc/sys/kernel/trace_user_triggered [ -e /proc/sys/kernel/wakeup_timing ] && echo 1 > /proc/sys/kernel/wakeup_timing echo 1 > /proc/sys/kernel/trace_enabled # get better quality traces echo 1 > /proc/sys/kernel/mcount_enabled # echo 0 > /proc/sys/kernel/mcount_enabled # echo 1 > /proc/sys/kernel/stackframe_tracing echo 0 > /proc/sys/kernel/trace_freerunning echo 0 > /proc/sys/kernel/trace_print_at_crash echo 0 > /proc/sys/kernel/trace_verbose echo 0 > /proc/sys/kernel/preempt_thresh 2>/dev/null echo 0 > /proc/sys/kernel/preempt_max_latency 2>/dev/null ----- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
