At Sun, 14 Jul 2024 12:45:49 -0700, "Greg A. Woods" <woods%planix.ca@localhost> wrote: Subject: Re: annual howto rampage > > At Thu, 11 Jul 2024 15:46:01 -0400, Greg Troxel <gdt%lexort.com@localhost> wrote: > Subject: annual howto rampage > > > > - Are there any problems with 4.18 (other than timekeeping)? > > I've seen the odd reboot (two, exactly, one on each machine) from the > Xen kernel watchdog firing for no apparent reason. > > Well I guess the reason is the NetBSD dom0 kernel locked up hard enough > that it didn't tickle Xen any more, but there was no evidence on the > console: > > [Fri Jul 12 06:57:25 2024][ 660210.6923526] xen_rtc_set: Setting to 1720792646.009459000 s at systime 660180665194637 ns (nanouptime: 660210692352600 ns, diff(st-nt): -30.27157963 s) > [Fri Jul 12 07:06:16 2024][ 660739.8322481] xen_rtc_set: Setting to 1720793175.149355000 s at systime 660710772767673 ns (nanouptime: 660739832824235 ns, diff(st-nt): -29.60056562 s) > [Fri Jul 12 07:14:41 2024](XEN) [2024-07-12 14:14:39.928] Watchdog timer fired for domain 0 > [Fri Jul 12 07:14:41 2024](XEN) [2024-07-12 14:14:39.928] Hardware Dom0 shutdown: watchdog rebooting machine > > The first column of timestamps is from conserver. There would have been > another of those xen_rtc_set messages at about 07:15:05 I think (another > ~530 seconds) so no clue there.... (and /var/log/kern was entirely lost > in the crash it seems) BTW, this is just evidence of the timekeeping regression -- the evidence was indeed right there in the console output in the two xen_rtc_set lines: the diff value normally never drops in magnitude. I.e. time was suddenly sluing so quickly that xwatchdogd couldn't work. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpfgOjf7df5X.pgp
Description: OpenPGP Digital Signature