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
On Fri, Jan 10, 2020 at 01:06:03PM +0900, Mike Hommey wrote:
> 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?
FWIW, it doesn't seem to have happened in 8 days of running 5.5rc6.
Cheers,
Mike