Hello, [I repaired the quoting style and expanded To: a bit] On Sun, Sep 29, 2019 at 07:36:27PM +0000, John Blake wrote: > On Saturday, September 28, 2019, 3:52:11 PM MDT, Rick Thomas <rbthomas@pobox.com> wrote: > > On Sep 28, 2019, at 1:14 PM, John Blake <blakejoh@yahoo.com> wrote: > > > > > > After upgrading my Sheevaplug from Stretch to Buster, it would not > > > set the system time from the RTC at boot. Here is what I see in > > > dmesg output: > > > > > > (kernel 4.19.67-2+deb10u1) > > > # dmesg | grep rtc > > > [ 2.088797] hctosys: unable to open rtc device (rtc0) > > > [ 2.535171] rtc-mv f1010300.rtc: rtc core: registered f1010300.rtc as rtc0 > > > > > > This results in the system time being way off until after NTP starts and syncs. > > > > > > If I revert to the kernel from Stretch, it works fine: > > > > > > (kernel 4.9.168-1+deb9u5) > > > # dmesg | grep rtc > > > [ 2.205994] rtc-mv f1010300.rtc: rtc core: registered f1010300.rtc as rtc0 > > > [ 2.238801] rtc-mv f1010300.rtc: setting system clock to 2019-09-07 22:51:49 UTC (1567896709) > > > > > > Does anyone know if there is a fix or workaround for this? I > > > searched the web for this problem and found where someone (on > > > archlinux) had a similar problem, his workaround being to change > > > kernel .config "CONFIG_RTC_DRV_CMOS=m" to "CONFIG_RTC_DRV_CMOS=y" > > > and compile a custom kernel. It seems to me there should be a > > > simpler solution. > > > > I do not have this problem on my sheevaplug running kernel > > ‘4.19.67-2’ . I see that ‘4.19.67-2+deb10u1’ is available, but not 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. 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). Best regards Uwe [1] https://salsa.debian.org/kernel-team/linux/commit/d192eb755516d1ad2a6edda3cfc61e288fbb365f>
Attachment:
signature.asc
Description: PGP signature