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 <[email protected]>
---
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?
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
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
