linux-kernel - Re: CONFIG_PRINTK_TIME broken on git HEAD ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4822E23F.8040101@googlemail.com>
Date:	Thu, 08 May 2008 13:21:35 +0200
From:	Gabriel C <nix.or.die@...glemail.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>
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@...llo.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@...e.hu: various fixes and cleanups ]
>>  
>>      Signed-off-by: Peter Zijlstra <a.p.zijlstra@...llo.nl>
>>      Signed-off-by: Ingo Molnar <mingo@...e.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/