[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#782364: Actually, it makes some sense to keep both clocks



Ben Hutchings indicates that his preference would be to disable the non-battery-backed RTC and enable the battery-backed RTC in the kernel for the Cubox-i4pro.

I’m not a kernel hacker, so what I’m about to say may be off the mark, but:

If I’m not mistaken, this kernel is intended to be used on the entire Cubox line of computers.  Only the i4Pro model has the battery-backed RTC available.  The other models do not enable that hardware feature.  So disabling the non-battery-backed RTC would break those models.

I don’t know if it’s possible (without modifications to other packages) to have the battery-backed clock be the one pointed to by /dev/rtc (though that would be nice…).  However, if that’s not possible, I’m willing to configure /etc/default/hwclock as a workaround.

I don’t know whether the two RTCs on the Cubox-i4Pro differ in their properties other than battery-backed-ness — e.g. accuracy, precision, etc… But if they do, that would be an argument in favor of providing both in the kernel.  One may be good for some uses, the other for other uses.

Thanks!
Rick

Reply to: