lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 12 Jun 2014 02:06:46 +0100
From:	John Whitmore <>
To:	John Stultz <>
Cc:	Linux Kernel Mailing List <>,
	Alessandro Zummo <>
Subject: Re: rtc/hctosys.c Problem during kernel boot

On Wed, Jun 11, 2014 at 04:53:55PM -0700, John Stultz wrote:
> On Wed, Jun 11, 2014 at 4:01 PM, John Whitmore <> wrote:
> > I'm having a problem with a DS3234 SPI based RTC chip and rtc/hctosys.c on the
> > 3.10.29 kernel of the RaspberryPi. I'm not sure this is a bug or not but
> > thought I'd ask. I've enabled the kernel config option for HCTOSYS which, on
> > boot, should set the system's date/time to the value read from the RTC. I
> > tried tihs but it would never happen on the RPi. I eventually found in syslog
> > that the kernel boot is attempting to execute the hctosys functionality prior
> > to the SPI being initialised. As a result of this when hctosys is attempted
> > there is not /dev/rtc0 yet. A short time later the DS3234 RTC is initialised
> > but by then it's too late.
> >
> > Once the system has booted and I've logged in I can read and write to the RTC
> > and all seems good but /sys/class/rtc/rtc0/hctosys is '0' indicating that the
> > system time was not set on boot.
> >
> > There is a "deprecated" warning in the syslog coming from the spi of the board
> > file so perhaps that is the cause. So is this a bug? And if so what can I do
> > to resolve it. The hctosys is on a "late_initcall" so not sure of timing.
> Sigh. Yea, this issue was brought up previously, but we never got
> around to a solution that could be merged.
> Basically hctosys is late_init, but if the driver is a module, it
> might not be loaded in time. Adding hooks at module load time when
> RTCs are registered could be done, but then you have the issue that
> userspace might have set the clock via something like ntpdate, so
> HCTOSYS could then cause the clock to be less accurate.
> So we need to make the HCTOSYS functionality happen at RTC register
> time, but it needs to set the clock only if nothing has set the clock
> already. This requires a new timekeeeping interface - something like
> timekeeping_set_time_if_unset(), which atomically would set the time
> if it has never been set.
> You can read some of the previous discussion here:

Thanks a million for that information I'll have a look, as I might try and
resolve the issue.

> I'd be very interested in patches to resolve this!
> thanks
> -john
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists