Messages in this thread | | | Date | Thu, 08 May 2008 13:21:35 +0200 | From | Gabriel C <> | Subject | Re: CONFIG_PRINTK_TIME broken on git HEAD ? |
| |
Peter Zijlstra wrote: > On Thu, 2008-05-08 at 13:00 +0200, Gabriel C wrote: > >>> >From my log 2.6.26-rc1-00065-g5717922 was fine. >>> >> >>> May 6 00:13:14 thor kernel: [ 0.000000] Allocating PCI resources starting at d0000000 (gap: cf600000:2f800000) >>> May 6 00:13:14 thor kernel: [ 0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs >>> May 6 00:13:14 thor kernel: [ 0.000000] PERCPU: Allocating 41732 bytes of per cpu data >>> May 6 00:13:14 thor kernel: [ 0.000000] Kernel command line: root=/dev/sdb1 ro debug vga=0x317 >>> May 6 00:13:14 thor kernel: [ 0.000000] Preemptible RCU implementation. >>> May 6 00:13:14 thor kernel: [ 0.000000] Extended CMOS year: 2000 >>> May 6 00:13:14 thor kernel: [ 0.000000] TSC calibrated against PM_TIMER >>> May 6 00:13:14 thor kernel: [ 0.000014] time.c: Detected 2499.952 MHz processor. >>> May 6 00:13:14 thor kernel: [ 0.000032] console [tty0] enabled >>> May 6 00:13:14 thor kernel: [ 0.000999] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) >>> May 6 00:13:14 thor kernel: [ 0.000999] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) >>> May 6 00:13:14 thor kernel: [ 0.000999] Checking aperture... >>> >>> ... >>> >>>>> dmesg shows here : >>>>> >>>>> ... >>>>> >>>>> >>>>> [ 0.000000] Allocating PCI resources starting at d0000000 (gap: cf600000:2f800000) >>>>> [ 0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs >>>>> [ 0.000000] PERCPU: Allocating 42756 bytes of per cpu data >>>>> [ 0.000000] NR_CPUS: 8, nr_cpu_ids: 4 >>>>> [4294014.506571] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1010753 >>>>> [4294014.506571] Kernel command line: root=/dev/sdb1 ro debug vga=0x317 >>>>> [4294014.506571] Initializing CPU#0 >>>>> [4294014.506571] Preemptible RCU implementation. >>>>> [4294014.506571] PID hash table entries: 4096 (order: 12, 32768 bytes) > > >> I've bisected it. > >> cat ./.git/refs/bisect/bad >> 3e51f33fcc7f55e6df25d15b55ed10c8b4da84cd >> >> git show 3e51f33fcc7f55e6df25d15b55ed10c8b4da84cd >> commit 3e51f33fcc7f55e6df25d15b55ed10c8b4da84cd >> Author: Peter Zijlstra <a.p.zijlstra@chello.nl> >> Date: Sat May 3 18:29:28 2008 +0200 >> >> sched: add optional support for CONFIG_HAVE_UNSTABLE_SCHED_CLOCK >> >> this replaces the rq->clock stuff (and possibly cpu_clock()). >> >> - architectures that have an 'imperfect' hardware clock can set >> CONFIG_HAVE_UNSTABLE_SCHED_CLOCK >> >> - the 'jiffie' window might be superfulous when we update tick_gtod >> before the __update_sched_clock() call in sched_clock_tick() >> >> - cpu_clock() might be implemented as: >> >> sched_clock_cpu(smp_processor_id()) >> >> if the accuracy proves good enough - how far can TSC drift in a >> single jiffie when considering the filtering and idle hooks? >> >> [ mingo@elte.hu: various fixes and cleanups ] >> >> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> >> Signed-off-by: Ingo Molnar <mingo@elte.hu> >> > > Ok, so the issue is that the clock doesn't start at 0, but at: > 4294014.506571 ?
At least on my box , yes.
There is a similar report http://lkml.org/lkml/2008/5/8/100 , there it jumps to 42949372.961619
> I guess that's a side-effect of using ktime to base the clock off. > Thomas, do we have a clock that is uptime based? >
Gabriel
| |