summaryrefslogtreecommitdiffstats
path: root/init/main.c
diff options
context:
space:
mode:
authorThomas Gleixner <tglx@linutronix.de>2009-08-21 22:01:12 +0200
committerThomas Gleixner <tglx@linutronix.de>2009-08-27 16:38:18 +0200
commitfa84e9eecfff478df2d00e94deb3fc40fe4634ad (patch)
treef7fead8e4b2dfbac63fc9bed132d12a95b9690cd /init/main.c
parent1e23502cc57cef33455ac7cb9111e3c6d991a894 (diff)
downloadlinux-fa84e9eecfff478df2d00e94deb3fc40fe4634ad.tar.gz
linux-fa84e9eecfff478df2d00e94deb3fc40fe4634ad.tar.bz2
linux-fa84e9eecfff478df2d00e94deb3fc40fe4634ad.zip
init: Move sched_clock_init after late_time_init
Some architectures initialize clocks and timers in late_time_init and x86 wants to do the same to avoid FIXMAP hackery for calibrating the TSC. That would result in undefined sched_clock readout and wreckaged printk timestamps again. We probably have those already on archs which do all their time/clock setup in late_time_init. There is no harm to move that after late_time_init except that a few more boot timestamps are stale. The scheduler is not active at that point so no real wreckage is expected. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> LKML-Reference: <new-submission> Cc: linux-arch@vger.kernel.org
Diffstat (limited to 'init/main.c')
-rw-r--r--init/main.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/init/main.c b/init/main.c
index 11f4f145be3f..0ec75ce771ac 100644
--- a/init/main.c
+++ b/init/main.c
@@ -631,7 +631,6 @@ asmlinkage void __init start_kernel(void)
softirq_init();
timekeeping_init();
time_init();
- sched_clock_init();
profile_init();
if (!irqs_disabled())
printk(KERN_CRIT "start_kernel(): bug: interrupts were "
@@ -682,6 +681,7 @@ asmlinkage void __init start_kernel(void)
numa_policy_init();
if (late_time_init)
late_time_init();
+ sched_clock_init();
calibrate_delay();
pidmap_init();
anon_vma_init();