The following is in my ntpd log. ... 27 Sep 23:06:40 ntpd[3045]: Listening on interface #67 wlan0, fe80::21c:bfff:fe58:3a87#123 Enabled 27 Sep 23:06:49 ntpd[3045]: Listening on interface #68 wlan0, 172.17.2.154#123 Enabled The system is sent to S3 at this point and woken 4 days later. This is how it comes up: 27 Sep 23:07:03 ntpd[3045]: no servers reachable 27 Sep 23:19:54 ntpd[3045]: synchronized to 83.170.1.225, stratum 2 27 Sep 23:19:54 ntpd[3045]: time correction of 306709 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. Roughly 3 and a half days of time missing. I've never seen anything like it before. This is my system. FreeBSD mobileKamikaze.norad 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0 r254957: Tue Aug 27 19:07:40 CEST 2013 root at mobileKamikaze.norad:/usr/obj/HP6510b-9/amd64/usr/src/sys/HP6510b-9 amd64 -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
On Tue, Oct 01, 2013 at 01:12:38PM +0200, Dominic Fandrey wrote:> The system is sent to S3 at this point and woken 4 days later. > > This is how it comes up: > > 27 Sep 23:07:03 ntpd[3045]: no servers reachable > 27 Sep 23:19:54 ntpd[3045]: synchronized to 83.170.1.225, stratum 2 > 27 Sep 23:19:54 ntpd[3045]: time correction of 306709 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. > > Roughly 3 and a half days of time missing. I've never seen anything like > it before. > > This is my system. > FreeBSD [...] 9.2-PRERELEASE FreeBSD [...] amd64Not sure about amd64, but at least on i386, "device pmtimer" is required to be in kernel config for timekeeping while sleeping. ./danfe
On Tue, 1 Oct 2013 13:12:38 +0200, Dominic Fandrey wrote: > The following is in my ntpd log. > > ... > 27 Sep 23:06:40 ntpd[3045]: Listening on interface #67 wlan0, fe80::21c:bfff:fe58:3a87#123 Enabled > 27 Sep 23:06:49 ntpd[3045]: Listening on interface #68 wlan0, 172.17.2.154#123 Enabled > > The system is sent to S3 at this point and woken 4 days later. > > This is how it comes up: > > 27 Sep 23:07:03 ntpd[3045]: no servers reachable > 27 Sep 23:19:54 ntpd[3045]: synchronized to 83.170.1.225, stratum 2 > 27 Sep 23:19:54 ntpd[3045]: time correction of 306709 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. > > Roughly 3 and a half days of time missing. I've never seen anything like > it before. > > This is my system. > FreeBSD mobileKamikaze.norad 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0 r254957: Tue Aug 27 19:07:40 CEST 2013 root at mobileKamikaze.norad:/usr/obj/HP6510b-9/amd64/usr/src/sys/HP6510b-9 amd64 My 9.1 system is (physically) broken at the moment so I only have 8.2 sources to hand, but in any case it looks like the RTC - the only source of clock time available on resume, at least on i386 - was either stopped on suspend when the RTC was updated from system time, or - perhaps more likely? - couldn't be properly read back to restore time on resume. Is there logging of this suspend and resume cycle in /var/log/meesages ? ccing Alexander, resident master of clocks last time I tried following RTC suspend/resume with a view to maybe implementing resume-on-alarm. cheers, Ian