Re: [chrony-dev] Re: Are there known issues in destructive tests on arm64 or ppc64

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-dev Archives ]




On Mon, Dec 9, 2019 at 1:46 PM Vincent Blut <vincent.debian@xxxxxxx> wrote:
Hi,

On 2019-12-09T12:00+0100, Christian Ehrhardt wrote:
>On Fri, Dec 6, 2019 at 7:19 PM Vincent Blut <vincent.debian@xxxxxxx> wrote:
>
>> On 2019-12-06T16:55+0100, Vincent Blut wrote:
>> >On 2019-12-06T10:21+0100, Christian Ehrhardt wrote:
>> >>Hi chrony-dev,
>> >>chrony is tested in Debian/Ubuntu on any update of related packages
>> >>and while that was running I found that arm64 and ppc64 reproducibly
>> >>hang [1][2]. OTOH arm64 and s390x reproducibly work.
>> >
>> >By the way, I just gave it a shot on an arm64 VM and the rtc test
>> >passed flawlessly. Note that this VM is powered by Linux 4.19.x.
>> >I will soon run that test with a more recent kernel.
>>
>> I still can’t reproduce the issue on an updated Debian unstable arm64 VM:
>>
>
>My manual testing was on ppc64el, I only knew arm64 was affected from the
>runs at autopkgtest.ubuntu.com.
>Since you tried arm64 first I spun up a VM myself.

I think I will have access to a ppc64el system this week. We’ll see if I
can reproduce this.

Hope your ppc64 isn't different than mine, as it turns out our ARM VMs are :-/. 

>The ppc64 system had 5.2.0-8-generic, this one now has 5.3.0-24-generic..
>I ran it again against the chrony master tarball with just the minimal
>setting I mentioned before:
>
>$ cat ~/chronyd.conf
>rtcfile /root/rtcfile
>$ cat /root/rtcfile
>1 1575623140 0.0 0.0
># ./chronyd -f /root/chronyd.conf -s -d
>2019-12-09T10:58:13Z chronyd version DEVELOPMENT starting (+CMDMON +NTP
>+REFCLOCK +RTC +PRIVDROP -SCFILTER -SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG)
>2019-12-09T10:58:14Z System time set from RTC
>2019-12-09T10:58:14Z Initial frequency -10.245 ppm
>2019-12-09T10:58:14Z Could not enable RTC interrupt : Invalid argument
><hang>

I wonder if the RTC driver in use on your system is able to handle
RTC_UIE_{ON,OFF} ioctl requests.

>All other symptoms (e.g. the defunct proc if running without -d and so on)
>are the same on this arm64 system.
>
>Just to check a bit of the rtc-config on those VMs between our cases:
># ll /dev/rtc*
>lrwxrwxrwx 1 root root      4 Dec  9 10:42 /dev/rtc -> rtc0
>crw------- 1 root root 248, 0 Dec  9 10:42 /dev/rtc0
># dmesg | grep rtc
>[    0.905564] rtc-efi rtc-efi: registered as rtc0
>[    1.082957] rtc-efi rtc-efi: setting system clock to 2019-12-09T10:41:00
>UTC (1575888060)

Ok, so I checked this driver’s code [1], and it doesn’t seem to be able
to handle the aforementioned ioctl requests:

rtc->uie_unsupported = 1;

It would interesting to know if you can reproduce this issue by enabling
the CONFIG_RTC_INTF_DEV_UIE_EMUL kernel module.
 
I have tried and built such a kernel, but the VM doesn't come up with it.
And since this is a cloud I don't have much control about early boot and such to debug fix it :-/

I have also tried to recreate this on x86 with a trick like:
  $ firejail --shell=none --noprofile --seccomp.drop=ioctl:EINVAL  ./chronyd -x -f /root/chronyd.conf -s -d

While I get a similar message
2019-12-10T10:25:42Z Could not enable RTC interrupt : Invalid argument

It does not hang in that mode, so that isn't a good test either.

Still failing with the default Ubuntu arm64 and ppc64el test VM environments ....

FWIW, my arm64 VM uses the rtc-pl031 driver.

Cheers,
Vincent


--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/