On Fri, Oct 16, 2015 at 12:54:51PM +0200, Heiko Carstens wrote:
> > > So you are saying this works on x86 and it must be some s390 specific bug?
> >
> > Looks like. I have no idea why that would break on s390. Did you try
> > to revert the commit on top of tree?
>
> Reverting the patch isn't easy due to all the dependencies the code has in
> the meantime. However the following code snippet does logically revert the
> patch and it works again:
>
> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> index 3739ac6aa473..c97dd1cc9bd5 100644
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -1953,12 +1953,10 @@ ktime_t ktime_get_update_offsets_now(unsigned int
> *cwsseq, ktime_t *offs_real,
> nsecs = timekeeping_get_ns(&tk->tkr_mono);
> base = ktime_add_ns(base, nsecs);
>
> - if (*cwsseq != tk->clock_was_set_seq) {
> - *cwsseq = tk->clock_was_set_seq;
> - *offs_real = tk->offs_real;
> - *offs_boot = tk->offs_boot;
> - *offs_tai = tk->offs_tai;
> - }
> + *cwsseq = tk->clock_was_set_seq;
> + *offs_real = tk->offs_real;
> + *offs_boot = tk->offs_boot;
> + *offs_tai = tk->offs_tai;
Adding the patch below also "fixes" this. Right now I don't see why this
could architecture specific. Hmm.
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 3739ac6aa473..75771b15647c 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1835,7 +1835,7 @@ void update_wall_time(void)
* memcpy under the tk_core.seq against one before we start
* updating.
*/
- timekeeping_update(tk, clock_set);
+ timekeeping_update(tk, clock_set | TK_CLOCK_WAS_SET);
memcpy(real_tk, tk, sizeof(*tk));
/* The memcpy must come last. Do not put anything here! */
write_seqcount_end(&tk_core.seq);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
