Re: wrong value from DTRACE (uint32 for int64)
On Mon, 02 Dec 2019 21:58:36 +0100, Mark Johnston wrote: The DTRACE_PROBE* macros cast their parameters to uintptr_t, which will be 32 bits wide on i386. You might be able to work around the problem by casting arg0 to uint32_t in the script. Thanks for the info - good that it has a logical explanation. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD CI Weekly Report 2019-12-01
(Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2019-12-01 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2019-11-25 to 2019-12-01. During this period, we have: * 2134 builds (96.3% (+1.2) passed, 3.7% (-1.2) 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. * 283 test runs (97.5% (+14.4) passed, 2.5% (-6.4) unstable, 0% (-8) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 22 doc builds (100% (0) passed) Test case status (on 2019-12-01 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | --- | - | - | - | --- | | head/amd64 | 7620 (+2) | 7554 (+2) | 0 (0) | 66 (0) | | head/i386 | 7618 (+2) | 7548 (+2) | 0 (0) | 70 (0) | | 12-STABLE/amd64 | 7483 (0) | 7432 (-3) | 0 (0) | 51 (+3) | | 12-STABLE/i386 | 7481 (0) | 7426 (0) | 0 (0) | 55 (0) | | 11-STABLE/amd64 | 6853 (0) | 6806 (+3) | 0 (0) | 47 (-3) | | 11-STABLE/i386 | 6851 (0) | 6802 (+3) | 0 (0) | 49 (-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-20191201 and archive is available at https://hackmd.io/@FreeBSD-CI/, any help is welcome. ## News * A new wiki page started at https://wiki.freebsd.org/Jenkins/Debug describes how to reproduce and debug the failing cases. It is welcomed to add more contents. * A list of "FreeBSD CI Tasks and Ideas" is keeping at https://hackmd.io/@FreeBSD-CI/freebsd-ci-todo , please contact freebsd-test...@freebsd.org and lw...@freebsd.org if you are interested or have new ideas. * Experimental "Hardware test lab" result is available at: https://ci.freebsd.org/hwlab/ , more hardware support is welcomed! * We are collecting information of FreeBSD in software development, for future collaboration. The wiki page is https://wiki.freebsd.org/3rdPartySoftwareCI , plese help adding more information. ## 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 ~14 failing and ~100 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 (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.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.synpr
FreeBSD CI Weekly Report 2019-11-24
(Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2019-11-24 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2019-11-18 to 2019-11-24. During this period, we have: * 2617 builds (95.1% (+3.9) passed, 4.9% (-3.9) 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. * 349 test runs (83.1% (-14.8) passed, 8.9% (-6.8) unstable, 8.0% (+8) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 48 doc builds (100% (0) passed) Test case status (on 2019-11-24 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | --- | - | - | - | --- | | head/amd64 | 7618 (+7) | 7552 (+6) | 0 (0) | 66 (+1) | | head/i386 | 7616 (+7) | 7546 (+9) | 0 (0) | 70 (-2) | | 12-STABLE/amd64 | 7483 (0) | 7435 (0) | 0 (0) | 48 (0) | | 12-STABLE/i386 | 7481 (0) | 7426 (+3) | 0 (0) | 55 (-3) | | 11-STABLE/amd64 | 6853 (0) | 6803 (-3) | 0 (0) | 50 (+3) | | 11-STABLE/i386 | 6851 (0) | 6799 (0) | 0 (0) | 52 (0) | (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-20191124 and archive is available at https://hackmd.io/@FreeBSD-CI/, any help is welcome. ## News * A new wiki page started at https://wiki.freebsd.org/Jenkins/Debug describes how to reproduce and debug the failing cases. It is welcomed to add more contents. * A list of "FreeBSD CI Tasks and Ideas" is keeping at https://hackmd.io/@FreeBSD-CI/freebsd-ci-todo , please contact freebsd-test...@freebsd.org and lw...@freebsd.org if you are interested or have new ideas. * Experimental "Hardware test lab" result is available at: https://ci.freebsd.org/hwlab/ , more hardware support is welcomed! * We are collecting information of FreeBSD in software development, for future collaboration. The wiki page is https://wiki.freebsd.org/3rdPartySoftwareCI , plese help adding more information. ## Fixed tests * https://bugs.freebsd.org/242095 failing test case: usr.bin.unifdef.basic_test.basic ## 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 ~100 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 (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.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 ker
FreeBSD CI Weekly Report 2019-11-17
(Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2019-11-17 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2019-11-11 to 2019-11-17. During this period, we have: * 2174 builds (91.2% (-3.7) passed, 8.8% (+3.7) 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. * 331 test runs (97.9% (+5.8) passed, 2.1% (-4.3) unstable, 0% (-1.5) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 30 doc builds (100% passed) Test case status (on 2019-11-17 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | --- | - | - | - | --- | | head/amd64 | 7611 (0) | 7546 (+3) | 0 (0) | 65 (-3) | | head/i386 | 7609 (0) | 7537 (-3) | 0 (0) | 72 (+3) | | 12-STABLE/amd64 | 7483 (0) | 7435 (0) | 0 (0) | 48 (0) | | 12-STABLE/i386 | 7481 (0) | 7423 (-3) | 0 (0) | 58 (+3) | | 11-STABLE/amd64 | 6853 (+4) | 6806 (+4) | 0 (0) | 47 (0) | | 11-STABLE/i386 | 6851 (+4) | 6799 (+1) | 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-20191117 and archive is available at https://hackmd.io/@FreeBSD-CI/, any help is welcome. ## News * A new wiki page started at https://wiki.freebsd.org/Jenkins/Debug describes how to reproduce and debug the failing cases. It is welcomed to add more contents. * A list of "FreeBSD CI Tasks and Ideas" is keeping at https://hackmd.io/@FreeBSD-CI/freebsd-ci-todo , please contact freebsd-test...@freebsd.org and lw...@freebsd.org if you are interested or have new ideas. * Experimental "Hardware test lab" result is available at: https://ci.freebsd.org/hwlab/ , more hardware support is welcomed! * We are collecting information of FreeBSD in software development, for future collaboration. The wiki page is https://wiki.freebsd.org/3rdPartySoftwareCI , plese help adding more information. ## 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 ~7 failing and ~100 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 (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.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
Re: wrong value from DTRACE (uint32 for int64)
On Mon, Dec 02, 2019 at 08:44:59PM +0100, Peter wrote:
> Hi @all,
>
> I felt the need to look into my ZFS ARC, but DTRACE provided misleading
> (i.e., wrong) output (on i386, 11.3-RELEASE):
>
> # dtrace -Sn 'arc-available_memory { printf("%x %x", arg0, arg1); }'
> DIFO 0x286450a0 returns D type (integer) (size 8)
> OFF OPCODE INSTRUCTION
> 00: 29010601ldgs DT_VAR(262), %r1 ! DT_VAR(262) = "arg0"
> 01: 2301ret %r1
>
> NAME ID KND SCP FLAG TYPE
> arg0 262 scl glb rD type (integer) (size 8)
>
> DIFO 0x286450f0 returns D type (integer) (size 8)
> OFF OPCODE INSTRUCTION
> 00: 29010701ldgs DT_VAR(263), %r1 ! DT_VAR(263) = "arg1"
> 01: 2301ret %r1
>
> NAME ID KND SCP FLAG TYPE
> arg1 263 scl glb rD type (integer) (size 8)
> dtrace: description 'arc-available_memory ' matched 1 probe
>0 14none:arc-available_memory 2fb000 2
>0 14none:arc-available_memory 4e000 2
>1 14none:arc-available_memory b000 2
>1 14none:arc-available_memory b000 2
>1 14none:arc-available_memory b000 2
>1 14none:arc-available_memory 19000 2
>0 14none:arc-available_memory d38000 2
>
> # dtrace -n 'arc-available_memory { printf("%d %d", arg0, arg1); }'
>1 14none:arc-available_memory 81920 5
>1 14none:arc-available_memory 69632 5
>1 14none:arc-available_memory 4294955008 5
>1 14none:arc-available_memory 4294955008 5
>
>
> The arg0 Variable is shown here obviousely as an unsigned int32 value. But
> in fact, the probe in the sourcecode in arc.c is a signed int64:
>
> DTRACE_PROBE2(arc__available_memory, int64_t, lowest, int, r);
>
>
> User @shkhin in the forum pointed me to check the bare dtrace program,
> unattached to the kernel code:
> https://forums.freebsd.org/threads/dtrace-treats-int64_t-as-uint32_t-on-i386.73223/post-446517
>
> And there everything appears correct.
>
> So two questions:
> 1. can anybody check and confirm this happening?
> 2. any idea what could be wrong here? (The respective variable in arc.c
> bears the correct 64bit negative value, I checked that - and otherwise the
> ARC couldn't shrink.)
The DTRACE_PROBE* macros cast their parameters to uintptr_t, which
will be 32 bits wide on i386. You might be able to work around the
problem by casting arg0 to uint32_t in the script.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
wrong value from DTRACE (uint32 for int64)
Hi @all,
I felt the need to look into my ZFS ARC, but DTRACE provided misleading
(i.e., wrong) output (on i386, 11.3-RELEASE):
# dtrace -Sn 'arc-available_memory { printf("%x %x", arg0, arg1); }'
DIFO 0x286450a0 returns D type (integer) (size 8)
OFF OPCODE INSTRUCTION
00: 29010601ldgs DT_VAR(262), %r1 ! DT_VAR(262) = "arg0"
01: 2301ret %r1
NAME ID KND SCP FLAG TYPE
arg0 262 scl glb rD type (integer) (size 8)
DIFO 0x286450f0 returns D type (integer) (size 8)
OFF OPCODE INSTRUCTION
00: 29010701ldgs DT_VAR(263), %r1 ! DT_VAR(263) = "arg1"
01: 2301ret %r1
NAME ID KND SCP FLAG TYPE
arg1 263 scl glb rD type (integer) (size 8)
dtrace: description 'arc-available_memory ' matched 1 probe
0 14none:arc-available_memory 2fb000 2
0 14none:arc-available_memory 4e000 2
1 14none:arc-available_memory b000 2
1 14none:arc-available_memory b000 2
1 14none:arc-available_memory b000 2
1 14none:arc-available_memory 19000 2
0 14none:arc-available_memory d38000 2
# dtrace -n 'arc-available_memory { printf("%d %d", arg0, arg1); }'
1 14none:arc-available_memory 81920 5
1 14none:arc-available_memory 69632 5
1 14none:arc-available_memory 4294955008 5
1 14none:arc-available_memory 4294955008 5
The arg0 Variable is shown here obviousely as an unsigned int32 value. But
in fact, the probe in the sourcecode in arc.c is a signed int64:
DTRACE_PROBE2(arc__available_memory, int64_t, lowest, int, r);
User @shkhin in the forum pointed me to check the bare dtrace program,
unattached to the kernel code:
https://forums.freebsd.org/threads/dtrace-treats-int64_t-as-uint32_t-on-i386.73223/post-446517
And there everything appears correct.
So two questions:
1. can anybody check and confirm this happening?
2. any idea what could be wrong here? (The respective variable in arc.c
bears the correct 64bit negative value, I checked that - and otherwise the
ARC couldn't shrink.)
rgds,
PMc
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: rev 355285 breaks stable build
Fixed by rev. 355290 > On 2 Dec 2019, at 16:21, peter.b...@bsd4all.org wrote: > > Hi, > > While building rescue > > ld: error: undefined symbol: lz4_init referenced by spa_misc.c:2066 (/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c:2066) spa_misc.o:(spa_init) in archive /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libzpool.a > > ld: error: undefined symbol: lz4_fini referenced by spa_misc.c:2096 (/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c:2096) spa_misc.o:(spa_fini) in archive /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libzpool.a > cc: error: linker command failed with exit code 1 (use -v to see invocation) > *** [rescue] Error code 1 > > Peter > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
rev 355285 breaks stable build
Hi, While building rescue ld: error: undefined symbol: lz4_init >>> referenced by spa_misc.c:2066 >>> (/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c:2066) >>> spa_misc.o:(spa_init) in archive >>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libzpool.a ld: error: undefined symbol: lz4_fini >>> referenced by spa_misc.c:2096 >>> (/usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa_misc.c:2096) >>> spa_misc.o:(spa_fini) in archive >>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libzpool.a cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [rescue] Error code 1 Peter ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Slow zfs destroy
02.12.2019 20:35, Andriy Gapon wrote: > On 02/12/2019 11:27, Scott Bennett wrote: >> The vast majority of my "destroy" operations are for snapshots, but what >> I have seen is that, without the "-d", the command does not return until the >> disk activity of the "destroy" finishes, but with the "-d", it returns within >> a couple of seconds,--i.e., just long enough to get the operation going--and >> the disk I/Os continue until the work is done and free space in the pool >> increases >> until the I/Os stop. >> Perhaps the man pages for zfs(8) and zpool-features(7) need some >> modification/ >> clarification on this matter. > > I don't know how to explain what you see, but the manual pages are correct. > -d has nothing to do with asynchronous destroy which is automatic (when > enabled). It seems that "zfs destroy" writes and/or removes large enough amount of data to spend lots of time before return when TRIM performance is bad. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Slow zfs destroy
Eugene Grosbein wrote: > 30.11.2019 0:57, Scott Bennett wrote: > > > On Thu, 28 Nov 2019 23:18:37 +0700 Eugene Grosbein > > wrote: > > > >> 28.11.2019 20:34, Steven Hartland wrote: > >> > >>> It may well depend on the extent of the deletes occurring. > >>> > >>> Have you tried disabling TRIM to see if it eliminates the delay? > >> > >> This system used mfi(4) first and mfi(4) does not support TRIM at all. > >> Performance was abysmal. > >> Now it uses mrsas(4) and after switch I ran trim(8) for all SSDs > >> one-by-one then re-added them to RAID1. > >> Disabling TRIM is not an option. > >> > >> Almost a year has passed since then and I suspect SSDs have no or a few > >> spare trimmed cells for some reason. > >> Is there documented way to check this out? Maybe some SMART attribute? > >> > > You neglected to state whether you used "zfs destroy datasetname" or > > "zfs destroy -d datasetname". If you used the former, then ZFS did what > > you told it to do. If you want the data set destroyed in the background, > > you will need to include the "-d" option in the command. (See the zfs(1) > > man page at defer_destroy under "Native Properties".) > > The manual says "zfs destroy -d" is not for "background" but for "deferred". > The "zfs destroy" without -d would return EBUSY for a snapshot on hold (zfs > hold) > or bound with a clone, but "zfs destroy -d" would mark the snapshot for later > destruction > in a moment the clone is deleted or user lock (hold) is lifted. > Until then the snapshot still usable and destruction does not happen. > > All my snapshots are free from holds or clones and can be deleted, > so "zfs destroy -d" is equal to "zfs destroy" for them. > What you say is true, and I have seen it accept a "zfs destroy -d" for a held snapshot but do nothing until the hold is released, whereupon the "destroy" begins. However, that cannot be the whole story because... The vast majority of my "destroy" operations are for snapshots, but what I have seen is that, without the "-d", the command does not return until the disk activity of the "destroy" finishes, but with the "-d", it returns within a couple of seconds,--i.e., just long enough to get the operation going--and the disk I/Os continue until the work is done and free space in the pool increases until the I/Os stop. Perhaps the man pages for zfs(8) and zpool-features(7) need some modification/ clarification on this matter. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: UEFI ISO boot not working in 12.1 ?
Am 09.11.2019 um 18:24 schrieb Kyle Evans:
On Sat, Nov 9, 2019 at 10:42 AM Chris Ross wrote:
On Thu, Nov 07, 2019 at 02:53:25PM -0500, Chris Ross wrote:
On Thu, Nov 7, 2019 at 9:46 AM Julian Elischer wrote:
You could try some bisection back along the 12 branch..
Yeah. I was hoping for an easier path, but. I can try slogging back
through stable-12 a month or two at a time.
Okay. I spent a bunch of time moving around stable-12 by date, and
an ISO build from stable-12 as of 2019-10-14 works (rev 353483), and
2019-10-15 (rev 353541) does not.
…
That helps- thanks! I'm CC'ing tsoome@, as this is basically just
r353501 in that range. Can you give the latest -CURRENT snapshot boot
as another data point?
I can confirm that reverting r353501 on stable/12 from yesterday solves
my problem with booting the setup media.
(My symptoms on ESXi 6.7 guest using SATA vODD: r355263 loads
kernel/modules but stucks with 100%CPU while trying to hand over to kernel)
My svn skills are as lousy as my C skills, but to me it seems like a
mismerge.
The attached patch (against r355263, stable/12 from yesterday _without_
reverting r353501!) solves my problem.
But please could someone familiar with svn&code inspect what happened
and verify/correct/commit the fix.
Solving my problem doesn't mean my approach is correct. I don't know
HandleProtocol() nor OpenProtocol() nor did I read the code trying to
understand what's happening in "proto.c".
I just text-edited a obvious cannotbe… Maby I missed a lot of things…
In case attachment won't make it to the list (white space nits to be
expected):
Index: stand/efi/boot1/proto.c
===
--- stand/efi/boot1/proto.c (Revision 355263)
+++ stand/efi/boot1/proto.c (Arbeitskopie)
@@ -61,7 +61,7 @@
int preferred;
/* Figure out if we're dealing with an actual partition. */
- status = BS->HandleProtocol(h, &DevicePathGUID, (void **)&devpath);
+ status = OpenProtocolByHandle(h, &DevicePathGUID, (void
**)&devpath);
if (status == EFI_UNSUPPORTED)
return (0);
@@ -77,7 +77,7 @@
efi_free_devpath_name(text);
}
#endif
- status = BS->HandleProtocol(h, &BlockIoProtocolGUID, (void
**)&blkio);
+ status = OpenProtocolByHandle(h, &BlockIoProtocolGUID, (void
**)&blkio);
if (status == EFI_UNSUPPORTED)
return (0);
Index: stand/efi/gptboot/proto.c
===
--- stand/efi/gptboot/proto.c (Revision 355263)
+++ stand/efi/gptboot/proto.c (Arbeitskopie)
@@ -146,7 +146,7 @@
EFI_STATUS status;
/* Figure out if we're dealing with an actual partition. */
- status = BS->HandleProtocol(h, &DevicePathGUID, (void **)&devpath);
+ status = OpenProtocolByHandle(h, &DevicePathGUID, (void
**)&devpath);
if (status != EFI_SUCCESS)
return;
#ifdef EFI_DEBUG
@@ -169,7 +169,7 @@
return;
}
}
- status = BS->HandleProtocol(h, &BlockIoProtocolGUID, (void
**)&blkio);
+ status = OpenProtocolByHandle(h, &BlockIoProtocolGUID, (void
**)&blkio);
if (status != EFI_SUCCESS) {
DPRINTF("Can't get the block I/O protocol block\n");
return;
But reading this thread leaves one question:
Does 12.1-RELEASE refuse to boot on regular ESXi UEFI guests!?
Thanks,
-Harry
(resent due to ?expired? subscription…; original message was addressed
to all other recipients)
Index: stand/efi/boot1/proto.c
===
--- stand/efi/boot1/proto.c (Revision 355263)
+++ stand/efi/boot1/proto.c (Arbeitskopie)
@@ -61,7 +61,7 @@
int preferred;
/* Figure out if we're dealing with an actual partition. */
- status = BS->HandleProtocol(h, &DevicePathGUID, (void **)&devpath);
+ status = OpenProtocolByHandle(h, &DevicePathGUID, (void **)&devpath);
if (status == EFI_UNSUPPORTED)
return (0);
@@ -77,7 +77,7 @@
efi_free_devpath_name(text);
}
#endif
- status = BS->HandleProtocol(h, &BlockIoProtocolGUID, (void **)&blkio);
+ status = OpenProtocolByHandle(h, &BlockIoProtocolGUID, (void **)&blkio);
if (status == EFI_UNSUPPORTED)
return (0);
Index: stand/efi/gptboot/proto.c
===
--- stand/efi/gptboot/proto.c (Revision 355263)
+++ stand/efi/gptboot/proto.c (Arbeitskopie)
@@ -146,7 +146,7 @@
EFI_STATUS status;
/* Figure out if we're dealing with an actual partition. */
- status = BS->HandleProtocol(h, &DevicePathGUID, (void **)&devpath);
+ status = OpenProtocolByHandle(h, &DevicePathGUID, (void **)&devpath);
if (status != EFI_SUCCESS)
return;
#ifdef EFI_DEBUG
@@ -169,7 +169,7 @@
return;
}
}
- status = BS->HandleProtocol(h, &BlockIoProtocolGUID, (void **)&blkio);
+ status = OpenProtocolBy
