Re: CONFIG_RTC_HCTOSYS lost on x86 with ALWAYS_USE_PERSISTENT_CLOCKchanges?

[Jason Gunthorpe]

On Thu, Apr 25, 2013 at 12:54:15PM -0700, John Stultz wrote:

> That said, I suspect we need RTC equivalents to the xen/kvm/vrtc
> logic in the x86 persistent_clock code before we'll be able to tear
> out the persistent_clock code (I think just cmos and efi have RTC
> drivers).

Aha! Maybe this is why my Xen servers always seem to have the wrong
time in the RTC :)

I'm not sure what is going on with Xen, my Xenserver installs have a
/sys/class/rtc/rtc0 in dom0 which is rtc_cmos (bound via a PNP device),
but the Xen platform code seem to route dom0 set_wallclock to a
hypervisor call.. So, like on normal x86, not sure why userspace and
NTP auto-sync use different code.

I have a feeling the set_wallclock method doesn't actually work,
because I have had several hard crashes on Xensever boxes over the
years and the RTC was always wrong on reboot, this suggests to me the
NTP update of the RTC via set_wallclock perhaps is not working..

Xen Folks: If xen_set_wallclock is bogus, or if using the set method
via in rtc_cmos is OK, please return -ENODEV from dom0
xen_set_wallclock and rely on the new CONFIG_RTC_SYSTOHC path for NTP
synchronization.

I wonder if arch/x86/platform/mrst/vrtc.c and rtc-mrst.c are the same
thing?

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/