I'm also seeing this issue, also on a Debian Linux 4.19 kernel (on
updated Debian unstable VM), also on KVM, straight after rebooting the
VM. But without any suspending involved, I just reboot the VM, and as
soon as I can log in after rebooting its showing 6+ days of uptime.
The uptime jumps *very* early in the boot sequence, at the point that
kvm-clock starts reporting, by many days in my case.
Of note, the KVM host here is pretty old (Ubuntu 14.04 LTS, on
3.13.0-164-generic kernel, and qemu-kvm 2.0.0+dfsg-2ubuntu1.44). It's
also naturally a fairly old CPU (Intel Xeon X3450).
So I wonder if part of the trigger is newer (4.19) kernels relying on
CPU/hypervisor features that older CPUs / older hypervisors do not
provide/initialise. And maybe reading an uninitialised value as a result.
From reading the upstream thread, this seems the closest to diagnosis:
https://lore.kernel.org/lkml/20190126020410.gb3...@feynman.vault24.org/
around guest clock sources being chosen, and apparently the upstream
maintainer has managed to reproduce the issue:
https://lore.kernel.org/lkml/20190126161137.gme4vsrz3xmnc...@soleen.tm1wkky2jk1uhgkn0ivaxijq1c.bx.internal.cloudapp.net/
by changing the clock source (to HPET), as of late Jan 2019.
Ewen
-=- cut here -=-
ewen@debian-unstable:~$ uptime
11:21:06 up 6 days, 22:40, 1 user, load average: 0.88, 0.75, 0.52
ewen@debian-unstable:~$ last | head -5
ewen pts/0 172.20.254.10 Mon Feb 11 11:10 still logged in
reboot system boot 4.19.0-2-amd64 Mon Feb 11 11:07 still running
ewen ttyS0 Mon Feb 11 11:06 - down (00:00)
ewen pts/0 172.20.254.10 Mon Feb 11 11:06 - down (00:00)
reboot system boot 4.19.0-2-amd64 Mon Feb 11 11:05 - 11:06 (00:01)
ewen@debian-unstable:~$ date
Mon Feb 11 11:21:21 NZDT 2019
ewen@debian-unstable:~$
ewen@debian-unstable:~$ uname -r
4.19.0-2-amd64
ewen@debian-unstable:~$ dpkg -l | grep linux-image
ii linux-image-4.19.0-1-amd64 4.19.13-1
amd64 Linux 4.19 for 64-bit PCs (signed)
ii linux-image-4.19.0-2-amd64 4.19.16-1
amd64 Linux 4.19 for 64-bit PCs (signed)
ii linux-image-amd64 4.19+102
amd64 Linux for 64-bit PCs (meta-package)
ewen@debian-unstable:~$
ewen@debian-unstable:~$ sudo dmesg | grep -A 4 "Hypervisor"
[ 0.000000] Hypervisor detected: KVM
[ 0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00
[599207.077513] kvm-clock: cpu 0, msr 117d7001, primary cpu clock
[599207.077513] clocksource: kvm-clock: mask: 0xffffffffffffffff
max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[599207.077516] tsc: Detected 2659.982 MHz processor
ewen@debian-unstable:~$
ewen@debian-unstable:~$ sudo dmesg | head -20 | grep -v BIOS-e820
[ 0.000000] Linux version 4.19.0-2-amd64
(debian-ker...@lists.debian.org) (gcc version 8.2.0 (Debian 8.2.0-14))
#1 SMP Debian 4.19.16-1 (2019-01-17)
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-2-amd64
root=UUID=260df8b9-6a61-4f0e-9625-340dcdaf4017 ro console=ttyS0,9600
[ 0.000000] x86/fpu: x87 FPU will use FXSAVE
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] SMBIOS 2.4 present.
[ 0.000000] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs
01/01/2011
[ 0.000000] Hypervisor detected: KVM
[ 0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00
[599207.077513] kvm-clock: cpu 0, msr 117d7001, primary cpu clock
[599207.077513] clocksource: kvm-clock: mask: 0xffffffffffffffff
max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[599207.077516] tsc: Detected 2659.982 MHz processor
[599207.078351] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
ewen@debian-unstable:~$
-=- cut here -=-
-=- cut here -=-
ewen@naosdell:~$ head -5 /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Xeon(R) CPU X3450 @ 2.67GHz
ewen@naosdell:~$
-=- cut here -=-