3 ms·

> Many RTCs decide not to tick anymore when that happens. Of course I laughed when I read that, but then I realized I was interpreting that line to mean "it de

> Many RTCs decide not to tick anymore when that happens. Of course I laughed when I read that, but then I realized I was interpreting that line to mean "it declares shenanigans and stops reporting time so you realize something broke." Just wanted to clarify - do you mean the above, or "of course software cannot kill hardware!!1" "won't tick anymore"?

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.

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.