lkml.org 
[lkml]   [2008]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: CONFIG_PRINTK_TIME broken on git HEAD ?
    From
    Date
    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 ?

    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?




    \
     
     \ /
      Last update: 2008-05-08 13:17    [W:0.034 / U:118.336 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site