Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 10 Jan 2020 13:06:03 +0900
From:   Mike Hommey <mh@glandium.org>
To:     linux-kernel@vger.kernel.org
Subject: Uptime completely off after resume from suspend
Message-ID: <20200110040603.3lxanijleog6tfl6@glandium.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: NeoMutt/20180716
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi,

I have a one month old machine, and was surprised to notice an uptime of
several hundreds of days in top. Since I had been suspending the machine
on many occasions, I was wondering if that could be related, so I put
the machine to sleep, came back 30 minutes later, and uptime had
advanced 35 days!

The actual boot time, according to journald was a week ago. And the
"timestamp" for the suspend exit in dmesg is 312967, which is about 86
hours, which is about half, which seems about right considering the
suspends.

The wall clock time and date is right too at the time of resume in the
journald logs, assuming systemd-timesyncd doesn't synchronize with NTP
before systemd logs "Started Suspend" after resuming.

This is all with 5.5rc4 + the patches from the Debian kernel packages,
on a Threadripper 3970X, in case that matters.

Any hints where I should be looking to find out what's going wrong?

Cheers,

Mike