/sys/boot compile broken
SVN for HEAD source at 324810. Compiling /sys/boot is totally screwed up. The failure is that geliboot.c cannot be found. This prevents a successful ``make buildworld''. This error occurs despite the fact that I have LOADER_NO_GELI_SUPPORT set to yes in src.conf. Looking at the various Makefiles this option is supposed to prevent using GELI. Even if the user wanted to use GELI the compile of the boot code would probably fail. imp@ has had his fingers in the boot code lately. -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: host, bhyve vm and ntpd
On Fri, 2017-10-20 at 21:15 +0300, Boris Samorodov wrote: > 20.10.2017 21:04, Ian Lepore пишет: > > > > On Fri, 2017-10-20 at 20:20 +0300, Boris Samorodov wrote: > > > > > > (CC to freebsd-virtualization@) > > > > > > 20.10.2017 19:32, Ian Lepore пишет: > > > > > > > > > > > > On Fri, 2017-10-20 at 18:36 +0300, Boris Samorodov wrote: > > > > > > > > > > > > > > > 20.10.2017 18:31, Boris Samorodov пишет: > > > > > > > > > > > > > > > > > > > > > > > > 20.10.2017 18:12, Ian Lepore пишет: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, 2017-10-20 at 14:46 +0300, Boris Samorodov wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > I have got a host: > > > > > > > > --- > > > > > > > > bhyve-host% uname -a > > > > > > > > FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: > > > > > > > > Fri Aug > > > > > > > > 25 05:25:26 MSK 2017 > > > > > > > > bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FAST amd64 > > > > > > > > amd64 > > > > > > > > --- > > > > > > > > > > > > > > > > And a bhyve vm: > > > > > > > > --- > > > > > > > > bhyve-vm: uname -a > > > > > > > > FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 > > > > > > > > r324782: Fri > > > > > > > > Oct 20 05:12:17 MSK 2017 > > > > > > > > bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X amd64 amd64 > > > > > > > > --- > > > > > > > > > > > > > > > > The only difference at kernel configs is a colored console. :-) > > > > > > > > > > > > > > > > And here I get some weird (is it?) result at the VM (I expect > > > > > > > > ntpd to be > > > > > > > > more stable): > > > > > > > > --- > > > > > > > > bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done > > > > > > > > remote refid st t when poll reach delay > > > > > > > > offset > > > > > > > > jitter > > > > > > > > == > > > > > > > > XX.XX.XX.1 XX.XX.XX.245 4 u9 6430.605 > > > > > > > > -1.202 > > > > > > > > 316.407 > > > > > > > > XX.XX.XX.1 XX.XX.XX.245 4 u7 6470.605 > > > > > > > > -1.202 > > > > > > > > 358.395 > > > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u5 64 170.615 > > > > > > > > -328.42 > > > > > > > > 181.405 > > > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u3 64 370.615 > > > > > > > > -328.42 > > > > > > > > 214.868 > > > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 67 64 370.615 > > > > > > > > -328.42 > > > > > > > > 214.868 > > > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 63 64 770.615 > > > > > > > > -328.42 > > > > > > > > 268.618 > > > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 60 64 1770.615 > > > > > > > > -328.42 > > > > > > > > 333.175 > > > > > > > > XX.XX.XX.1 .STEP. 16 u 1910 6400.000 > > > > > > > > 0.000 > > > > > > > > 0.000 > > > > > > > > XX.XX.XX.1 XX.XX.XX.245 4 u 27 6410.703 > > > > > > > > -262.63 > > > > > > > > 0.004 > > > > > > > > XX.XX.XX.1 XX.XX.XX.245 4 u 31 6410.649 > > > > > > > > -331.43 > > > > > > > > 68.800 > > > > > > > > --- > > > > > > > > > > > > > > > > At the same time host's results are very stable: > > > > > > > > --- > > > > > > > > bhyve-host% for t in `jot 10`; do ntpq -pn; sleep 64; done > > > > > > > > remote refid st t when poll reach delay > > > > > > > > offset > > > > > > > > jitter > > > > > > > > == > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u1 6410.401 > > > > > > > > 0.176 > > > > > > > > 0.106 > > > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u6 6430.401 > > > > > > > > 0.176 > > > > > > > > 0.459 > > > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u3 6470.401 > > > > > > > > 0.176 > > > > > > > > 0.940 > > > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 67 6470.401 > > > > > > > > 0.176 > > > > > > > > 0.940 > > > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 64 64 170.401 > > > > > > > > 0.176 > > > > > > > > 1.566 > > > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 60 64 370.448 > > > > > > > > 1.275 > > > > > > > > 1.739 > > > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 55 64 770.448 > > > > > > > > 1.275 > > > > > > > > 2.365 > > > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 53 64 1770.448 > > > > > > > > 1.275 > > > > > > > > 3.110 > > > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 50 64 3770.448 > > > > > > > > 1.275 > > > > > > > > 3.929 > > > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 45 64 3770.443 > > > > > > > > 8.750 > > > > > > > > 4.722 > > > > > > > > ---
Re: host, bhyve vm and ntpd
20.10.2017 21:04, Ian Lepore пишет: > On Fri, 2017-10-20 at 20:20 +0300, Boris Samorodov wrote: >> (CC to freebsd-virtualization@) >> >> 20.10.2017 19:32, Ian Lepore пишет: >>> >>> On Fri, 2017-10-20 at 18:36 +0300, Boris Samorodov wrote: 20.10.2017 18:31, Boris Samorodov пишет: > > > 20.10.2017 18:12, Ian Lepore пишет: >> >> >> On Fri, 2017-10-20 at 14:46 +0300, Boris Samorodov wrote: >>> >>> >>> Hi All, >>> >>> I have got a host: >>> --- >>> bhyve-host% uname -a >>> FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: Fri Aug >>> 25 05:25:26 MSK 2017 >>> bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FAST amd64 amd64 >>> --- >>> >>> And a bhyve vm: >>> --- >>> bhyve-vm: uname -a >>> FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 r324782: Fri >>> Oct 20 05:12:17 MSK 2017 >>> bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X amd64 amd64 >>> --- >>> >>> The only difference at kernel configs is a colored console. :-) >>> >>> And here I get some weird (is it?) result at the VM (I expect ntpd to be >>> more stable): >>> --- >>> bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done >>> remote refid st t when poll reach delay offset >>> jitter >>> == >>> XX.XX.XX.1 XX.XX.XX.245 4 u9 6430.605 -1.202 >>> 316.407 >>> XX.XX.XX.1 XX.XX.XX.245 4 u7 6470.605 -1.202 >>> 358.395 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u5 64 170.615 -328.42 >>> 181.405 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u3 64 370.615 -328.42 >>> 214.868 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u 67 64 370.615 -328.42 >>> 214.868 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u 63 64 770.615 -328.42 >>> 268.618 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u 60 64 1770.615 -328.42 >>> 333.175 >>> XX.XX.XX.1 .STEP. 16 u 1910 6400.0000.000 >>> 0.000 >>> XX.XX.XX.1 XX.XX.XX.245 4 u 27 6410.703 -262.63 >>> 0.004 >>> XX.XX.XX.1 XX.XX.XX.245 4 u 31 6410.649 -331.43 >>> 68.800 >>> --- >>> >>> At the same time host's results are very stable: >>> --- >>> bhyve-host% for t in `jot 10`; do ntpq -pn; sleep 64; done >>> remote refid st t when poll reach delay offset >>> jitter >>> == >>> >>> >>> >>> *XX.XX.XX.1 XX.XX.XX.245 4 u1 6410.4010.176 >>> 0.106 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u6 6430.4010.176 >>> 0.459 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u3 6470.4010.176 >>> 0.940 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u 67 6470.4010.176 >>> 0.940 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u 64 64 170.4010.176 >>> 1.566 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u 60 64 370.4481.275 >>> 1.739 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u 55 64 770.4481.275 >>> 2.365 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u 53 64 1770.4481.275 >>> 3.110 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u 50 64 3770.4481.275 >>> 3.929 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u 45 64 3770.4438.750 >>> 4.722 >>> --- >>> >>> The network is organized via bridge -- host igb and vm tap interfaces >>> are members of one bridge. >>> >>> Are those results expected? Does it smell like a bug? Should I dig >>> furter? >>> >> So it is repeatedly stepping the clock in the VM? (Set >> kern.timecounter.stepwarnings=1 to log steps). > No kernel/ntpd messages for 20 minutes after setting this sysctl. > >> >> >> That is usually a sign >> that the chosen timecounter is running at a different frequency than it >> claimed to be when it registered itself -- the host may not be >> emulating the timer hardware properly in the guest. What is the output >> of sysctl kern.timecounter in the vm? > --- > bhyve-vm% sysctl kern.timecounter > > kern.timecounter.tsc_shift: 1 > kern.timecounter.smp_tsc_adjust: 0 > kern.timecounter.smp_tsc: 0 > kern.timecounter.invariant_tsc: 1 > kern.timecounter.fast_gettime: 1 > kern.timecounter.tick: 1 > kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(-100) > dummy(-100) > kern.timecounter.hardware: HPET > kern.timecounter.alloweddeviation: 5 > kern.timecounter.stepwarnings: 1 > kern.timecounter.tc.ACPI-fast.quality: 900 > kern.timecounter.tc
Re: host, bhyve vm and ntpd
On Fri, 2017-10-20 at 20:20 +0300, Boris Samorodov wrote: > (CC to freebsd-virtualization@) > > 20.10.2017 19:32, Ian Lepore пишет: > > > > On Fri, 2017-10-20 at 18:36 +0300, Boris Samorodov wrote: > > > > > > 20.10.2017 18:31, Boris Samorodov пишет: > > > > > > > > > > > > 20.10.2017 18:12, Ian Lepore пишет: > > > > > > > > > > > > > > > On Fri, 2017-10-20 at 14:46 +0300, Boris Samorodov wrote: > > > > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > I have got a host: > > > > > > --- > > > > > > bhyve-host% uname -a > > > > > > FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: Fri > > > > > > Aug > > > > > > 25 05:25:26 MSK 2017 > > > > > > bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FAST amd64 amd64 > > > > > > --- > > > > > > > > > > > > And a bhyve vm: > > > > > > --- > > > > > > bhyve-vm: uname -a > > > > > > FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 > > > > > > r324782: Fri > > > > > > Oct 20 05:12:17 MSK 2017 > > > > > > bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X amd64 amd64 > > > > > > --- > > > > > > > > > > > > The only difference at kernel configs is a colored console. :-) > > > > > > > > > > > > And here I get some weird (is it?) result at the VM (I expect ntpd > > > > > > to be > > > > > > more stable): > > > > > > --- > > > > > > bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done > > > > > > remote refid st t when poll reach delay > > > > > > offset > > > > > > jitter > > > > > > == > > > > > > XX.XX.XX.1 XX.XX.XX.245 4 u9 6430.605 > > > > > > -1.202 > > > > > > 316.407 > > > > > > XX.XX.XX.1 XX.XX.XX.245 4 u7 6470.605 > > > > > > -1.202 > > > > > > 358.395 > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u5 64 170.615 > > > > > > -328.42 > > > > > > 181.405 > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u3 64 370.615 > > > > > > -328.42 > > > > > > 214.868 > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 67 64 370.615 > > > > > > -328.42 > > > > > > 214.868 > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 63 64 770.615 > > > > > > -328.42 > > > > > > 268.618 > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 60 64 1770.615 > > > > > > -328.42 > > > > > > 333.175 > > > > > > XX.XX.XX.1 .STEP. 16 u 1910 6400.000 > > > > > > 0.000 > > > > > > 0.000 > > > > > > XX.XX.XX.1 XX.XX.XX.245 4 u 27 6410.703 > > > > > > -262.63 > > > > > > 0.004 > > > > > > XX.XX.XX.1 XX.XX.XX.245 4 u 31 6410.649 > > > > > > -331.43 > > > > > > 68.800 > > > > > > --- > > > > > > > > > > > > At the same time host's results are very stable: > > > > > > --- > > > > > > bhyve-host% for t in `jot 10`; do ntpq -pn; sleep 64; done > > > > > > remote refid st t when poll reach delay > > > > > > offset > > > > > > jitter > > > > > > == > > > > > > > > > > > > > > > > > > > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u1 6410.401 > > > > > > 0.176 > > > > > > 0.106 > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u6 6430.401 > > > > > > 0.176 > > > > > > 0.459 > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u3 6470.401 > > > > > > 0.176 > > > > > > 0.940 > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 67 6470.401 > > > > > > 0.176 > > > > > > 0.940 > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 64 64 170.401 > > > > > > 0.176 > > > > > > 1.566 > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 60 64 370.448 > > > > > > 1.275 > > > > > > 1.739 > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 55 64 770.448 > > > > > > 1.275 > > > > > > 2.365 > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 53 64 1770.448 > > > > > > 1.275 > > > > > > 3.110 > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 50 64 3770.448 > > > > > > 1.275 > > > > > > 3.929 > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 45 64 3770.443 > > > > > > 8.750 > > > > > > 4.722 > > > > > > --- > > > > > > > > > > > > The network is organized via bridge -- host igb and vm tap > > > > > > interfaces > > > > > > are members of one bridge. > > > > > > > > > > > > Are those results expected? Does it smell like a bug? Should I dig > > > > > > furter? > > > > > > > > > > > So it is repeatedly stepping the clock in the VM? (Set > > > > > kern.timecounter.stepwarnings=1 to log steps). > > > > No kernel/ntpd messages for 20 minutes after setting this sysctl. > > > > > > > > > > > > > > > > > > > That is usually a sign > > > > > that the chosen timecounter is running at a different frequency than > > > > > it > > > > > claimed to be when it registered i
Re: host, bhyve vm and ntpd
(CC to freebsd-virtualization@) 20.10.2017 19:32, Ian Lepore пишет: > On Fri, 2017-10-20 at 18:36 +0300, Boris Samorodov wrote: >> 20.10.2017 18:31, Boris Samorodov пишет: >>> >>> 20.10.2017 18:12, Ian Lepore пишет: On Fri, 2017-10-20 at 14:46 +0300, Boris Samorodov wrote: > > Hi All, > > I have got a host: > --- > bhyve-host% uname -a > FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: Fri Aug > 25 05:25:26 MSK 2017 > bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FAST amd64 amd64 > --- > > And a bhyve vm: > --- > bhyve-vm: uname -a > FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 r324782: Fri > Oct 20 05:12:17 MSK 2017 > bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X amd64 amd64 > --- > > The only difference at kernel configs is a colored console. :-) > > And here I get some weird (is it?) result at the VM (I expect ntpd to be > more stable): > --- > bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done > remote refid st t when poll reach delay offset > jitter > == > XX.XX.XX.1 XX.XX.XX.245 4 u9 6430.605 -1.202 > 316.407 > XX.XX.XX.1 XX.XX.XX.245 4 u7 6470.605 -1.202 > 358.395 > *XX.XX.XX.1 XX.XX.XX.245 4 u5 64 170.615 -328.42 > 181.405 > *XX.XX.XX.1 XX.XX.XX.245 4 u3 64 370.615 -328.42 > 214.868 > *XX.XX.XX.1 XX.XX.XX.245 4 u 67 64 370.615 -328.42 > 214.868 > *XX.XX.XX.1 XX.XX.XX.245 4 u 63 64 770.615 -328.42 > 268.618 > *XX.XX.XX.1 XX.XX.XX.245 4 u 60 64 1770.615 -328.42 > 333.175 > XX.XX.XX.1 .STEP. 16 u 1910 6400.0000.000 > 0.000 > XX.XX.XX.1 XX.XX.XX.245 4 u 27 6410.703 -262.63 > 0.004 > XX.XX.XX.1 XX.XX.XX.245 4 u 31 6410.649 -331.43 > 68.800 > --- > > At the same time host's results are very stable: > --- > bhyve-host% for t in `jot 10`; do ntpq -pn; sleep 64; done > remote refid st t when poll reach delay offset > jitter > == > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u1 6410.4010.176 > 0.106 > *XX.XX.XX.1 XX.XX.XX.245 4 u6 6430.4010.176 > 0.459 > *XX.XX.XX.1 XX.XX.XX.245 4 u3 6470.4010.176 > 0.940 > *XX.XX.XX.1 XX.XX.XX.245 4 u 67 6470.4010.176 > 0.940 > *XX.XX.XX.1 XX.XX.XX.245 4 u 64 64 170.4010.176 > 1.566 > *XX.XX.XX.1 XX.XX.XX.245 4 u 60 64 370.4481.275 > 1.739 > *XX.XX.XX.1 XX.XX.XX.245 4 u 55 64 770.4481.275 > 2.365 > *XX.XX.XX.1 XX.XX.XX.245 4 u 53 64 1770.4481.275 > 3.110 > *XX.XX.XX.1 XX.XX.XX.245 4 u 50 64 3770.4481.275 > 3.929 > *XX.XX.XX.1 XX.XX.XX.245 4 u 45 64 3770.4438.750 > 4.722 > --- > > The network is organized via bridge -- host igb and vm tap interfaces > are members of one bridge. > > Are those results expected? Does it smell like a bug? Should I dig > furter? > So it is repeatedly stepping the clock in the VM? (Set kern.timecounter.stepwarnings=1 to log steps). >>> No kernel/ntpd messages for 20 minutes after setting this sysctl. >>> That is usually a sign that the chosen timecounter is running at a different frequency than it claimed to be when it registered itself -- the host may not be emulating the timer hardware properly in the guest. What is the output of sysctl kern.timecounter in the vm? >>> --- >>> bhyve-vm% sysctl kern.timecounter >>> >>> kern.timecounter.tsc_shift: 1 >>> kern.timecounter.smp_tsc_adjust: 0 >>> kern.timecounter.smp_tsc: 0 >>> kern.timecounter.invariant_tsc: 1 >>> kern.timecounter.fast_gettime: 1 >>> kern.timecounter.tick: 1 >>> kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(-100) >>> dummy(-100) >>> kern.timecounter.hardware: HPET >>> kern.timecounter.alloweddeviation: 5 >>> kern.timecounter.stepwarnings: 1 >>> kern.timecounter.tc.ACPI-fast.quality: 900 >>> kern.timecounter.tc.ACPI-fast.frequency: 3579545 >>> kern.timecounter.tc.ACPI-fast.counter: 4161213491 >>> kern.timecounter.tc.ACPI-fast.mask: 4294967295 >>> kern.timecounter.tc.HPET.quality: 950 >>> kern.timecounter.tc.HPET.frequency: 1000 >>> kern.timecounter.tc.HPET.counter: 3518036865 >>> kern.timecounter.tc.HPET.mask: 4294967295 >>> kern.timecounter.tc.i8254.quality: 0 >>> kern.timecoun
Re: host, bhyve vm and ntpd
On Fri, 2017-10-20 at 18:36 +0300, Boris Samorodov wrote: > 20.10.2017 18:31, Boris Samorodov пишет: > > > > 20.10.2017 18:12, Ian Lepore пишет: > > > > > > On Fri, 2017-10-20 at 14:46 +0300, Boris Samorodov wrote: > > > > > > > > Hi All, > > > > > > > > I have got a host: > > > > --- > > > > bhyve-host% uname -a > > > > FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: Fri Aug > > > > 25 05:25:26 MSK 2017 > > > > bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FAST amd64 amd64 > > > > --- > > > > > > > > And a bhyve vm: > > > > --- > > > > bhyve-vm: uname -a > > > > FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 r324782: Fri > > > > Oct 20 05:12:17 MSK 2017 > > > > bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X amd64 amd64 > > > > --- > > > > > > > > The only difference at kernel configs is a colored console. :-) > > > > > > > > And here I get some weird (is it?) result at the VM (I expect ntpd to be > > > > more stable): > > > > --- > > > > bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done > > > > remote refid st t when poll reach delay offset > > > > jitter > > > > == > > > > XX.XX.XX.1 XX.XX.XX.245 4 u9 6430.605 -1.202 > > > > 316.407 > > > > XX.XX.XX.1 XX.XX.XX.245 4 u7 6470.605 -1.202 > > > > 358.395 > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u5 64 170.615 -328.42 > > > > 181.405 > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u3 64 370.615 -328.42 > > > > 214.868 > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 67 64 370.615 -328.42 > > > > 214.868 > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 63 64 770.615 -328.42 > > > > 268.618 > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 60 64 1770.615 -328.42 > > > > 333.175 > > > > XX.XX.XX.1 .STEP. 16 u 1910 6400.0000.000 > > > > 0.000 > > > > XX.XX.XX.1 XX.XX.XX.245 4 u 27 6410.703 -262.63 > > > > 0.004 > > > > XX.XX.XX.1 XX.XX.XX.245 4 u 31 6410.649 -331.43 > > > > 68.800 > > > > --- > > > > > > > > At the same time host's results are very stable: > > > > --- > > > > bhyve-host% for t in `jot 10`; do ntpq -pn; sleep 64; done > > > > remote refid st t when poll reach delay offset > > > > jitter > > > > == > > > > > > > > > > > > > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u1 6410.4010.176 > > > > 0.106 > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u6 6430.4010.176 > > > > 0.459 > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u3 6470.4010.176 > > > > 0.940 > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 67 6470.4010.176 > > > > 0.940 > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 64 64 170.4010.176 > > > > 1.566 > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 60 64 370.4481.275 > > > > 1.739 > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 55 64 770.4481.275 > > > > 2.365 > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 53 64 1770.4481.275 > > > > 3.110 > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 50 64 3770.4481.275 > > > > 3.929 > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u 45 64 3770.4438.750 > > > > 4.722 > > > > --- > > > > > > > > The network is organized via bridge -- host igb and vm tap interfaces > > > > are members of one bridge. > > > > > > > > Are those results expected? Does it smell like a bug? Should I dig > > > > furter? > > > > > > > So it is repeatedly stepping the clock in the VM? (Set > > > kern.timecounter.stepwarnings=1 to log steps). > > No kernel/ntpd messages for 20 minutes after setting this sysctl. > > > > > > > > That is usually a sign > > > that the chosen timecounter is running at a different frequency than it > > > claimed to be when it registered itself -- the host may not be > > > emulating the timer hardware properly in the guest. What is the output > > > of sysctl kern.timecounter in the vm? > > --- > > bhyve-vm% sysctl kern.timecounter > > > > kern.timecounter.tsc_shift: 1 > > kern.timecounter.smp_tsc_adjust: 0 > > kern.timecounter.smp_tsc: 0 > > kern.timecounter.invariant_tsc: 1 > > kern.timecounter.fast_gettime: 1 > > kern.timecounter.tick: 1 > > kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(-100) > > dummy(-100) > > kern.timecounter.hardware: HPET > > kern.timecounter.alloweddeviation: 5 > > kern.timecounter.stepwarnings: 1 > > kern.timecounter.tc.ACPI-fast.quality: 900 > > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > > kern.timecounter.tc.ACPI-fast.counter: 4161213491 > > kern.timecounter.tc.ACPI-fast.mask: 4294967295 > > kern.timecounter.tc.HPET.quality: 950 > > kern.timecounter.tc.HPET.frequency: 1000 > > kern.timecounter.tc.
Re: host, bhyve vm and ntpd
20.10.2017 18:31, Boris Samorodov пишет: > 20.10.2017 18:12, Ian Lepore пишет: >> So it is repeatedly stepping the clock in the VM? (Set >> kern.timecounter.stepwarnings=1 to log steps). > No kernel/ntpd messages for 20 minutes after setting this sysctl. Sorry for multiply answers. The kernel message has just arrived: --- Oct 20 18:31:25 builder kernel: Time stepped from 1508513486.200998799 to 1508513485.31729 (1508513485.316858000) --- So, you are right, the time is stepped. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: host, bhyve vm and ntpd
20.10.2017 18:31, Boris Samorodov пишет: > 20.10.2017 18:12, Ian Lepore пишет: >> On Fri, 2017-10-20 at 14:46 +0300, Boris Samorodov wrote: >>> Hi All, >>> >>> I have got a host: >>> --- >>> bhyve-host% uname -a >>> FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: Fri Aug >>> 25 05:25:26 MSK 2017 >>> bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FAST amd64 amd64 >>> --- >>> >>> And a bhyve vm: >>> --- >>> bhyve-vm: uname -a >>> FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 r324782: Fri >>> Oct 20 05:12:17 MSK 2017 >>> bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X amd64 amd64 >>> --- >>> >>> The only difference at kernel configs is a colored console. :-) >>> >>> And here I get some weird (is it?) result at the VM (I expect ntpd to be >>> more stable): >>> --- >>> bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done >>> remote refid st t when poll reach delay offset >>> jitter >>> == >>> XX.XX.XX.1 XX.XX.XX.245 4 u9 6430.605 -1.202 >>> 316.407 >>> XX.XX.XX.1 XX.XX.XX.245 4 u7 6470.605 -1.202 >>> 358.395 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u5 64 170.615 -328.42 >>> 181.405 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u3 64 370.615 -328.42 >>> 214.868 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u 67 64 370.615 -328.42 >>> 214.868 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u 63 64 770.615 -328.42 >>> 268.618 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u 60 64 1770.615 -328.42 >>> 333.175 >>> XX.XX.XX.1 .STEP. 16 u 1910 6400.0000.000 >>> 0.000 >>> XX.XX.XX.1 XX.XX.XX.245 4 u 27 6410.703 -262.63 >>> 0.004 >>> XX.XX.XX.1 XX.XX.XX.245 4 u 31 6410.649 -331.43 >>> 68.800 >>> --- >>> >>> At the same time host's results are very stable: >>> --- >>> bhyve-host% for t in `jot 10`; do ntpq -pn; sleep 64; done >>> remote refid st t when poll reach delay offset >>> jitter >>> == >>> >>> >>> >>> *XX.XX.XX.1 XX.XX.XX.245 4 u1 6410.4010.176 >>> 0.106 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u6 6430.4010.176 >>> 0.459 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u3 6470.4010.176 >>> 0.940 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u 67 6470.4010.176 >>> 0.940 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u 64 64 170.4010.176 >>> 1.566 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u 60 64 370.4481.275 >>> 1.739 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u 55 64 770.4481.275 >>> 2.365 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u 53 64 1770.4481.275 >>> 3.110 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u 50 64 3770.4481.275 >>> 3.929 >>> *XX.XX.XX.1 XX.XX.XX.245 4 u 45 64 3770.4438.750 >>> 4.722 >>> --- >>> >>> The network is organized via bridge -- host igb and vm tap interfaces >>> are members of one bridge. >>> >>> Are those results expected? Does it smell like a bug? Should I dig >>> furter? >>> >> >> So it is repeatedly stepping the clock in the VM? (Set >> kern.timecounter.stepwarnings=1 to log steps). > > No kernel/ntpd messages for 20 minutes after setting this sysctl. > >> That is usually a sign >> that the chosen timecounter is running at a different frequency than it >> claimed to be when it registered itself -- the host may not be >> emulating the timer hardware properly in the guest. What is the output >> of sysctl kern.timecounter in the vm? > > --- > bhyve-vm% sysctl kern.timecounter > > kern.timecounter.tsc_shift: 1 > kern.timecounter.smp_tsc_adjust: 0 > kern.timecounter.smp_tsc: 0 > kern.timecounter.invariant_tsc: 1 > kern.timecounter.fast_gettime: 1 > kern.timecounter.tick: 1 > kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(-100) > dummy(-100) > kern.timecounter.hardware: HPET > kern.timecounter.alloweddeviation: 5 > kern.timecounter.stepwarnings: 1 > kern.timecounter.tc.ACPI-fast.quality: 900 > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > kern.timecounter.tc.ACPI-fast.counter: 4161213491 > kern.timecounter.tc.ACPI-fast.mask: 4294967295 > kern.timecounter.tc.HPET.quality: 950 > kern.timecounter.tc.HPET.frequency: 1000 > kern.timecounter.tc.HPET.counter: 3518036865 > kern.timecounter.tc.HPET.mask: 4294967295 > kern.timecounter.tc.i8254.quality: 0 > kern.timecounter.tc.i8254.frequency: 1193182 > kern.timecounter.tc.i8254.counter: 47597 > kern.timecounter.tc.i8254.mask: 65535 > kern.timecounter.tc.TSC-low.quality: -100 > kern.timecounter.tc.TSC-low.frequency: 1199886114 > kern.timecounter.tc.TSC-low.counter: 1274338278 > kern.timecounter.tc.TSC-low.mask: 4294967295 > --- BTW, here is the host kern.timecounter: --- kern.timecounter.tsc_shi
Re: host, bhyve vm and ntpd
20.10.2017 18:12, Ian Lepore пишет: > On Fri, 2017-10-20 at 14:46 +0300, Boris Samorodov wrote: >> Hi All, >> >> I have got a host: >> --- >> bhyve-host% uname -a >> FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: Fri Aug >> 25 05:25:26 MSK 2017 >> bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FAST amd64 amd64 >> --- >> >> And a bhyve vm: >> --- >> bhyve-vm: uname -a >> FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 r324782: Fri >> Oct 20 05:12:17 MSK 2017 >> bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X amd64 amd64 >> --- >> >> The only difference at kernel configs is a colored console. :-) >> >> And here I get some weird (is it?) result at the VM (I expect ntpd to be >> more stable): >> --- >> bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done >> remote refid st t when poll reach delay offset >> jitter >> == >> XX.XX.XX.1 XX.XX.XX.245 4 u9 6430.605 -1.202 >> 316.407 >> XX.XX.XX.1 XX.XX.XX.245 4 u7 6470.605 -1.202 >> 358.395 >> *XX.XX.XX.1 XX.XX.XX.245 4 u5 64 170.615 -328.42 >> 181.405 >> *XX.XX.XX.1 XX.XX.XX.245 4 u3 64 370.615 -328.42 >> 214.868 >> *XX.XX.XX.1 XX.XX.XX.245 4 u 67 64 370.615 -328.42 >> 214.868 >> *XX.XX.XX.1 XX.XX.XX.245 4 u 63 64 770.615 -328.42 >> 268.618 >> *XX.XX.XX.1 XX.XX.XX.245 4 u 60 64 1770.615 -328.42 >> 333.175 >> XX.XX.XX.1 .STEP. 16 u 1910 6400.0000.000 >> 0.000 >> XX.XX.XX.1 XX.XX.XX.245 4 u 27 6410.703 -262.63 >> 0.004 >> XX.XX.XX.1 XX.XX.XX.245 4 u 31 6410.649 -331.43 >> 68.800 >> --- >> >> At the same time host's results are very stable: >> --- >> bhyve-host% for t in `jot 10`; do ntpq -pn; sleep 64; done >> remote refid st t when poll reach delay offset >> jitter >> == >> >> >> >> *XX.XX.XX.1 XX.XX.XX.245 4 u1 6410.4010.176 >> 0.106 >> *XX.XX.XX.1 XX.XX.XX.245 4 u6 6430.4010.176 >> 0.459 >> *XX.XX.XX.1 XX.XX.XX.245 4 u3 6470.4010.176 >> 0.940 >> *XX.XX.XX.1 XX.XX.XX.245 4 u 67 6470.4010.176 >> 0.940 >> *XX.XX.XX.1 XX.XX.XX.245 4 u 64 64 170.4010.176 >> 1.566 >> *XX.XX.XX.1 XX.XX.XX.245 4 u 60 64 370.4481.275 >> 1.739 >> *XX.XX.XX.1 XX.XX.XX.245 4 u 55 64 770.4481.275 >> 2.365 >> *XX.XX.XX.1 XX.XX.XX.245 4 u 53 64 1770.4481.275 >> 3.110 >> *XX.XX.XX.1 XX.XX.XX.245 4 u 50 64 3770.4481.275 >> 3.929 >> *XX.XX.XX.1 XX.XX.XX.245 4 u 45 64 3770.4438.750 >> 4.722 >> --- >> >> The network is organized via bridge -- host igb and vm tap interfaces >> are members of one bridge. >> >> Are those results expected? Does it smell like a bug? Should I dig >> furter? >> > > So it is repeatedly stepping the clock in the VM? (Set > kern.timecounter.stepwarnings=1 to log steps). No kernel/ntpd messages for 20 minutes after setting this sysctl. > That is usually a sign > that the chosen timecounter is running at a different frequency than it > claimed to be when it registered itself -- the host may not be > emulating the timer hardware properly in the guest. What is the output > of sysctl kern.timecounter in the vm? --- bhyve-vm% sysctl kern.timecounter kern.timecounter.tsc_shift: 1 kern.timecounter.smp_tsc_adjust: 0 kern.timecounter.smp_tsc: 0 kern.timecounter.invariant_tsc: 1 kern.timecounter.fast_gettime: 1 kern.timecounter.tick: 1 kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(-100) dummy(-100) kern.timecounter.hardware: HPET kern.timecounter.alloweddeviation: 5 kern.timecounter.stepwarnings: 1 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.counter: 4161213491 kern.timecounter.tc.ACPI-fast.mask: 4294967295 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.HPET.frequency: 1000 kern.timecounter.tc.HPET.counter: 3518036865 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.counter: 47597 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.TSC-low.quality: -100 kern.timecounter.tc.TSC-low.frequency: 1199886114 kern.timecounter.tc.TSC-low.counter: 1274338278 kern.timecounter.tc.TSC-low.mask: 4294967295 --- > Also, what is the output of ntptime(8) in the vm? --- bhyve-vm% ntptime ntp_gettime() returns code 0 (OK) time dd94930f.20ea2900 Fri, Oct 20 2017 18:21:51.128, (.128573699), maximum error 1309110 us, estimated error 3 us, TAI offset 37 ntp_adjtime() returns code 0 (
Re: host, bhyve vm and ntpd
On Fri, 2017-10-20 at 14:46 +0300, Boris Samorodov wrote: > Hi All, > > I have got a host: > --- > bhyve-host% uname -a > FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: Fri Aug > 25 05:25:26 MSK 2017 > bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FAST amd64 amd64 > --- > > And a bhyve vm: > --- > bhyve-vm: uname -a > FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 r324782: Fri > Oct 20 05:12:17 MSK 2017 > bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X amd64 amd64 > --- > > The only difference at kernel configs is a colored console. :-) > > And here I get some weird (is it?) result at the VM (I expect ntpd to be > more stable): > --- > bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done > remote refid st t when poll reach delay offset > jitter > == > XX.XX.XX.1 XX.XX.XX.245 4 u9 6430.605 -1.202 > 316.407 > XX.XX.XX.1 XX.XX.XX.245 4 u7 6470.605 -1.202 > 358.395 > *XX.XX.XX.1 XX.XX.XX.245 4 u5 64 170.615 -328.42 > 181.405 > *XX.XX.XX.1 XX.XX.XX.245 4 u3 64 370.615 -328.42 > 214.868 > *XX.XX.XX.1 XX.XX.XX.245 4 u 67 64 370.615 -328.42 > 214.868 > *XX.XX.XX.1 XX.XX.XX.245 4 u 63 64 770.615 -328.42 > 268.618 > *XX.XX.XX.1 XX.XX.XX.245 4 u 60 64 1770.615 -328.42 > 333.175 > XX.XX.XX.1 .STEP. 16 u 1910 6400.0000.000 > 0.000 > XX.XX.XX.1 XX.XX.XX.245 4 u 27 6410.703 -262.63 > 0.004 > XX.XX.XX.1 XX.XX.XX.245 4 u 31 6410.649 -331.43 > 68.800 > --- > > At the same time host's results are very stable: > --- > bhyve-host% for t in `jot 10`; do ntpq -pn; sleep 64; done > remote refid st t when poll reach delay offset > jitter > == > > > > *XX.XX.XX.1 XX.XX.XX.245 4 u1 6410.4010.176 > 0.106 > *XX.XX.XX.1 XX.XX.XX.245 4 u6 6430.4010.176 > 0.459 > *XX.XX.XX.1 XX.XX.XX.245 4 u3 6470.4010.176 > 0.940 > *XX.XX.XX.1 XX.XX.XX.245 4 u 67 6470.4010.176 > 0.940 > *XX.XX.XX.1 XX.XX.XX.245 4 u 64 64 170.4010.176 > 1.566 > *XX.XX.XX.1 XX.XX.XX.245 4 u 60 64 370.4481.275 > 1.739 > *XX.XX.XX.1 XX.XX.XX.245 4 u 55 64 770.4481.275 > 2.365 > *XX.XX.XX.1 XX.XX.XX.245 4 u 53 64 1770.4481.275 > 3.110 > *XX.XX.XX.1 XX.XX.XX.245 4 u 50 64 3770.4481.275 > 3.929 > *XX.XX.XX.1 XX.XX.XX.245 4 u 45 64 3770.4438.750 > 4.722 > --- > > The network is organized via bridge -- host igb and vm tap interfaces > are members of one bridge. > > Are those results expected? Does it smell like a bug? Should I dig > furter? > So it is repeatedly stepping the clock in the VM? (Set kern.timecounter.stepwarnings=1 to log steps). That is usually a sign that the chosen timecounter is running at a different frequency than it claimed to be when it registered itself -- the host may not be emulating the timer hardware properly in the guest. What is the output of sysctl kern.timecounter in the vm? Also, what is the output of ntptime(8) in the vm? -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Build failure: non-SMP after SVN r324778
On Fri, Oct 20, 2017 at 3:52 PM, Michael Butler wrote: > If SMP is not defined, as it isn't on my last remaining i386 platform, the > build fails with: > > Building /usr/obj/usr/src/sys/SARAH/kern_mutex.o > --- kern_mutex.o --- > /usr/src/sys/kern/kern_mutex.c:313:3: error: implicit declaration of > function '_mtx_lock_spin' is invalid in C99 [-Werror,-Wimplicit-function-d > eclaration] > _mtx_lock_spin(m, v, opts, file, line); > ^ > /usr/src/sys/kern/kern_mutex.c:313:3: error: this function declaration is > not a prototype [-Werror,-Wstrict-prototypes] > 2 errors generated. > *** [kern_mutex.o] Error code 1 > > oops, fixed in r324803. -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Build failure: non-SMP after SVN r324778
If SMP is not defined, as it isn't on my last remaining i386 platform, the build fails with: Building /usr/obj/usr/src/sys/SARAH/kern_mutex.o --- kern_mutex.o --- /usr/src/sys/kern/kern_mutex.c:313:3: error: implicit declaration of function '_mtx_lock_spin' is invalid in C99 [-Werror,-Wimplicit-function-declaration] _mtx_lock_spin(m, v, opts, file, line); ^ /usr/src/sys/kern/kern_mutex.c:313:3: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes] 2 errors generated. *** [kern_mutex.o] Error code 1 make[2]: stopped in /usr/obj/usr/src/sys/SARAH imb ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
host, bhyve vm and ntpd
Hi All, I have got a host: --- bhyve-host% uname -a FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: Fri Aug 25 05:25:26 MSK 2017 bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FAST amd64 amd64 --- And a bhyve vm: --- bhyve-vm: uname -a FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 r324782: Fri Oct 20 05:12:17 MSK 2017 bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X amd64 amd64 --- The only difference at kernel configs is a colored console. :-) And here I get some weird (is it?) result at the VM (I expect ntpd to be more stable): --- bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done remote refid st t when poll reach delay offset jitter == XX.XX.XX.1 XX.XX.XX.245 4 u9 6430.605 -1.202 316.407 XX.XX.XX.1 XX.XX.XX.245 4 u7 6470.605 -1.202 358.395 *XX.XX.XX.1 XX.XX.XX.245 4 u5 64 170.615 -328.42 181.405 *XX.XX.XX.1 XX.XX.XX.245 4 u3 64 370.615 -328.42 214.868 *XX.XX.XX.1 XX.XX.XX.245 4 u 67 64 370.615 -328.42 214.868 *XX.XX.XX.1 XX.XX.XX.245 4 u 63 64 770.615 -328.42 268.618 *XX.XX.XX.1 XX.XX.XX.245 4 u 60 64 1770.615 -328.42 333.175 XX.XX.XX.1 .STEP. 16 u 1910 6400.0000.000 0.000 XX.XX.XX.1 XX.XX.XX.245 4 u 27 6410.703 -262.63 0.004 XX.XX.XX.1 XX.XX.XX.245 4 u 31 6410.649 -331.43 68.800 --- At the same time host's results are very stable: --- bhyve-host% for t in `jot 10`; do ntpq -pn; sleep 64; done remote refid st t when poll reach delay offset jitter == *XX.XX.XX.1 XX.XX.XX.245 4 u1 6410.4010.176 0.106 *XX.XX.XX.1 XX.XX.XX.245 4 u6 6430.4010.176 0.459 *XX.XX.XX.1 XX.XX.XX.245 4 u3 6470.4010.176 0.940 *XX.XX.XX.1 XX.XX.XX.245 4 u 67 6470.4010.176 0.940 *XX.XX.XX.1 XX.XX.XX.245 4 u 64 64 170.4010.176 1.566 *XX.XX.XX.1 XX.XX.XX.245 4 u 60 64 370.4481.275 1.739 *XX.XX.XX.1 XX.XX.XX.245 4 u 55 64 770.4481.275 2.365 *XX.XX.XX.1 XX.XX.XX.245 4 u 53 64 1770.4481.275 3.110 *XX.XX.XX.1 XX.XX.XX.245 4 u 50 64 3770.4481.275 3.929 *XX.XX.XX.1 XX.XX.XX.245 4 u 45 64 3770.4438.750 4.722 --- The network is organized via bridge -- host igb and vm tap interfaces are members of one bridge. Are those results expected? Does it smell like a bug? Should I dig furter? -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
