Re: wrong value from DTRACE (uint32 for int64)

2019-12-02 Thread Peter
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

FreeBSD CI Weekly Report 2019-12-01

2019-12-02 Thread Li-Wen Hsu
(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

FreeBSD CI Weekly Report 2019-11-24

2019-12-02 Thread Li-Wen Hsu
(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

FreeBSD CI Weekly Report 2019-11-17

2019-12-02 Thread Li-Wen Hsu
(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

Re: wrong value from DTRACE (uint32 for int64)

2019-12-02 Thread Mark Johnston
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

wrong value from DTRACE (uint32 for int64)

2019-12-02 Thread Peter
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: 29010601

Re: rev 355285 breaks stable build

2019-12-02 Thread peter . blok
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)

rev 355285 breaks stable build

2019-12-02 Thread peter . blok
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:

Re: Slow zfs destroy

2019-12-02 Thread Eugene Grosbein
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

Re: Slow zfs destroy

2019-12-02 Thread Scott Bennett
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

Re: UEFI ISO boot not working in 12.1 ?

2019-12-02 Thread Harry Schmalzbauer
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