Supermicro X9SCV-Q: no boot options to define
Hello folks, my apology for polluting this list with a non-FreeBSD specific problem, but since Supermicro is a veryy often used vendor in the FreeBSD user/developer community I might find help here much fast. I got hands on onto an oldish Supermicro X9SCV-Q mainboard, equipted with an older i5-25XXM CPU running at 2,5 GHz). The AMI BIOS has version 2.10.1208 from 2012. The board does initially a longer beep and the it sounds like two or three very short beeps plus a last longer beep at a higher tune and then the system ALWAYS jumps into the firmware/BIOS screen, no matter whether I set a administrator password to protect the BIOS or not. Apart from the suspect of damaged RAM (three beeps indicate RAM problem above the first 64k block, two indicate PEI recovery or video memory problems if I interpret the manual correctly). Sometimes the POST screen shows some message like "... in Recovery State", due to the off-phased HDMI attached monitor, I do not see the first characters. Maybe someone knows what that might indicate. I already have changed the memory banks and the memory seems to be allright as the replacement memory has been checked thoroughly prior to the test in another well running box and I also checked the memory on another box with memtest tool without any suspicious indication. The attempt to flash the latest firmware fails due to the fact that I can not even define a boot device - either this process is cryptic or it isn't documented and I'm too dull. A FreeDOS 1.1 prepared USB flashdrive isn't bootable as any other UEFI/non UEFI flashdrive: I can see the USB drive as being attached to PCI bus in the firmware menu, I also can define a symbolic name, but then I fail in defining the path to the loader as suggested in the example (fs0:\file\loader.efi or so). Any hint is welcome. This board has been used successfully over the past years and was equipted with a TPM module at connector 23 (TMP1 header) - I'm unfamiliar with those technologies and my first guess apart from a hardware failure was that the hardware could have been protected anyway like it is done via secure boot. Unplugging that TPM header doesn' change anything. Also the boot of XigmaNAS latest USB flashed image or any FreeBSD (11, 12 CURRENT) latest USB flashed image failed so far. Thanks for some help in adavnce, oh pgpGLdssTbceE.pgp Description: OpenPGP digital signature
Re: WITH_LLVM_TARGET_BPF=yes broken on head
On 10 Dec 2019, at 20:29, Ryan Stone wrote: > > If I do a "make toolchain" with WITH_LLVM_TARGET_BPF=yes set in > /etc/src.conf on the latest head I get the following errors when it > tries to link clang. I believe that this was broken by the recent'ish > llvm update; it worked as of r351363 back in August. Thanks for reporting it, this should now be fixed with r355602! -Dimitry signature.asc Description: Message signed with OpenPGP
FreeBSD CI Weekly Report 2019-12-08
(Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2019-12-08 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2019-12-02 to 2019-12-08. During this period, we have: * 2463 builds (95% (-1.3) passed, 5% (+1.3) failed) of buildworld and buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 353 test runs (98% (+0.5) passed, 1.7% (-0.8) unstable, 0.3% (+0.3) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 42 doc builds (100% (0) passed) Test case status (on 2019-12-08 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | --- | -- | - | - | --- | | head/amd64 | 7632 (+12) | 7563 (+9) | 0 (0) | 69 (+3) | | head/i386 | 7630 (+12) | 7557 (+9) | 0 (0) | 73 (+3) | | 12-STABLE/amd64 | 7488 (+5) | 7437 (+5) | 0 (0) | 51 (0) | | 12-STABLE/i386 | 7486 (+5) | 7428 (+2) | 0 (0) | 58 (+3) | | 11-STABLE/amd64 | 6858 (+5) | 6811 (+5) | 0 (0) | 47 (0) | | 11-STABLE/i386 | 6856 (+5) | 6804 (+2) | 0 (0) | 52 (+3) | (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/@FreeBSD-CI/report-20191208 and archive is available at https://hackmd.io/@FreeBSD-CI/, any help is welcome. ## News * Experimental "Hardware test lab" result is available at: https://ci.freebsd.org/hwlab/ , more hardware support is welcomed! ## Failing and Flaky Tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * cddl.usr.sbin.dtrace.common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237641 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~13 failing and ~109 skipped cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details * Work for cleaning these failing cass are in progress ## Disabled Tests * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * sys.kern.ptrace_test.ptrace__PT_KILL_competing_stop https://bugs.freebsd.org/220841 * lib.libc.regex.exhaust_test.regcomp_too_big (i386 only) https://bugs.freebsd.org/237450 * sys.netinet.socket_afinet.socket_afinet_bind_zero https://bugs.freebsd.org/238781 * sys.netpfil.pf.names.names * sys.netpfil.pf.synproxy.synproxy https://bugs.freebsd.org/238870 * sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger https://bugs.freebsd.org/239292 * sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger https://bugs.freebsd.org/239397 * sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger https://bugs.freebsd.org/239399 * sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger https://bugs.freebsd.org/239425 * lib.libc.gen.getmntinfo_test.getmntinfo_test https://bugs.freebsd.org/240049 * sys.sys.qmath_test.qdivq_s64q https://bugs.freebsd.org/240219 * sys.kern.ptrace_test.ptrace__getppid https://bugs.freebsd.org/240510 * lib.libc.sys.stat_test.stat_socket https://bugs.freebsd.org/240621 * lib.libarchive.functional_test.test_write_filter_zstd https://bugs.freebsd.org/240683 * lib.libcasper.services.cap_dns.dns_test.main https://bugs.freebsd.org/241435 * local.kyua.* (31 cases) & local.lutok.* (3 cases) on 11-i386 https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/2278/testReport/ ## Issues ### Cause build fails * https://bugs.freebsd.org/233735 Possible build race: genoffset.o /usr/src/sys/sys/types.h: error: machine/endian.h: No such file or directory * https://bugs.freebsd.org/233769 Possible build race: ld: error: unable to find library -lgcc_s ### Cause kernel panics * https://bugs.freebsd.org/238870 sys.netpfil.pf.names.names and sys.netpfil.pf.synproxy.synproxy cause panic Patch exists: * https://reviews.freebsd.org/D20868 * https://reviews.freebsd.org/D20869 ### Open * https://bugs.freebsd.org/237403 Tests in sys/opencrypto should be converted to Python3 * https://bugs.freebsd.org/237641 Flakey test case: common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237656 "Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of memory." seen when running sys/netipsec tests * https://bugs.freebsd.org/238781 sys.netinet.socket_afinet.socket_afinet_bind_zero does not work when mac_portacl(4)
13-CURRENT r355560: GNOME and KDE crash when logging in
Hi freebsd-current@ mailing list, When I updated my laptop to r355560, I could boot into GDM, but logging into GNOME led to a coredump and brought me back to GDM. I tried KDE, but logging in via SDDM also led to a crash. I noted a lot of changes to the VM subsystem have happened, are they related to the crashes? Not meaning that r355560 specifically caused the issue, but that's the last checked out revision. I don't have coredumps, sorry. Looks like my laptop will be booting into Windows for the time being. Running -STABLE is not an option because of unsupported hardware there. -Neel === https://www.neelc.org/ ___ 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"
WITH_LLVM_TARGET_BPF=yes broken on head
If I do a "make toolchain" with WITH_LLVM_TARGET_BPF=yes set in /etc/src.conf on the latest head I get the following errors when it tries to link clang. I believe that this was broken by the recent'ish llvm update; it worked as of r351363 back in August. ld: error: undefined symbol: llvm::initializeBPFAbstractMemberAccessPass(llvm::PassRegistry&) >>> referenced by BPFTargetMachine.cpp:37 >>> (/srcpool/src/rstone/freebsd/contrib/llvm/lib/Target/BPF/BPFTargetMachine.cp p:37) >>> BPFTargetMachine.o:(LLVMInitializeBPFTarget) in archive >>> /usr/obj/srcpool/src/rstone/freebsd/amd64.am d64/tmp/obj-tools/lib/clang/libllvm/libllvm.a ld: error: undefined symbol: llvm::createBPFAbstractMemberAccess() >>> referenced by BPFTargetMachine.cpp:97 >>> (/srcpool/src/rstone/freebsd/contrib/llvm/lib/Target/BPF/BPFTargetMachine.cp p:97) >>> BPFTargetMachine.o:((anonymous >>> namespace)::BPFPassConfig::addIRPasses()) in archive /usr/obj/srcpool /src/rstone/freebsd/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a ld: error: undefined symbol: llvm::createBPFMISimplifyPatchablePass() >>> referenced by BPFTargetMachine.cpp:111 >>> (/srcpool/src/rstone/freebsd/contrib/llvm/lib/Target/BPF/BPFTargetMachine.c pp:111) >>> BPFTargetMachine.o:((anonymous >>> namespace)::BPFPassConfig::addMachineSSAOptimization()) in archive /u sr/obj/srcpool/src/rstone/freebsd/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a ld: error: undefined symbol: llvm::BPFCoreSharedInfo::AmaAttr >>> referenced by string:1427 (/usr/include/c++/v1/string:1427) >>> BTFDebug.o:(llvm::BTFDebug::processLDimm64(llvm::MachineInstr >>> const*)) in archive /usr/obj/srcpool/s rc/rstone/freebsd/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a ld: error: undefined symbol: llvm::BPFCoreSharedInfo::AmaAttr >>> referenced by string:0 (/usr/include/c++/v1/string:0) >>> BTFDebug.o:(llvm::BTFDebug::processLDimm64(llvm::MachineInstr >>> const*)) in archive /usr/obj/srcpool/s rc/rstone/freebsd/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a ld: error: undefined symbol: llvm::BPFCoreSharedInfo::AmaAttr >>> referenced by string:0 (/usr/include/c++/v1/string:0) >>> BTFDebug.o:(llvm::BTFDebug::processLDimm64(llvm::MachineInstr >>> const*)) in archive /usr/obj/srcpool/s rc/rstone/freebsd/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a ld: error: undefined symbol: llvm::BPFCoreSharedInfo::AmaAttr >>> referenced by string:0 (/usr/include/c++/v1/string:0) >>> BTFDebug.o:(llvm::BTFDebug::processLDimm64(llvm::MachineInstr >>> const*)) in archive /usr/obj/srcpool/s rc/rstone/freebsd/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a ld: error: undefined symbol: llvm::BPFCoreSharedInfo::PatchableExtSecName >>> referenced by string:1427 (/usr/include/c++/v1/string:1427) >>> BTFDebug.o:(llvm::BTFDebug::processLDimm64(llvm::MachineInstr >>> const*)) in archive /usr/obj/srcpool/s rc/rstone/freebsd/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a ld: error: undefined symbol: llvm::BPFCoreSharedInfo::PatchableExtSecName >>> referenced by string:0 (/usr/include/c++/v1/string:0) >>> BTFDebug.o:(llvm::BTFDebug::processLDimm64(llvm::MachineInstr >>> const*)) in archive /usr/obj/srcpool/s rc/rstone/freebsd/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a ld: error: undefined symbol: llvm::BPFCoreSharedInfo::PatchableExtSecName >>> referenced by string:0 (/usr/include/c++/v1/string:0) >>> BTFDebug.o:(llvm::BTFDebug::processLDimm64(llvm::MachineInstr >>> const*)) in archive /usr/obj/srcpool/s rc/rstone/freebsd/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a ld: error: undefined symbol: llvm::BPFCoreSharedInfo::PatchableExtSecName >>> referenced by StringRef.h:0 >>> (/srcpool/src/rstone/freebsd/contrib/llvm/include/llvm/ADT/StringRef.h:0) >>> BTFDebug.o:(llvm::BTFDebug::processLDimm64(llvm::MachineInstr >>> const*)) in archive /usr/obj/srcpool/s rc/rstone/freebsd/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a ld: error: undefined symbol: llvm::BPFCoreSharedInfo::AmaAttr >>> referenced by string:1427 (/usr/include/c++/v1/string:1427) >>> BTFDebug.o:(llvm::BTFDebug::InstLower(llvm::MachineInstr >>> const*, llvm::MCInst&)) in archive /usr/obj /srcpool/src/rstone/freebsd/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a ld: error: undefined symbol: llvm::BPFCoreSharedInfo::AmaAttr >>> referenced by string:0 (/usr/include/c++/v1/string:0) >>> BTFDebug.o:(llvm::BTFDebug::InstLower(llvm::MachineInstr >>> const*, llvm::MCInst&)) in archive /usr/obj /srcpool/src/rstone/freebsd/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/libllvm.a ld: error: undefined symbol: llvm::BPFCoreSharedInfo::AmaAttr >>> referenced by string:0 (/usr/include/c++/v1/string:0) >>> BTFDebug.o:(llvm::BTFDebug::InstLower(llvm::MachineInstr >>> const*, llvm::MCInst&)) in
13-CURRENT r355560: GNOME and KDE crash when logging in
Hi freebsd-current@, freebsd-ports@ mailing lists, When I updated my laptop to r355560, I could boot into GDM, but logging into GNOME led to a coredump and brought me back to GDM. I tried KDE, but logging in via SDDM also led to a crash. I noted a lot of changes to the VM subsystem have happened, are they related to the crashes? Not meaning that r355560 specifically caused the issue, but that's the last checked out revision. I don't have coredumps, sorry. Looks like my laptop will be booting into Windows for the time being. Running -STABLE is not an option because of unsupported hardware there. -Neel === https://www.neelc.org/ ___ 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"
sysutils/lsof: Recent changes have broken lsof
Anyone know what I need to add to fix this? --- dnode.o --- In file included from dnode.c:62: /usr/src/sys/fs/tmpfs/tmpfs.h:508:2: warning: implicit declaration of function 'MPASS' is invalid in C99 [-Wimplicit-function-declaration] MPASS(mp != NULL && mp->mnt_data != NULL); ^ /usr/src/sys/fs/tmpfs/tmpfs.h:518:2: warning: implicit declaration of function 'MPASS' is invalid in C99 [-Wimplicit-function-declaration] MPASS(vp != NULL && vp->v_data != NULL); ^ /usr/src/sys/fs/tmpfs/tmpfs.h:529:2: warning: implicit declaration of function 'MPASS' is invalid in C99 [-Wimplicit-function-declaration] TMPFS_VALIDATE_DIR(node); ^ /usr/src/sys/fs/tmpfs/tmpfs.h:479:2: note: expanded from macro 'TMPFS_VALIDATE_DIR' MPASS((node)->tn_type == VDIR); \ ^ 3 warnings generated. --- dnode1.o --- cc -pipe -fstack-protector-strong -fno-strict-aliasing -DNEEDS_BOOL_TYPEDEF -DHASTASKS -DHAS_PAUSE_SBT -DHAS_DUP2 -DHAS_CLOSEFROM -DHASEFFNLINK=i_effnlink -DHASF_VNODE -DHAS_FILEDESCENT -DHAS_TMPFS -DHASWCTYPE_H -DHASSBSTATE -DHAS_KVM_VNODE -DHAS_UFS1_2 -DHAS_NO_IDEV -DHAS_VM_MEMATTR_T -DNEEDS_DEVICE_T -DHAS_CDEV2PRIV -DHAS_NO_SI_UDEV -DHAS_SYS_SX_H -DHASFUSEFS -DHAS_ZFS -DHAS_V_LOCKF -DHAS_LOCKF_ENTRY -DHAS_NO_6PORT -DHAS_NO_6PPCB -DNEEDS_BOOLEAN_T -DHAS_SB_CCC -DHAS_FDESCENTTBL -DFREEBSDV=13000 -DHASFDESCFS=2 -DHASPSEUDOFS -DHASNULLFS -DHASIPv6 -DHASUTMPX -DHAS_STRFTIME -DLSOF_VSTR=\"13.0-CURRENT\" -I/usr/src/sys -O2 -c dnode1.c -o dnode1.o In file included from dnode1.c:148: In file included from /usr/src/sys/fs/fuse/fuse_node.h:72: /usr/src/sys/fs/fuse/fuse_file.h:214:33: warning: declaration of 'struct fuse_open_out' will not be visible outside of this function [-Wvisibility] struct ucred *cred, struct fuse_open_out *foo); ^ In file included from dnode1.c:148: /usr/src/sys/fs/fuse/fuse_node.h:142:2: warning: implicit declaration of function 'getbinuptime' is invalid in C99 [-Wimplicit-function-declaration] getbinuptime(); ^ /usr/src/sys/fs/fuse/fuse_node.h:174:3: warning: implicit declaration of function 'MPASS' is invalid in C99 [-Wimplicit-function-declaration] MPASS(dvp->v_type == VDIR); ^ /usr/src/sys/fs/fuse/fuse_node.h:187:45: warning: declaration of 'struct fuse_entry_out' will not be visible outside of this function [-Wvisibility] int fuse_vnode_get(struct mount *mp, struct fuse_entry_out *feo, ^ 4 warnings generated. --- lib/liblsof.a --- --- fino.o --- cc -pipe -fstack-protector-strong -fno-strict-aliasing -DNEEDS_BOOL_TYPEDEF -DHASTASKS -DHAS_PAUSE_SBT -DHAS_DUP2 -DHAS_CLOSEFROM -DHASEFFNLINK=i_effnlink -DHASF_VNODE -DHAS_FILEDESCENT -DHAS_TMPFS -DHASWCTYPE_H -DHASSBSTATE -DHAS_KVM_VNODE -DHAS_UFS1_2 -DHAS_NO_IDEV -DHAS_VM_MEMATTR_T -DNEEDS_DEVICE_T -DHAS_CDEV2PRIV -DHAS_NO_SI_UDEV -DHAS_SYS_SX_H -DHASFUSEFS -DHAS_ZFS -DHAS_V_LOCKF -DHAS_LOCKF_ENTRY -DHAS_NO_6PORT -DHAS_NO_6PPCB -DNEEDS_BOOLEAN_T -DHAS_SB_CCC -DHAS_FDESCENTTBL -DFREEBSDV=13000 -DHASFDESCFS=2 -DHASPSEUDOFS -DHASNULLFS -DHASIPv6 -DHASUTMPX -DHAS_STRFTIME -DLSOF_VSTR="13.0-CURRENT" -I/usr/src/sys -O2 -c fino.c -o fino.o --- dnode2.o --- --- dnode2.o --- cc -pipe -fstack-protector-strong -fno-strict-aliasing -DNEEDS_BOOL_TYPEDEF -DFREEBSDV=13000 -DHAS_ZFS -DHAS_CV_TIMEDWAIT_SBT -DHAS_V_LOCKF -D_SOLARIS_C_SOURCE -O2 -I/usr/src/sys/cddl/compat/opensolaris -I/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs -I/usr/src/sys/cddl/contrib/opensolaris/uts/common/zmod -I/usr/src/sys/cddl/contrib/opensolaris/uts/common -I/usr/src/sys/cddl/contrib/opensolaris/common/zfs -I/usr/src/sys/cddl/contrib/opensolaris/common -I/wrkdirs/usr/ports/sysutils/lsof/work/lsof-4.93.2/usr/src/include -I`pwd` -c dnode2.c -o dnode2.o In file included from dnode2.c:56: In file included from /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_znode.h:33: In file included from /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/dmu.h:48: In file included from /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_context.h:73: In file included from /usr/src/sys/cddl/compat/opensolaris/sys/vfs.h:37: /usr/src/sys/cddl/compat/opensolaris/sys/vnode.h:243:10: warning: implicit declaration of function 'VOP_FSYNC' is invalid in C99 [-Wimplicit-function-declaration] error = VOP_FSYNC(vp, MNT_WAIT, curthread); ^ --- lib/liblsof.a --- --- isfn.o --- cc -pipe -fstack-protector-strong -fno-strict-aliasing -DNEEDS_BOOL_TYPEDEF -DHASTASKS -DHAS_PAUSE_SBT -DHAS_DUP2 -DHAS_CLOSEFROM -DHASEFFNLINK=i_effnlink -DHASF_VNODE -DHAS_FILEDESCENT -DHAS_TMPFS -DHASWCTYPE_H -DHASSBSTATE -DHAS_KVM_VNODE -DHAS_UFS1_2 -DHAS_NO_IDEV -DHAS_VM_MEMATTR_T -DNEEDS_DEVICE_T -DHAS_CDEV2PRIV -DHAS_NO_SI_UDEV -DHAS_SYS_SX_H -DHASFUSEFS -DHAS_ZFS -DHAS_V_LOCKF
Re: dtrace not working on bhyve VM without invariant_tsc
On Mon, Dec 09, 2019 at 09:27:01PM -0500, Ryan Stone wrote: > I have a bhyve VM guest on my laptop where dtrace just constantly > aborts whenever I try to use it: > > [rstone@ebpf dtrace]sudo dtrace -s fdcopy.d > Assertion failed: (buf->dtbd_timestamp >= first_timestamp), file > /usr/home/rstone/git/bsd-worktree/ebpf-import/cddl/contrib/opensolaris/lib/libdtrace/common/dt_consume.c, > line 3026. > Abort trap > > I believe that the problem is caused by dtrace unconditionally using > rdtsc() to implement dtrace_gethrtime(), assuming that the values will > be stable for a given CPU. The VM's vcpus seem to be getting migrated > frequently. > > Should dtrace instead be using the system timecounter? That should > stand a much better chance of being monotonically increasing. One complication here is that the timecounter must be readable without calling any symbols in the kernel, to avoid probe recursion. That is, dtrace_gethrtime() cannot unconditionally use the system timecounter. It might be possible to use the timecounter specifically for dtbd_timestamp, but I suspect that will just shift the problem elsewhere: dtrace uses the TSC to provide a global order for individual records. As Eric noted you can pin the vCPUs, but I'm surprised that laptop does not have an invariant TSC. DTrace used to attempt to synchronize TSCs, but I disabled this for guests in r345359. ___ 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: dtrace not working on bhyve VM without invariant_tsc
> On Dec 9, 2019, at 8:27 PM, Ryan Stone wrote: > > I have a bhyve VM guest on my laptop where dtrace just constantly > aborts whenever I try to use it: > > [rstone@ebpf dtrace]sudo dtrace -s fdcopy.d > Assertion failed: (buf->dtbd_timestamp >= first_timestamp), file > /usr/home/rstone/git/bsd-worktree/ebpf-import/cddl/contrib/opensolaris/lib/libdtrace/common/dt_consume.c, > line 3026. > Abort trap > > I believe that the problem is caused by dtrace unconditionally using > rdtsc() to implement dtrace_gethrtime(), assuming that the values will > be stable for a given CPU. The VM's vcpus seem to be getting migrated > frequently. > > Should dtrace instead be using the system timecounter? That should > stand a much better chance of being monotonically increasing. I’ve seen TSC issues with OneFS under bhyve on certain CPUs. Pinning the VM to CPUs 1-N (i.e. avoiding CPU 0) worked around it. You might try that as a workaround. Eric ___ 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"
