Date:Tue, 30 Oct 2018 12:31:02 -0700
From:Dennis Ferguson
Message-ID:
You might, or might not depending which lists you read, have noticed that
I was working on this about the same time you were sending this message.
| Note that time_second(9) says boottime is
dennis.c.fergu...@gmail.com (Dennis Ferguson) writes:
>It may be worth pointing out that the code in kern/kern_tc.c is written to
>maintain the identity
>time = uptime + boottime
>at all times, except that it instead maintains a local version of boottime
>in the local variable timebasebin.
> On Oct 29, 2018, at 17:21, Robert Elz wrote:
>
> | We are talking about internal kernel data. If you need $uptime, you
> | could expose it like $boottime.
>
> We could, but deisigning a system where now - boottime != uptime is
> kind of weird, don't you think? boottime is where it all
k...@munnari.oz.au (Robert Elz) writes:
>We could, but deisigning a system where now - boottime != uptime is
>kind of weird, don't you think? boottime is where it all starts, if boottime
>is X, and uptime is Y, then X + Y should be now.
Weird, but that's how the real world is, arbitrary and
Date:Mon, 29 Oct 2018 07:03:21 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| Being "plausible" is irrelevant here, we are just talking about
| time stamps that are useful, not some meaning in the real world.
That might be what you're
k...@munnari.oz.au (Robert Elz) writes:
> | > 1. when the firmware is told to boot
> | > 2. when the boot loader gets control from the firmware
> | > 3. when the kernel first starts executing.
> | 3a. when the kernel has started clock
> | 3b. when the kernel has mounted root
> | > 4.
Date:Sun, 28 Oct 2018 13:14:34 +0100
From:Michael van Elst
Message-ID: <20181028121433.ga20...@serpens.de>
| On Sun, Oct 28, 2018 at 04:45:58PM +0700, Robert Elz wrote:
|
| > 1. when the firmware is told to boot
| > 2. when the boot loader gets control from
On Sun, Oct 28, 2018 at 04:45:58PM +0700, Robert Elz wrote:
> 1. when the firmware is told to boot
> 2. when the boot loader gets control from the firmware
> 3. when the kernel first starts executing.
3a. when the kernel has started clock
3b. when the kernel has mounted root
> 4. When the
Date:Sun, 28 Oct 2018 07:45:12 - (UTC)
From:mlel...@serpens.de (Michael van Elst)
Message-ID:
| We could save the uptime value at that point and make dmesg -T adjust
| the timestamps accordingly
I think we need to define just what is boottime? sysctl(7) is
g...@pobox.com (Geoff Wing) writes:
>From my quick look, sys/kern/init_main.c:666 initialises boottime
>after mounting the root file system, so "dmesg -T" is using a bad
>value.
When there is no TOD clock, the time is deduced from the timestamp in the
superblock of the root filesystem. That's
On Sunday 2018-10-28 13:16 +1100, Geoff Wing output:
:Hi,
:I'm running the same -current build on two x64 machines. One is a VM
:and the other is bare-metal. I'm rebuilding in case something funny
:happened in the build and noone else can reproduce anything similar.
:
:The ntpdate in
On Sunday 2018-10-28 08:32 +0700, Robert Elz output:
:I don't suppose that your ToD clock is 6 seconds incorrect, and
:ntpdate run from /etc/rc is fixing that (but the ToD clock isn't being
:updated) ?
:
:if it is not that, then you're right, something weird is happening.
Hi,
I'm running the same
Date:Sun, 28 Oct 2018 12:01:55 +1100
From:Geoff Wing
Message-ID: <20181028010155.ga1...@primenet.com.au>
| Ah, I just rebooted it so that's 1 min and 13 seconds,
| not 1 month and 13 seconds.
I should have known that, since I'm responsible for the current code
On Sunday 2018-10-28 07:19 +0700, Robert Elz output:
: | The dmesg time matches what appears in kern.boottime but I don't see a 5-6
: | second step in rc.log when ntpdate is run.
:You wouldn't now. The system from which you showed that output has
:been up for a month. During that month,
Date:Sun, 28 Oct 2018 09:51:43 +1100
From:Geoff Wing
Message-ID: <20181027225143.ga...@primenet.com.au>
| The dmesg time matches what appears in kern.boottime but I don't see a 5-6
| second step in rc.log when ntpdate is run.
You wouldn't now. The system from
On Saturday 2018-10-27 19:03 +0700, Robert Elz output:
:Date:Sat, 27 Oct 2018 17:39:16 +1100
:From:Geoff Wing
:Message-ID: <20181027063916.ga2...@primenet.com.au>
:
: | dates output by "dmesg -T" are not matching real time. Using a program
: | to generate a
Date:Sat, 27 Oct 2018 17:39:16 +1100
From:Geoff Wing
Message-ID: <20181027063916.ga2...@primenet.com.au>
| dates output by "dmesg -T" are not matching real time. Using a program
| to generate a segfault dmesg is showing times in the future:
dmesg times come
Hi,
dates output by "dmesg -T" are not matching real time. Using a program
to generate a segfault dmesg is showing times in the future:
# sysctl -w kern.logsigexit=1
kern.logsigexit: 0 -> 1
# ./segfault; date
[1]18445 segmentation fault ./segfault
Sat Oct 27 17:33:56 AEDT 2018
# dmesg -T |
18 matches
Mail list logo
