Hi J, I tried appplying your patches and got into some problems: > Applying: hwclock: hctosys drift compensation II > error: patch failed: sys-utils/hwclock.c:807 > error: sys-utils/hwclock.c: patch does not apply I tried that both upon origin/master and upon fb2ba06, which you seem to have based your first patch on. Here's the list of patches I was trying to apply: > [PATCH 1/2] hwclock: hctosys drift compensation > [PATCH 2/2] hwclock: hctosys drift compensation man page > [PATCH 1/7] hwclock: hctosys drift compensation II > [PATCH 2/7] hwclock: hctosys drift compensation II COMMENTS > [PATCH 3/7] hwclock: hctosys drift compensation II MAN > [PATCH 4/7] hwclock: persistent_clock_is_local > [PATCH 5/7] hwclock: persistent_clock_is_local MAN > [PATCH 6/7] hwclock: Add --update option > [PATCH 7/7] hwclock: Add --update option MAN Did I overlook a patch somewhere? 2014-10-07 17:50 GMT+02:00 JWP <elseifthen@xxxxxxx>: > > On 10/07/2014 08:48 AM, Noé RUBINSTEIN wrote: >>> Sure, hwclock already has the ability to track the offset between the >>> Hardware Clock and the System Clock(which presumably is the 'correct' time). >> ...but this information is recorded only when setting the hardware >> clock, which is impossible on some (arguably buggy) targets. > > Are you sure that drift factor (re)calculation does not happen if > writing the Hardware Clock fails? I just had a quick look at the > code and it seem that we do not test to see if write fails. So > (re)calculation might work as is? -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
