Surface Pro 8 loses system time on power off

[rommeswi]

Whenever I shut down my surface pro, after restarting the system clock is off by about 1 hour and 15 minutes. The time gets adjusted to the correct time as soon as the laptop connects to a time server.

I've already tried troubleshooting using various suggestions online.

In this thread I heard that the Surface Pro 7 has the same issue so I thought I'd file a bug report here after searching (and not finding anything) for this issue.

Here the output of timedatectl:

               Local time: Thu 2024-07-18 10:54:09 JST
           Universal time: Thu 2024-07-18 01:54:09 UTC
                 RTC time: Thu 2024-07-18 01:54:09
                Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

and from hwclock:

hwclock from util-linux 2.40.2
System Time: 1721267821.355448
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 1705941311 seconds after 1969
Last calibration done at 1705941311 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2024/07/18 01:57:02
Hw clock time : 2024/07/18 01:57:02 = 1721267822 seconds since 1969
Time since last adjustment is 15326511 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2024-07-18 10:57:01.360799+09:00

Here is also what is saved in /etc/adjtime:

0.000000 1705941311 0.000000
1705941311
UTC

Environment

• Hardware model: Surface Pro 8
• Kernel version: any recent
• Distribution: any Arch (at least)

[kug1977]

Hi, I face the same issue with Fedora 40 on a Surface 9. The time is off by 125 seconds (and raising) after every restart.

[danielzgtg]

My SP7 regressed in Q4 2023. Not sure why rtc-surface.c was deleted. The correct time is in devtmpfs but not sysfs. This is a pain because I must disable DNSSEC while restarting NTP after boot to get websites to work

[TheSnowfield]

Face the same issue, I guess it's caused these ridiculous charts.

[JJ-82]

Same issue here too.

I'm on a SP8 16/256 running Ubuntu 22.04

[marcelkv]

Same in SP8 kubuntu 24.04 😄

[ryuheechul]

Same for me with SP8 when my other device isn't affected.

In my case (using chrony for NTP), I found an workaround which is making a step for a drift that is bigger than 1 second. I've learnt this method from chrony's offical FAQ.

With this method, my system still boots with a big time difference (~7 hours) but correct itself within few minutes which is good enough automation for me.

Before this workaround I just ran chronyc makestep manually every time I needed the time to be correct (whenever this time difference cause any (weird) issues so that I realize the time is off). But I guess I will be finally free from doing that!

[danielzgtg]

Potential regression of #415.

@qzed Could https://github.com/linux-surface/kernel/blob/b0d746a86e81325ab694bdd8c7396da0226188b4/drivers/rtc/rtc-surface.c be brought back?

[Flameopathic]

same issue on SP7 running NixOS 24.11

[RedIODev]

Same issue on SP7 running Debian 12 Kernel 6.12.3-surface-2 After running hwclock and going into bios the time doesn't match. Meaning hwclock is "lying" and is not actually pulling the time from the bios chip. Also a hwclock -w has no effect on the datetime set in the bios. Updating the datetime in the bios on the other hand changes the time after boot until the timeserver syncs the systemtime (again not writing the difference back to bios)