7008793d77
dmesg -T and the actual time a message was produced, noted on current-users by Geoff Wing (Oct 27, 2018). The size of the offset would depend upon architecture, and processor, but was the delay from starting the clocks to initialising the time of day (after mounting root, in case that is needed). Change the kernel to set boottime to be the time at which the clocks were started, rather than the time at which it is init'd (by subtracting the interval between). Correct dmesg to properly compute the ToD based upon the boottime (which is a timespec, not a timeval, and has been since Jan 2009) and the time logged in the message. Note that this can (rarely) be 1 second earlier than date reports. This occurs when the time when the message was logged was actually in the next second, but the timecounters have not yet processed the tick, and so the time of the last tick, near the end of the previous second, is reported instead. Since times are always truncated, rather than rounded, it is occasionally possible to observe that disparity (if you try hard enough). IOW: sys/kern/subr_prf.c:addtstamp() uses getnanouptime() rather than nanouptime(). Note in dmesg(8) that -T conversions are gibberish other than when the message comes from current the running kernel. (It could be fixed when -M is used, for messages generated by the kernel whose corpse is being observed. But hasn't been...) |
||
|---|---|---|
| .. | ||
| dmesg.8 | ||
| dmesg.c | ||
| Makefile | ||