Re: host, bhyve vm and ntpd
25.10.2017 01:14, Ian Lepore пишет: > Can you show the /var/db/ntpd.drift file contents of the host and > guest? Ideally, now that it's stable, the two values should be very > close. If they're not, maybe this isn't the right fix. Sorry, no. :-( I experimented with the host and bhyve vm now has unstable ntp values (stepping). I'll try to revert all my changes and report back in a couple of days. -- WBR, bsam ___ 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 Wed, 2017-10-25 at 00:43 +0300, Boris Samorodov wrote: > Hi Ian, All! > > 22.10.2017 01:15, Ian Lepore пишет: > > > > On Sat, 2017-10-21 at 17:07 -0400, Michael Voorhis wrote: > > > > > > Ian Lepore writes: > > > > > > > > > > > > Beyond that, I'm not sure what else to try. It might be necessary to > > > > get some bhyve developers involved (I know almost nothing about it). > > > NTPD behaves more normally on uniprocessor VMs. > > > > > > A FreeBSD bhyve-guest running on a freebsd host will select a > > > different timecounter depending on whether it is a multiprocessor or a > > > uniprocessor. My uniprocessor bhyve-vm selected TSC-low as the best > > > timecounter in a uniprocessor. NTP functions there as expected. > > > > > > kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) HPET(950) i8254(0) > > > dummy(-100) > > > kern.timecounter.hardware: TSC-low > > > > > > The very same VM, when given two total CPUs, selected HPET (if I > > > recall) and the timekeeping with NTPD was unreliable, with many > > > step-resets to the clock. > > > > > Hmm, I just had glance at the code in sys/amd64/vmm/io/vhpet.c and it > > looks right. I wonder if this is just a simple roundoff error in > > converting between 10.0MHz and SBT units? If so, that could be wished > > away easily by using a power-of-2 frequency for the virtual HPET. I > > wonder if the attached patch is all that's needed? > I suppose the answer is "yes", the patch helped. Here are two samples > (host for bhyve VM without your patch and after patching): > --- > https://poudriere.passap.ru/misc/ntpd.jot.log-HPET.frequency.1000.txt > https://poudriere.passap.ru/misc/ntpd.jot.log-HPET.frequency.16777216.txt > --- > > The command was: > % for t in `jot 1000`; do ntpq -pn; sleep 64; done > > The patch made the system to stabilize the process. > Ian, thank you! > Hmmm. The startup behavior wasn't great, it took a long time and several clock steps for it to figure out the frequency error and get the clock under control. But, as you say, it did eventually stabilize this time. Can you show the /var/db/ntpd.drift file contents of the host and guest? Ideally, now that it's stable, the two values should be very close. If they're not, maybe this isn't the right fix. -- 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: host, bhyve vm and ntpd
Hi Ian, All! 22.10.2017 01:15, Ian Lepore пишет: > On Sat, 2017-10-21 at 17:07 -0400, Michael Voorhis wrote: >> Ian Lepore writes: >>> >>> Beyond that, I'm not sure what else to try. It might be necessary to >>> get some bhyve developers involved (I know almost nothing about it). >> NTPD behaves more normally on uniprocessor VMs. >> >> A FreeBSD bhyve-guest running on a freebsd host will select a >> different timecounter depending on whether it is a multiprocessor or a >> uniprocessor. My uniprocessor bhyve-vm selected TSC-low as the best >> timecounter in a uniprocessor. NTP functions there as expected. >> >> kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) HPET(950) i8254(0) >> dummy(-100) >> kern.timecounter.hardware: TSC-low >> >> The very same VM, when given two total CPUs, selected HPET (if I >> recall) and the timekeeping with NTPD was unreliable, with many >> step-resets to the clock. >> > > Hmm, I just had glance at the code in sys/amd64/vmm/io/vhpet.c and it > looks right. I wonder if this is just a simple roundoff error in > converting between 10.0MHz and SBT units? If so, that could be wished > away easily by using a power-of-2 frequency for the virtual HPET. I > wonder if the attached patch is all that's needed? I suppose the answer is "yes", the patch helped. Here are two samples (host for bhyve VM without your patch and after patching): --- https://poudriere.passap.ru/misc/ntpd.jot.log-HPET.frequency.1000.txt https://poudriere.passap.ru/misc/ntpd.jot.log-HPET.frequency.16777216.txt --- The command was: % for t in `jot 1000`; do ntpq -pn; sleep 64; done The patch made the system to stabilize the process. Ian, thank you! -- WBR, bsam ___ 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: Stale file handle when mounting nfs
Eh... disregard my last message, the mount works properly but the mount is stuck in a hard lock state. ___ 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: Stale file handle when mounting nfs
Was a bit tired last night and just wanted to make sure this issue was known. Upgraded to r324957 and everything works! yay! ___ 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: libfuzzer support
> On 24. Oct 2017, at 11:31, David Chisnall wrote: > > On 24 Oct 2017, at 10:29, Kurt Jaeger wrote: >> >>> >>> is libfuzzer (see https://llvm.org/docs/LibFuzzer.html) supported on >>> FreeBSD head? >>> It seems that it is not supported by /usr/bin/clang... >>> >>> Am I wrong and it is supported or is someone working on it? >> >> I searched in the Port devel/llvm50 and it looks like there's no support >> for libfuzzer right now. >> >> But that would probably(?) be the best place to add it first. > > It’s been a while, but I’m pretty sure I had libFuzzer working from the > upstream sources on FreeBSD. I found AFL (which also works on FreeBSD out of > the box) more useful, so I didn’t Are there plans to enable it for the versions of clang integrated in FreeBSD? > spend much time with it. Thanks for the hint, will look into it. Best regards Michael > > David > ___ 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: libfuzzer support
> On 24. Oct 2017, at 11:29, Kurt Jaeger wrote: > > Hi! > >> is libfuzzer (see https://llvm.org/docs/LibFuzzer.html) supported on FreeBSD >> head? >> It seems that it is not supported by /usr/bin/clang... >> >> Am I wrong and it is supported or is someone working on it? > > I searched in the Port devel/llvm50 and it looks like there's no support > for libfuzzer right now. Yepp, I checked that also... > > But that would probably(?) be the best place to add it first. Not sure. It would be nice if some version of clang would support this, I do not care if it is the one in the base system or in the ports tree. Best regards Michael > > -- > p...@opsec.eu+49 171 3101372 3 years to > go ! ___ 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: libfuzzer support
On 24 Oct 2017, at 10:29, Kurt Jaeger wrote: > >> >> is libfuzzer (see https://llvm.org/docs/LibFuzzer.html) supported on FreeBSD >> head? >> It seems that it is not supported by /usr/bin/clang... >> >> Am I wrong and it is supported or is someone working on it? > > I searched in the Port devel/llvm50 and it looks like there's no support > for libfuzzer right now. > > But that would probably(?) be the best place to add it first. It’s been a while, but I’m pretty sure I had libFuzzer working from the upstream sources on FreeBSD. I found AFL (which also works on FreeBSD out of the box) more useful, so I didn’t spend much time with it. David ___ 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: libfuzzer support
Hi! > is libfuzzer (see https://llvm.org/docs/LibFuzzer.html) supported on FreeBSD > head? > It seems that it is not supported by /usr/bin/clang... > > Am I wrong and it is supported or is someone working on it? I searched in the Port devel/llvm50 and it looks like there's no support for libfuzzer right now. But that would probably(?) be the best place to add it first. -- p...@opsec.eu+49 171 3101372 3 years to go ! ___ 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"
libfuzzer support
Dear all, is libfuzzer (see https://llvm.org/docs/LibFuzzer.html) supported on FreeBSD head? It seems that it is not supported by /usr/bin/clang... Am I wrong and it is supported or is someone working on it? Best regards Michael ___ 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: There is *NO* abi stability in -head
On 10/23/17 22:35, Mateusz Guzik wrote: This is your friendly reminder that in head struct layouts can change and each update requires you to rebuild *all* modules (including ones which come from ports). In practice you can get away without it most of the time, but if in doubt or seeing funny crashes - *recompile* and test with that. Hi, And for developers making this changes, consider bumping the __FreeBSD_version macro in sys/sys/param.h along with your commit. It forces recompilation of external kernel modules :-) --HPS ___ 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: There is *NO* abi stability in -head
On 23 Oct 2017, at 21:35, Mateusz Guzik wrote:
>
> Instead, the same can be reshuffled:
> struct crap2 {
>int i1;
>int i2;
>void *p1;
>void *p2;
> };
>
> With offsets:
>
> 0x1000 i1
> 0x1004 i2
> 0x1008 p1
> 0x1010 p2
>
> This is only 24 bytes. 2 ints can be placed together and since they add
> up to 8 the p1 pointer gets the right alignment without extra padding.
If you are making changes of this nature, please consider sorting in the other
order. When we start seeing 128-bit pointers (which, with CHERI-like systems,
may be sooner than you think) then this ordering will give you lots of padding,
whereas putting the pointers first will not.
David
___
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"
Stale file handle when mounting nfs
Hello, On 12.0-CURRENT #4 r324135 I am trying to mount an nfs and receiving stale mount on a linux system. # mount -t nfs -o nfsvers=3 -v 10.0.0.8:/mnt/tank /mnt/tank mount.nfs: timeout set for Tue Oct 24 00:38:47 2017 mount.nfs: trying text-based options 'nfsvers=3,addr=10.0.0.8' mount.nfs: prog 13, trying vers=3, prot=6 mount.nfs: trying 10.0.0.8 prog 13 vers 3 prot TCP port 2049 mount.nfs: prog 15, trying vers=3, prot=17 mount.nfs: trying 10.0.0.8 prog 15 vers 3 prot UDP port 996 mount.nfs: mount(2): Stale file handle mount.nfs: trying text-based options 'nfsvers=3,addr=10.0.0.8' mount.nfs: prog 13, trying vers=3, prot=6 mount.nfs: trying 10.0.0.8 prog 13 vers 3 prot TCP port 2049 mount.nfs: prog 15, trying vers=3, prot=17 mount.nfs: trying 10.0.0.8 prog 15 vers 3 prot UDP port 996 mount.nfs: mount(2): Stale file handle mount.nfs: trying text-based options 'nfsvers=3,addr=10.0.0.8' mount.nfs: prog 13, trying vers=3, prot=6 mount.nfs: trying 10.0.0.8 prog 13 vers 3 prot TCP port 2049 mount.nfs: prog 15, trying vers=3, prot=17 mount.nfs: trying 10.0.0.8 prog 15 vers 3 prot UDP port 996 mount.nfs: mount(2): Stale file handle mount.nfs: Stale file handle Noticed that rmacklem has been work on pnfs, but not positive this would affect version 3. Will upgrade the system tomorrow and report back. Best Regards, Richard Gallamore ___ 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: emulators/virtualbox-kmod: turn on VIMAGE by default for FreeBSD 12+
24 окт. 2017 г. 0:38 пользователь "Oleg Ginzburg"
написал:
Hello,
With this change:
https://svnweb.freebsd.org/base?view=revision&revision=324810 I think
should also set VIMAGE options by default in emulators/virtualbox-kmod port
for FreeBSD 12+ via
.if ${OPSYS} == FreeBSD && ${OSVERSION} >= 1200051
or by separated meta port ( FLAVOR can help?) :
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215336
Without this change we will get panic on FreeBSD 12 + virtualbox-kmod on
boot.
Hi!
First of all I suppose this has to be fixed the way kernel should not
panic, but should just not work (fail to load the module?) and warn about
that.
My 2 cents.
___
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"
