r352239: install failure: make[10]: exec(btxld) failed (No such file or directory)
Hello, we install several pkg-based systems and poudriere from a dedicated tree of sources, instead of /usr/src it is in our case /pool/sources/CURRENT/src and 12-STABLE/src. Compilation of the sources is done within a JAIL! For a couple of days now, both trees, CURRENT (r352239 now) and 12-STABLE (r352239) fail at the exact same point, when compiling and further packaging: [...] install -U -M /pool/sources/CURRENT/obj/pool/sources/CURRENT/src/amd64.amd64/worldstage//METALOG -D /pool/sources/CURRENT/obj/pool/sources/CURRENT/src/amd64.amd64/worldstage -T package=utilities -d -m 0755 -o root -g wheel /pool/sources/CURRENT/obj/pool/sources/CURRENT/src/amd64.amd64/worldstage/boot objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x2000 -f bin -b /pool/sources/CURRENT/obj/pool/sources/CURRENT/src/amd64.amd64/stand/i386/btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin make[10]: exec(btxld) failed (No such file or directory) *** Error code 1 [...] For reduction of the installed binaries and stuff, we use customized src.conf and each build process is delegated to its appropriate src.conf by setting the variabel SRCCONF accordingly; poudriere also uses the same src.conf by linking the jailname-src.conf file into poudriere's config folder; the content of src.conf is as follows: [...] WITH_OFED= YES #WITH_CTF= YES # #WITH_BEARSSL= YES # WITH_SVN= YES # WITH_SORT_THREADS= YES # MALLOC_PRODUCTION= YES # #WITHOUT_ASSERT_DEBUG= YES #WITHOUT_DEBUG_FILES=YES #WITHOUT_TESTS= YES WITHOUT_PROFILE=YES # WITHOUT_REPRODUCIBLE_BUILD= YES # # mitigation for CVE-2017-5715 in the kernel build WITH_RETPOLINE= YES [...] Building poudriere jails from such sources also fails since a couple of days on all platforms with a weird message thata folder and/or file atf-check is missing (this happens when using command sequence: poudriere jail -j jailname -u -b and the install method of the appropriate jail is src=/path/to/source/src. Thanks for helping, oh ___ 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"
FreeBSD CI Weekly Report 2019-09-08
(Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2019-09-08 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2019-09-02 to 2019-09-08. During this period, we have: * 2122 builds (99.4% (+2) passed, 0.6% (-2) failed) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 373 test runs (59.6% (-0.2) passed, 39.1% (-1.1) unstable, 1.3% (+1.3) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 50 doc builds (100% (+2) passed) Test case status (on 2019-09-08 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | --- | -- | -- | - | | | head/amd64 | 7556 (+6) | 7495 (+11) | 0 (-1)| 61 (-4) | | head/i386 | 7554 (+6) | 7484 (+7) | 2 (0) | 68 (-1) | | 12-STABLE/amd64 | 7393 (+1) | 7341 (-7) | 11 (+11) | 41 (-3) | | 12-STABLE/i386 | 7391 (+1) | 7329 (-10) | 11 (+11) | 51 (0) | | 11-STABLE/amd64 | 6846 (+1) | 6802 (+4) | 0 (0) | 44 (-3) | | 11-STABLE/i386 | 6844 (+1) | 6767 (-7) | 34 (0)| 43 (-6) | (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-20190908 and archive is available at https://hackmd.io/@FreeBSD-CI/, any help is welcome. ## News * Weekly CI report archive has been moved to https://hackmd.io/@FreeBSD-CI * [FCP 20190401-ci_policy: CI policy](https://github.com/freebsd/fcp/blob/master/fcp-20190401-ci_policy.md) is in "feedback" state, please check and provide comments on -fcp@ and -hackers@ mailing lists. ## Fixed Tests * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/ * (flakey) usr.bin.procstat.procstat_test.environment * (flakey) usr.bin.procstat.procstat_test.command_line_arguments Fixed in https://svnweb.freebsd.org/changeset/base/351819 ## Failing Tests * https://ci.freebsd.org/job/FreeBSD-stable-12-amd64-test/ * https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/ * sys.netipsec.tunnel.aes_cbc_128_hmac_sha1.v6 * sys.netipsec.tunnel.aes_cbc_256_hmac_sha2_256.v6 * sys.netipsec.tunnel.aes_gcm_128.v6 * sys.netipsec.tunnel.aes_gcm_256.v6 * sys.netipsec.tunnel.aesni_aes_cbc_128_hmac_sha1.v6 * sys.netipsec.tunnel.aesni_aes_cbc_256_hmac_sha2_256.v6 * sys.netipsec.tunnel.aesni_aes_gcm_128.v6 * sys.netipsec.tunnel.aesni_aes_gcm_256.v6 * sys.netipsec.tunnel.empty.v6 * sys.netpfil.pf.fragmentation.v6 * sys.netpfil.pf.pass_block.v6 * https://bugs.freebsd.org/240511 * https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/ * local.kyua.* (31 cases) * local.lutok.* (3 cases) ## 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 * cddl.usr.sbin.dtrace.amd64.arrays.t_dtrace_contrib.tst_uregsarray_d * https://bugs.freebsd.org/240358 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~60 failing cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details ## Disabled Tests * lib.libc.sys.mmap_test.mmap_truncate_signal https://bugs.freebsd.org/211924 Patch available: https://reviews.freebsd.org/D21566 * 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 (new) 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.netpfil.pf.forward.v4 (i386 only) * sys.netpfil.pf.forward.v6 (i386 only) * sys.netpfil.pf.set_tos.v4 (i386 only) https://bugs.freebsd.org/239380 (updating net/scapy to 2.4.3 may fix this) * 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
Re: "cpuset -n prefer:?" --what values for "?" are supposed to be allowed? (only 1 is, despite two numa domains)
On 2019-Sep-11, at 10:11, Mark Millard wrote:
> On 2019-Sep-11, at 08:15, Mark Johnston wrote:
>
>> On Wed, Sep 11, 2019 at 07:57:26AM -0700, Mark Millard wrote:
>>>
>>>
>>> On 2019-Sep-11, at 07:31, Mark Johnston wrote:
>>>
On Tue, Sep 10, 2019 at 10:58:05PM -0700, Mark Millard wrote:
> In a context with:
>
> # cpuset -g
> pid -1 mask: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16,
> 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27
> pid -1 domain policy: first-touch mask: 0, 1
>
> I get:
>
> # cpuset -l0 -n prefer:0 COMMAND
> cpuset: setdomain: Invalid argument
>
> # cpuset -l0 -n prefer:2 COMMAND
> cpuset: setdomain: Invalid argument
>
> But one prefer:? value does allow the COMMAND
> to run:
>
> # cpuset -l0 -n prefer:1 COMMAND
>
> This seem odd to me. Am I missing something?
>
> For reference: I'm using a ThreadRipper 1950X
> with a head -r351227 based context for this
> activity. The above happens to have been run
> in a Windows 10 Pro HyperV session, instead
> of in a native-boot of the same media. (A
> native-boot would have had 32 CPUs.)
Can you please show the output of "sysctl vm.phys_segs" from this
setup?
>>>
>>> Sure:
>>
>> I was wondering if you had only one domain populated, but it seems not
>> to be the case. Could you try updating to r351672 or later and see if
>> the behaviour persists?
>
> It may be a bit before I do that.
>
> FYI: I had set MAXMEMDOM to match the number of
> actual domains for the context:
>
> /usr/src/sys/amd64/conf/GENERIC-DBG:options MAXMEMDOM=2
> /usr/src/sys/amd64/conf/GENERIC-NODBG:options MAXMEMDOM=2
>
> (These kernel configuration files include GENERIC.)
Not that the below is the problem that I reported, but
cpuset_modify_domain has an oddity. In the below, note
the "root->" use followed by the "root &&" test: the
root-> use would have failed first. Should the && be
"dset &&" instead? Should "root &&" just be removed for
being redundant?
793 root = cpuset_getroot(set);
794 mtx_lock_spin(_lock);
795 dset = root->cs_domain;
796 /*
797 * Verify that we have access to this set of domains.
798 */
799 if (root && !domainset_valid(dset, domain)) {
800 error = EINVAL;
801 goto out;
802 }
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
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: "cpuset -n prefer:?" --what values for "?" are supposed to be allowed? (only 1 is, despite two numa domains)
On 2019-Sep-11, at 08:15, Mark Johnston wrote: > On Wed, Sep 11, 2019 at 07:57:26AM -0700, Mark Millard wrote: >> >> >> On 2019-Sep-11, at 07:31, Mark Johnston wrote: >> >>> On Tue, Sep 10, 2019 at 10:58:05PM -0700, Mark Millard wrote: In a context with: # cpuset -g pid -1 mask: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27 pid -1 domain policy: first-touch mask: 0, 1 I get: # cpuset -l0 -n prefer:0 COMMAND cpuset: setdomain: Invalid argument # cpuset -l0 -n prefer:2 COMMAND cpuset: setdomain: Invalid argument But one prefer:? value does allow the COMMAND to run: # cpuset -l0 -n prefer:1 COMMAND This seem odd to me. Am I missing something? For reference: I'm using a ThreadRipper 1950X with a head -r351227 based context for this activity. The above happens to have been run in a Windows 10 Pro HyperV session, instead of in a native-boot of the same media. (A native-boot would have had 32 CPUs.) >>> >>> Can you please show the output of "sysctl vm.phys_segs" from this >>> setup? >> >> Sure: > > I was wondering if you had only one domain populated, but it seems not > to be the case. Could you try updating to r351672 or later and see if > the behaviour persists? It may be a bit before I do that. FYI: I had set MAXMEMDOM to match the number of actual domains for the context: /usr/src/sys/amd64/conf/GENERIC-DBG:options MAXMEMDOM=2 /usr/src/sys/amd64/conf/GENERIC-NODBG:options MAXMEMDOM=2 (These kernel configuration files include GENERIC.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ 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: "cpuset -n prefer:?" --what values for "?" are supposed to be allowed? (only 1 is, despite two numa domains)
On Wed, Sep 11, 2019 at 07:57:26AM -0700, Mark Millard wrote: > > > On 2019-Sep-11, at 07:31, Mark Johnston wrote: > > > On Tue, Sep 10, 2019 at 10:58:05PM -0700, Mark Millard wrote: > >> In a context with: > >> > >> # cpuset -g > >> pid -1 mask: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, > >> 18, 19, 20, 21, 22, 23, 24, 25, 26, 27 > >> pid -1 domain policy: first-touch mask: 0, 1 > >> > >> I get: > >> > >> # cpuset -l0 -n prefer:0 COMMAND > >> cpuset: setdomain: Invalid argument > >> > >> # cpuset -l0 -n prefer:2 COMMAND > >> cpuset: setdomain: Invalid argument > >> > >> But one prefer:? value does allow the COMMAND > >> to run: > >> > >> # cpuset -l0 -n prefer:1 COMMAND > >> > >> This seem odd to me. Am I missing something? > >> > >> For reference: I'm using a ThreadRipper 1950X > >> with a head -r351227 based context for this > >> activity. The above happens to have been run > >> in a Windows 10 Pro HyperV session, instead > >> of in a native-boot of the same media. (A > >> native-boot would have had 32 CPUs.) > > > > Can you please show the output of "sysctl vm.phys_segs" from this > > setup? > > Sure: I was wondering if you had only one domain populated, but it seems not to be the case. Could you try updating to r351672 or later and see if the behaviour persists? ___ 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: "cpuset -n prefer:?" --what values for "?" are supposed to be allowed? (only 1 is, despite two numa domains)
On 2019-Sep-11, at 07:31, Mark Johnston wrote: > On Tue, Sep 10, 2019 at 10:58:05PM -0700, Mark Millard wrote: >> In a context with: >> >> # cpuset -g >> pid -1 mask: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, >> 18, 19, 20, 21, 22, 23, 24, 25, 26, 27 >> pid -1 domain policy: first-touch mask: 0, 1 >> >> I get: >> >> # cpuset -l0 -n prefer:0 COMMAND >> cpuset: setdomain: Invalid argument >> >> # cpuset -l0 -n prefer:2 COMMAND >> cpuset: setdomain: Invalid argument >> >> But one prefer:? value does allow the COMMAND >> to run: >> >> # cpuset -l0 -n prefer:1 COMMAND >> >> This seem odd to me. Am I missing something? >> >> For reference: I'm using a ThreadRipper 1950X >> with a head -r351227 based context for this >> activity. The above happens to have been run >> in a Windows 10 Pro HyperV session, instead >> of in a native-boot of the same media. (A >> native-boot would have had 32 CPUs.) > > Can you please show the output of "sysctl vm.phys_segs" from this > setup? Sure: # sysctl vm.phys_segs vm.phys_segs: SEGMENT 0: start: 0x1000 end: 0x9f000 domain:0 free list: 0x8281daa0 SEGMENT 1: start: 0x103000 end: 0x100 domain:0 free list: 0x8281daa0 SEGMENT 2: start: 0x100 end: 0x2ee1000 domain:0 free list: 0x8281d830 SEGMENT 3: start: 0x2eea000 end: 0x2f23000 domain:0 free list: 0x8281d830 SEGMENT 4: start: 0x300 end: 0xf7ff domain:0 free list: 0x8281d830 SEGMENT 5: start: 0x12000 end: 0x9c5562000 domain:0 free list: 0x8281d5c0 SEGMENT 6: start: 0xa07c0 end: 0xa07d5 domain:0 free list: 0x8281d5c0 SEGMENT 7: start: 0xa08001000 end: 0xf9ee0 domain:1 free list: 0x8281dd10 SEGMENT 8: start: 0x10 end: 0x1427fe6000 domain:1 free list: 0x8281dd10 And confirming the oddity is still the case (I'd rebooted since the report): # cpuset -g pid -1 mask: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27 pid -1 domain policy: first-touch mask: 0, 1 # cpuset -l0 -n prefer:0 COMMAND cpuset: setdomain: Invalid argument # cpuset -l0 -n prefer:2 COMMAND cpuset: setdomain: Invalid argument # cpuset -l0 -n prefer:1 COMMAND cpuset: COMMAND: No such file or directory === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ 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: "cpuset -n prefer:?" --what values for "?" are supposed to be allowed? (only 1 is, despite two numa domains)
On Tue, Sep 10, 2019 at 10:58:05PM -0700, Mark Millard wrote: > In a context with: > > # cpuset -g > pid -1 mask: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, > 18, 19, 20, 21, 22, 23, 24, 25, 26, 27 > pid -1 domain policy: first-touch mask: 0, 1 > > I get: > > # cpuset -l0 -n prefer:0 COMMAND > cpuset: setdomain: Invalid argument > > # cpuset -l0 -n prefer:2 COMMAND > cpuset: setdomain: Invalid argument > > But one prefer:? value does allow the COMMAND > to run: > > # cpuset -l0 -n prefer:1 COMMAND > > This seem odd to me. Am I missing something? > > For reference: I'm using a ThreadRipper 1950X > with a head -r351227 based context for this > activity. The above happens to have been run > in a Windows 10 Pro HyperV session, instead > of in a native-boot of the same media. (A > native-boot would have had 32 CPUs.) Can you please show the output of "sysctl vm.phys_segs" from this setup? ___ 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"
ixv + RSS
Has anyone ever tested a kernel with option RSS and an ixv interface? Just looking for some data points. Thanks! -- Andriy Gapon ___ 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: "cpuset -n prefer:?" --what values for "?" are supposed to be allowed? (only 1 is, despite two numa domains)
Mark, this is what I get on my machine: root@new:~ # cpuset -g pid -1 mask: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 pid -1 domain policy: first-touch mask: 0 root@new:~ # cpuset -l0 -n prefer:0 COMMAND cpuset: COMMAND: No such file or directory root@new:~ # cpuset -l0 -n prefer:2 COMMAND cpuset: setdomain: Invalid argument root@new:~ # cpuset -l0 -n prefer:1 COMMAND cpuset: setdomain: Invalid argument >From dmesg: FreeBSD 13.0-CURRENT r351901 GENERIC amd64 CPU: AMD Ryzen 7 3700X 8-Core Processor(3600.08-MHz K8-class CPU) Similar, Clay On Wed, Sep 11, 2019 at 12:58 AM Mark Millard wrote: > In a context with: > > # cpuset -g > pid -1 mask: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, > 18, 19, 20, 21, 22, 23, 24, 25, 26, 27 > pid -1 domain policy: first-touch mask: 0, 1 > > I get: > > # cpuset -l0 -n prefer:0 COMMAND > cpuset: setdomain: Invalid argument > > # cpuset -l0 -n prefer:2 COMMAND > cpuset: setdomain: Invalid argument > > But one prefer:? value does allow the COMMAND > to run: > > # cpuset -l0 -n prefer:1 COMMAND > > This seem odd to me. Am I missing something? > > For reference: I'm using a ThreadRipper 1950X > with a head -r351227 based context for this > activity. The above happens to have been run > in a Windows 10 Pro HyperV session, instead > of in a native-boot of the same media. (A > native-boot would have had 32 CPUs.) > > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > ___ > 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" > ___ 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"
