Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Herbert Valerio Riedel <hvr@gnu.org>
To: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Clem Taylor <clem.taylor@gmail.com>,
	Linux-MIPS <linux-mips@linux-mips.org>
Subject: Re: CONFIG_PRINTK_TIME and initial value for jiffies?
Date: Tue, 16 May 2006 08:03:19 +0200	[thread overview]
Message-ID: <1147759399.11301.15.camel@localhost.localdomain> (raw)
In-Reply-To: <4468F40F.80902@ru.mvista.com>

hello!

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;

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...

regards,
hvr

  reply	other threads:[~2006-05-16  6:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-15 20:41 CONFIG_PRINTK_TIME and initial value for jiffies? Clem Taylor
2006-05-15 21:11 ` Sergei Shtylyov
2006-05-15 21:35   ` Sergei Shtylyov
2006-05-16  6:03     ` Herbert Valerio Riedel [this message]
2006-05-16 12:35       ` Sergei Shtylyov
2006-05-22 16:27         ` Tim Bird

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1147759399.11301.15.camel@localhost.localdomain \
    --to=hvr@gnu.org \
    --cc=clem.taylor@gmail.com \
    --cc=linux-mips@linux-mips.org \
    --cc=sshtylyov@ru.mvista.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox