linux-mips
[Top] [All Lists]

Re: CONFIG_PRINTK_TIME and initial value for jiffies?

To: Herbert Valerio Riedel <hvr@gnu.org>
Subject: Re: CONFIG_PRINTK_TIME and initial value for jiffies?
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Date: Tue, 16 May 2006 16:35:43 +0400
Cc: Clem Taylor <clem.taylor@gmail.com>, Linux-MIPS <linux-mips@linux-mips.org>
In-reply-to: <1147759399.11301.15.camel@localhost.localdomain>
Organization: MontaVista Software Inc.
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <ecb4efd10605151341l33f491f1ueca8a0ce609c989d@mail.gmail.com> <4468EE9B.4000009@ru.mvista.com> <4468F40F.80902@ru.mvista.com> <1147759399.11301.15.camel@localhost.localdomain>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803
Hello.

Herbert Valerio Riedel wrote:

On Tue, 2006-05-16 at 01:35 +0400, Sergei Shtylyov wrote:

I just switched to 2.6.16.16 from 2.6.14 on a Au1550. I enabled
CONFIG_PRINTK_TIME, and for some reason jiffies doesn't start out near
zero like it does on x86. The first printk() always seems to have a
time of 4284667.296000.

jiffies_64 and wall_jiffies gets initialized to INITIAL_JIFFIES, but
I'm not sure where jiffies is initialized. INITIAL_JIFFIES is -300*HZ
(with some weird casting)

   Yes, the casting is weird. I somewat doubt that:

#define INITIAL_JIFFIES ((unsigned long)(unsigned int) (-300*HZ))

u64 jiffies_64 = INITIAL_JIFFIES;

can do the trick of wrapping around 5 mins after boot on x86... :-/

jfyi, starting with an offset of -300 seconds is done on purpose, to
expose bugs in drivers which don't handle wrapping of the jiffies;

   Oh, thank you. I've read that in the source code. :-)

and the trick to get printk to start at offset 0 is either define a
arch-specific printk_clock() function (it's a weak symbol in
kernel/printk.c) or like more drivers to it, to provide a sched_clock()
(which is used by the default printk_clock() function) implementation
which starts at offset 0...

sched_clock() defined in arch/i386/kernel/timers/timer_tsc.c can hardly provide 0-based time if it's using TSC (at least I can't see where the TSC is cleared). Even if it's not using TSC, jiffies_64 is not 0-based as we saw, and neither it's set to -300 secs because of the double cast to ulong and then to u64 which should clear the high word. Probably something somewhere clears TSC but I can see the related code only in arch/i386/kernel/smpboot.c...

regards,
hvr

WBR, Sergei

<Prev in Thread] Current Thread [Next in Thread>