3 ms·
Yeah, IIRC it really stopped ticking (until you write a valid value at which point it would resume). Note that it doesn't stop reporting the time in this condi
by wyldfire 9y ago
Yeah, IIRC it really stopped ticking (until you write a valid value at which point it would resume).
Note that it doesn't stop reporting the time in this condition it will just give you back all the garbage fields that you wrote before. So an interesting thing happens when the system tries to transform that into a UTC wall clock basis and it usually ends up with a really wild interpretation of the date (decades/centuries off, similar to the problem described in TFA).
- exikyut 9y ago> Yeah, IIRC it really stopped ticking (until you write a valid value at which point it would resume). Ah, okay then. Good to know I can't accidentally thousands of dedicated servers :P (ie, via NTP MITM, writing to hw RTC...) > Note that it doesn't stop reporting the time in this condition it will just give you back all the garbage fields that you wrote before. I don't know why I didn't remember this last night: Linux uses the RTC as a poor-man's NVRAM that will persist across a reboot. Provides <24 bits of data to work with (yay! ...not). https://wiki.ubuntu.com/DebuggingKernelSuspend https://wiki.ubuntu.com/DebuggingKernelSuspend, useful info in https://github.com/torvalds/linux/blob/e34bac726d27056081d0250c0e173e4b155aa340/drivers/base/power/trace.c https://github.com/torvalds/linux/blob/e34bac726d27056081d02... > So an interesting thing happens when the system tries to transform that into a UTC wall clock basis and it usually ends up with a really wild interpretation of the date (decades/centuries off, similar to the problem described in TFA). Right.