linux-rtc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oliver Hartkopp <socketcan@hartkopp.net>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>
Cc: 932845@bugs.debian.org, linux-rtc@vger.kernel.org
Subject: Re: Bug#932845: TS-219 RTC issue with Debian Buster
Date: Fri, 26 Jul 2019 11:27:11 +0200	[thread overview]
Message-ID: <ec38f0ea-2113-5054-b98a-a4798eb61c82@hartkopp.net> (raw)
In-Reply-To: <20190726072759.uxx7i2hrl5qr4oux@pengutronix.de>

Hello Uwe,

On 26.07.19 09:27, Uwe Kleine-König wrote:
> Hello Alexandre,
> 
> On Thu, Jul 25, 2019 at 04:31:49PM +0200, Oliver Hartkopp wrote:
>> On 24.07.19 09:07, Uwe Kleine-König wrote:
>>> On Tue, Jul 23, 2019 at 10:28:18PM +0200, Oliver Hartkopp wrote:
>>>> I'm running a TS-119P+ and a TS-219P II Qnap NAS with Debian Buster.
>>>> Both are now running a linux-image-4.19.0-5-marvell kernel.
>>>>
>>>> But since my update from Linux 4.9 (Stretch) to Linux 4.19 (Buster) the
>>>> hardware clock of both boxes refuse to work.
>>>>
>>>> After some digging in kernel sources and re-installing Linux 4.9 on my
>>>> Buster setup it turns out, that a change in the kernel config causes the
>>>> problem:
>>>>
>>>> 4.19.0-5-marvell -> CONFIG_RTC_DRV_S35390A=m   (fails)
>>>>
>>>> 4.9.0-4-marvell -> CONFIG_RTC_DRV_S35390A=y    (works)
>>>>
>>>> See details and solving process at:
>>>>
>>>> https://marc.info/?l=linux-arm-kernel&m=156390875629259&w=2
>>>>
>>>> Can you please revert the Kernel config parts for the RTC in a way that the
>>>> RTC drivers are built into the marvell-arch kernel again instead of building
>>>> them as modules?
>>>
>>> They were switched to modules because the kernel image got too big to
>>> fit into the flash storage of some machines. I assume when we switch to
>>> built-in again the resulting problem is the bigger one.
>>
>> I don't know which is the bigger problem here.
>>
>> When the rtc driver is built as module it can not be operated with the
>> hwclock tool from the util-linux package due to the missing rtc UIE support.
>>
>> You finally have no hardware clock on these machines and must wait for ntp
>> to shift time and date (my system always starts in February until ntp fixes
>> the time).
> 
> For me it's obvious what is the bigger problem. Either you don't have
> the correct time until ntp fixes it up for you, or others cannot install
> a kernel update and so run a vulnerable OS.

That what I've written, NTP fixes the time for me. I have no problem 
with updating my kernels - in fact I was even able to flash an older 
kernel to figure out this rtc issue :-)

>> Maybe this problem is only relevant for the S35390A and PCF8563 chip which
>> both lack the UIE support needed by hwclock. Both have only alarm triggers
>> in a minute accuracy according to the driver source code.
> 
> AFAIK the rtc framework should then emulate this event somehow.

I don't think so. When the rtc chip is not able to trigger an event with 
a one second resolution - how can you emulate that?

>> So CONFIG_RTC_DRV_S35390A=y and CONFIG_RTC_DRV_PCF8563=y should bring back
>> the hw clocks on these machines.
>>
>> I assume using hwclock without UIE trigger code will impact the accuracy.
>>
>>>> As described in the referenced description the hwclock tool does not work on
>>>> the machines.
>>>
>>> I'm not sure yet if this is a problem in hwclock() or the s35390a
>>> driver.
>>
>> In detail it is hwclock together with rtc drivers not supporting UIE trigger
>> with a 1 second resolution.
> 
> @abelloni: Do you can shed some light here, how it is supposed to work?
> Is hwclock just doing it wrong with non-PC clocks, or is there a kernel
> bug to fix?
> 
> Best regards
> Uwe
> 

Best regards,
Oliver

  reply	other threads:[~2019-07-26  9:27 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <9992cfcd-e51b-e002-4843-b16da8e2e119@hartkopp.net>
     [not found] ` <20190724070704.GA5983@taurus.defre.kleine-koenig.org>
     [not found]   ` <806117df-54ac-88f2-06a0-20a7502202ff@hartkopp.net>
2019-07-26  7:27     ` Bug#932845: TS-219 RTC issue with Debian Buster Uwe Kleine-König
2019-07-26  9:27       ` Oliver Hartkopp [this message]
2019-07-26  9:39         ` Alexandre Belloni
2019-07-26 10:26           ` Oliver Hartkopp
2019-07-26 10:53             ` Oliver Hartkopp
2019-07-26 18:12               ` Trent Piepho
2019-07-26 19:09                 ` Oliver Hartkopp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ec38f0ea-2113-5054-b98a-a4798eb61c82@hartkopp.net \
    --to=socketcan@hartkopp.net \
    --cc=932845@bugs.debian.org \
    --cc=alexandre.belloni@bootlin.com \
    --cc=linux-rtc@vger.kernel.org \
    --cc=u.kleine-koenig@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).