Bug 895909

Summary:	incorrect time in dmesg
Product:	[Fedora] Fedora	Reporter:	Marcela Mašláňová <mmaslano>
Component:	util-linux	Assignee:	Karel Zak <kzak>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	18	CC:	jonathan, kzak, mluscon, redhat
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-01-18 09:37:57 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Marcela Mašláňová 2013-01-16 09:13:59 UTC

Description of problem:
The date in dmesg is incorrect with -T option. It's happening after sleep/hibernate/resume of computer. On the other hand time in /var/log/messages is correct. 
I'm not sure whether it is a problem of dmesg or kernel or logging.

Version-Release number of selected component (if applicable):
util-linux-2.22.1-2.4.fc18.x86_64

How reproducible:


Steps to Reproduce:
1. sleep the system
2. resume
3. date
Wed Jan 16 10:07:32 CET 2013
4. dmesg -T
[Wed Jan  9 08:49:10 2013] PM: Finishing wakeup.
[Wed Jan  9 08:49:10 2013] Restarting tasks ... done.
[Wed Jan  9 08:49:10 2013] video LNXVIDEO:00: Restoring backlight state
[Wed Jan  9 08:49:10 2013] e1000e 0000:00:19.0: irq 52 for MSI/MSI-X
[Wed Jan  9 08:49:10 2013] e1000e 0000:00:19.0: irq 52 for MSI/MSI-X
[Wed Jan  9 08:49:10 2013] IPv6: ADDRCONF(NETDEV_UP): em1: link is not ready
[Wed Jan  9 08:49:10 2013] IPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready
[Wed Jan  9 08:49:13 2013] e1000e: em1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
[Wed Jan  9 08:49:13 2013] IPv6: ADDRCONF(NETDEV_CHANGE): em1: link becomes ready
5. tail /var/log/messages
Jan 16 10:03:30 localhost dnsmasq[1178]: reading /etc/resolv.conf
Jan 16 10:03:30 localhost dnsmasq[1178]: using nameserver 10.34.255.6#53
Jan 16 10:03:30 localhost dnsmasq[1178]: using nameserver 10.34.255.7#53
Jan 16 10:03:30 localhost dnsmasq[1178]: using local addresses only for unqualified names
Jan 16 10:03:34 localhost chronyd[890]: Selected source 10.11.160.238

  
Actual results:


Expected results:


Additional info:

Comment 1 Marcela Mašláňová 2013-01-16 09:21:40 UTC

I read in man page, dmesg -T could give inaccurate time, but there must be wrong more things. Abrt is not able to find out crashes from this week, so there must be something wrong with timestamps, but not sure where.

Comment 2 Karel Zak 2013-01-18 09:37:57 UTC

dmesg -T cannot be correct after suspend/resume. dmesg(1) uses the timestamp generated by kernel and in-kernel printk() does not use regular system time (aka gettimeofday etc.).

I guess that syslogd/journald uses the current system time rather than the timestamp generated by kernel.