linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* "systemd[1]: Failed to apply local time delta" with v4.7-rc1
@ 2016-05-30 14:13 Mika Westerberg
  2016-05-31 18:24 ` John Stultz
  0 siblings, 1 reply; 2+ messages in thread
From: Mika Westerberg @ 2016-05-30 14:13 UTC (permalink / raw)
  To: Baolin Wang; +Cc: John Stultz, linux-kernel

Hi,

I noticed that when I boot my Lenovo Yoga 900 with v4.7-rc1 I get
following error from systemd:

  systemd[1]: Failed to apply local time delta, ignoring: Invalid argument

and my system time is left being 180 minutes off.

With following commits reverted it works fine:

  86d3473224b0 time: Introduce do_sys_settimeofday64()
  457db29bfcfd security: Introduce security_settime64()

and systemd prints:

  systemd[1]: RTC configured in localtime, applying delta of 180 minutes to system time.

>From systemd source code it seems to use Linux specific feature to "warp" the
system clock according the timezone passed in:

  clock_set_timezone() {
	const struct timeval *tv_null = NULL;

	...

	/*
	 * If the RTC does not run in UTC but in local time, the very first
	 * call to settimeofday() will set the kernel's timezone and will warp the
	 * system clock, so that it runs in UTC instead of the local time we
	 * have read from the RTC.
	 */
	if (settimeofday(tv_null, &tz) < 0)
		return -errno;
	if (min)
		*min = minutesdelta;

With commit 86d3473224b0 it seems that do_sys_settimeofday() started returning
-EINVAL when tv is NULL which seems to break the above.

Is this intentional or am I missing something?

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: "systemd[1]: Failed to apply local time delta" with v4.7-rc1
  2016-05-30 14:13 "systemd[1]: Failed to apply local time delta" with v4.7-rc1 Mika Westerberg
@ 2016-05-31 18:24 ` John Stultz
  0 siblings, 0 replies; 2+ messages in thread
From: John Stultz @ 2016-05-31 18:24 UTC (permalink / raw)
  To: Mika Westerberg; +Cc: Baolin Wang, lkml

On Mon, May 30, 2016 at 7:13 AM, Mika Westerberg
<mika.westerberg@linux.intel.com> wrote:
> Hi,
>
> I noticed that when I boot my Lenovo Yoga 900 with v4.7-rc1 I get
> following error from systemd:
>
>   systemd[1]: Failed to apply local time delta, ignoring: Invalid argument
>
> and my system time is left being 180 minutes off.
>
> With following commits reverted it works fine:
>
>   86d3473224b0 time: Introduce do_sys_settimeofday64()
>   457db29bfcfd security: Introduce security_settime64()
>
> and systemd prints:
>
>   systemd[1]: RTC configured in localtime, applying delta of 180 minutes to system time.
>
> From systemd source code it seems to use Linux specific feature to "warp" the
> system clock according the timezone passed in:
>
>   clock_set_timezone() {
>         const struct timeval *tv_null = NULL;
>
>         ...
>
>         /*
>          * If the RTC does not run in UTC but in local time, the very first
>          * call to settimeofday() will set the kernel's timezone and will warp the
>          * system clock, so that it runs in UTC instead of the local time we
>          * have read from the RTC.
>          */
>         if (settimeofday(tv_null, &tz) < 0)
>                 return -errno;
>         if (min)
>                 *min = minutesdelta;
>
> With commit 86d3473224b0 it seems that do_sys_settimeofday() started returning
> -EINVAL when tv is NULL which seems to break the above.
>
> Is this intentional or am I missing something?

:(
No, that wasn't intentional. Thanks for the report. I'll try to sort
it out here shortly.

thanks
-john

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2016-05-31 18:24 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-30 14:13 "systemd[1]: Failed to apply local time delta" with v4.7-rc1 Mika Westerberg
2016-05-31 18:24 ` John Stultz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).