> On Sep 29, 2019, at 1:05 PM, Uwe Kleine-König <u...@kleine-koenig.org> wrote:
>
> The step from 4.19.67-2 to 4.19.67-2+deb10u1 is harmless for this
> problem. The issue that John is describing comes from a change by Roger
> Shimizu to reduce the kernel size[1]. I guess there is some difference
> in userspace that is relevant for the problem not occuring for Rick.
> https://bugs.debian.org/855203 seems relevant here.
>
>>> yet installed on this machine. I think I’ll hold off on installing
>>> that update for a while!
>>>
>>> And, FWIW:
>>>
>>> rbthomas@sheeva:~$ grep RTC_DRV_CMOS /boot/config-4.19.0-6-marvell
>>> CONFIG_RTC_DRV_CMOS=m
>
> Note that CONFIG_RTC_DRV_CMOS isn't relevant for the Sheevaplug. The
> relevant symbol is CONFIG_RTC_DRV_MV there.
So here’s what I get for that:
rbthomas@sheeva:~$ grep RTC_DRV_MV /boot/config-4.19.0-6-marvell
CONFIG_RTC_DRV_MV=m
> I wonder if it would be sensible to implement the logic for hctosys
> (the "during boot" part that is) in rtc_register instead. This way it
> would not trigger to early if the relevant driver was modular (as is the
> case here).
Could you fill in the details a bit more here? I assume this is something to
do with the systemd way of initializing the system, which I’m afraid I don’t
understand as well as I probably should… please forgive my ignorance!
In particular, where/when is the “hwclock hctosys” being done during boot
currently? And where/when would it be done under your proposal?
And, finally, would the suggested change work for other types of hardware than
armel?
Thanks for your help!
Rick
