Re: Fwd: [PATCH] 2.6.18-rt7: fix more issues with 32-bit cycles_t in latency_trace.c
flat view
From: Sergei Shtylyov <hidden>
Date: 2007-07-12 17:04:26
Hello, I wrote:
In addition to clock wrap check being falsely triggered with 32-bit cycles_t, as noticed to Kevin Hilman, there's another issue: using %Lx format to print 32-bit values warrants erroneous values on 32-bit machines like ARM and PPC32.
Signed-off-by: Sergei Shtylyov <redacted>
--- PPC32 actually has 64-bit timebase counter, so could provide for 64-bit cycles_t -- maybe it's worth to rewrite get_cycles() to read both lower and upper registers?
This one (called latency-tracer-prink-fix.patch in the broken out patchset) has been erroneously "restored" some months ago. Since preempt_max_latency is of type 'unsigned long' now and all the other vars are of type 'cycle_t' (which aliases 'u64'), only the first cast is actually needed (or rather, the first format specifier needs to be changed to %08lx). Erm, maybe I'll cook a patch...
quoted hunk ↗ jump to hunk
Index: linux-2.6/kernel/latency_trace.c ===================================================================--- linux-2.6.orig/kernel/latency_trace.c +++ linux-2.6/kernel/latency_trace.c@@ -1623,8 +1623,8 @@ check_critical_timing(int cpu, struct cp #ifndef CONFIG_CRITICAL_LATENCY_HIST if (!preempt_thresh && preempt_max_latency > delta) { printk("bug: updating %016Lx > %016Lx?\n", - preempt_max_latency, delta); - printk(" [%016Lx %016Lx %016Lx]\n", T0, T1, T2); + (u64)preempt_max_latency, (u64)delta); + printk(" [%016Lx %016Lx %016Lx]\n", (u64)T0, (u64)T1, (u64)T2); } #endif
WBR, Sergei