On Wed, Dec 11, 2019 at 05:42:12PM +0100, Miroslav Lichvar wrote:
> On Wed, Dec 11, 2019 at 04:13:23PM +0100, Christian Ehrhardt wrote:
> > That means the first switch_interrupts call from RTC_Initialise ->
> > RTC_Linux_Initialise -> switch_interrupts has on_off=0 and that doesn't
> > trigger the
On Wed, Dec 11, 2019 at 5:42 PM Miroslav Lichvar
wrote:
> On Wed, Dec 11, 2019 at 04:13:23PM +0100, Christian Ehrhardt wrote:
> > That means the first switch_interrupts call from RTC_Initialise ->
> > RTC_Linux_Initialise -> switch_interrupts has on_off=0 and that doesn't
> > trigger the issue
On Wed, Dec 11, 2019 at 04:13:23PM +0100, Christian Ehrhardt wrote:
> That means the first switch_interrupts call from RTC_Initialise ->
> RTC_Linux_Initialise -> switch_interrupts has on_off=0 and that doesn't
> trigger the issue at initialization phase.
> Later on on RTC_TimeInit ->
On Wed, Dec 11, 2019 at 4:24 PM Vincent Blut wrote:
> On 2019-12-11T16:13+0100, Christian Ehrhardt wrote:
> >On Tue, Dec 10, 2019 at 5:59 PM Miroslav Lichvar
> >wrote:
> >
> >> On Tue, Dec 10, 2019 at 04:25:31PM +0100, Christian Ehrhardt wrote:
> >> > On Tue, Dec 10, 2019 at 4:19 PM Miroslav
On 2019-12-11T16:13+0100, Christian Ehrhardt wrote:
On Tue, Dec 10, 2019 at 5:59 PM Miroslav Lichvar
wrote:
On Tue, Dec 10, 2019 at 04:25:31PM +0100, Christian Ehrhardt wrote:
> On Tue, Dec 10, 2019 at 4:19 PM Miroslav Lichvar
> > I'm sorry for changing my mind, but I now think this case
On Tue, Dec 10, 2019 at 5:59 PM Miroslav Lichvar
wrote:
> On Tue, Dec 10, 2019 at 04:25:31PM +0100, Christian Ehrhardt wrote:
> > On Tue, Dec 10, 2019 at 4:19 PM Miroslav Lichvar
> > > I'm sorry for changing my mind, but I now think this case should be
> > > handled gracefully in chronyd and
On Tue, Dec 10, 2019 at 04:25:31PM +0100, Christian Ehrhardt wrote:
> On Tue, Dec 10, 2019 at 4:19 PM Miroslav Lichvar
> > I'm sorry for changing my mind, but I now think this case should be
> > handled gracefully in chronyd and not avoided in the test. According
> > to the man page, the -s
On Tue, Dec 10, 2019 at 4:19 PM Miroslav Lichvar
wrote:
> On Tue, Dec 10, 2019 at 04:11:14PM +0100, Christian Ehrhardt wrote:
> > On Tue, Dec 10, 2019 at 4:06 PM Vincent Blut
> wrote:
> > > >+hwclock -r --test | grep -q '^ioctl.*RTC_UIE_ON.*Invalid argument$'
> &&
> > > test_skip "RTC not
On Tue, Dec 10, 2019 at 04:11:14PM +0100, Christian Ehrhardt wrote:
> On Tue, Dec 10, 2019 at 4:06 PM Vincent Blut wrote:
> > >+hwclock -r --test | grep -q '^ioctl.*RTC_UIE_ON.*Invalid argument$' &&
> > test_skip "RTC not RTC_UIE_ON capable"
> >
> >
On Tue, Dec 10, 2019 at 4:06 PM Vincent Blut wrote:
> On 2019-12-10T15:52+0100, Christian Ehrhardt wrote:
> >The test might run on different platforms.
> >If the platform happens to have a RTC that does exist but unable to
> >have RTC_UIE_ON set the test will fall into an infinite hang.
> >
>
On 2019-12-10T15:52+0100, Christian Ehrhardt wrote:
The test might run on different platforms.
If the platform happens to have a RTC that does exist but unable to
have RTC_UIE_ON set the test will fall into an infinite hang.
Exampls of bad clocks are:
- ppc64el: rtc-generic
- arm64: rtc-efi
To
11 matches
Mail list logo