Livelock on recent current

2020-09-08 Thread Kevin Oberman 
I am seeing a problem since I moved to current on my laptop this week. It's
odd as it is linked to the keyboard. As long as the keyboard is active,
everything is fine, but if the keyboard is not used, after a few minutes,
it locks up and gets very hot. The system may be busy or idle. The system
seems completely locked. It does not respond in the network and the
display, X or just vt is frozen. The only factor is use of the keyboard.

I'm not sure what information I might collect.

The system is a ThinkPad L15 with 4GN of DRAMM (more on order) .
FreeBSD 13.0-CURRENT #2 r365481M: Tue Sep  8 20:16:02 PDT 2020
root@ptavv:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64
FreeBSD ptavv 13.0-CURRENT FreeBSD 13.0-CURRENT #2 r365481M: Tue Sep  8
20:16:02 PDT 2020
root@ptavv:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
 amd64
Intel(R) Core(TM) i5-10210U CPU (Crystal Lake)
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: OpenZFS and L2ARC

2020-09-08 Thread Graham Perrin 

On 08/09/2020 08:43, Stefan Esser wrote:
OpenZFS seems to work quite well for me, in general, but I have 
questions regarding the L2ARC statistics.



…


The sysutils/zfs-stats port reports the following values for
this system, BTW:


ZFS Subsystem Report    Tue Sep  8 09:02:46 2020



…



Quite a number of sysctl variable names have changed, and the port
needs to be adapted to the new names (therefore there are lots of 0
values in the -L output).

The following names used by zfs-stats do not exist in OpenZFS:

kstat.zfs.misc.arcstats.recycle_miss
kstat.zfs.misc.arcstats.l2_write_buffer_bytes_scanned
kstat.zfs.misc.arcstats.l2_write_buffer_iter
kstat.zfs.misc.arcstats.l2_write_buffer_list_iter
kstat.zfs.misc.arcstats.l2_write_buffer_list_null_iter
kstat.zfs.misc.arcstats.l2_write_full
kstat.zfs.misc.arcstats.l2_write_in_l2
kstat.zfs.misc.arcstats.l2_write_io_in_progress
kstat.zfs.misc.arcstats.l2_write_not_cacheable
kstat.zfs.misc.arcstats.l2_write_passed_headroom
kstat.zfs.misc.arcstats.l2_write_pios
kstat.zfs.misc.arcstats.l2_write_spa_mismatch
kstat.zfs.misc.arcstats.l2_write_trylock_fail
kstat.zfs.misc.arcstats.l2_writes_hdr_miss
vfs.zfs.vdev.cache.size

The existence of vfs.zfs.vdev.cache.size vs vfs.zfs.vdev.cache_size
can be used to detect OpenZFS, and is easily fixed.

But the above listed L2ARC values seem to have been removed from or
have never existed in OpenZFS, and I did not find any substitutes.

Are there any plans to re-create them in OpenZFS on FreeBSD or are
they gone for good?


Recalling 
, 
on 28/03/2020 15:17,28/03/2020 15:17, Allan Jude wrote:


>> …
>>
>> Basically 'arc' was converted to a subtree.
>>
>> We should add some backwards compat sysctls to cover some of
>> these renames etc so configs and scripts don't break etc.



I'd like to update the zfs-stats port for compatibilíty with OpenZFS ...


Cool!
___
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: clang miscompiles OpenLibm on i686-*-freebsd

2020-09-08 Thread Steve Kargl 
On Tue, Sep 08, 2020 at 09:11:50PM +0200, Dimitry Andric wrote:
> On 8 Sep 2020, at 19:47, Steve Kargl  
> wrote:
> > 
> > I think I've found the problem, and it appears to be
> > due to a change byt Openlibm developers to the file
> > math_private.h copied from FreeBSD.  Namely, one finds
> > 
> > //VBS
> > #define STRICT_ASSIGN(type, lval, rval) ((lval) = (rval))
> > 
> > /* VBS
> > #ifdef FLT_EVAL_METHOD
> > // Attempt to get strict C99 semantics for assignment with non-C99 
> > compilers.
> > #if FLT_EVAL_METHOD == 0 || __GNUC__ == 0
> > #define STRICT_ASSIGN(type, lval, rval) ((lval) = (rval))
> > #else
> > #define STRICT_ASSIGN(type, lval, rval) do { \
> > volatile type __lval;   \
> >  \
> > if (sizeof(type) >= sizeof(double)) \
> >  (lval) = (rval);  \
> > else { \
> >  __lval = (rval);  \
> >  (lval) = __lval;  \
> > } \
> > } while (0)
> > #endif
> > #endif
> > */
> > 
> > So, STRICT_ASSIGN is broken in Openlibm.  I'll be reporting
> > a bug upstream.  Apoogies for the noise.
> 
> Hi Steve,
> 
> I'm curious what their rationale was, as the commit that changed it is:
> 
> https://github.com/JuliaMath/openlibm/commit/f5fb92746715beb0441a60feca202ee16cb19fc9
> 
> with a description of just "Build with gcc"... Maybe they've assumed gcc
> never needs the volatile approach?
> 

I have no idea why OpenLibm would change math_private.h.  I've 
reported the issue at https://github.com/JuliaMath/openlibm/issues/215

-- 
Steve
___
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: Boot error with OpenZFS

2020-09-08 Thread Guido Falsi 



On 08/09/20 19:30, Mark Johnston wrote:
> On Tue, Sep 08, 2020 at 07:24:38PM +0200, Guido Falsi wrote:
>> On 08/09/20 10:01, Guido Falsi wrote:
>>> Hi,
>>>
>>> I'm trying to update to recent head, but I can't boot my system with the
>>> compiled kernel.
>>>
>>> The system has ZFS on root and was working with previous kernel (before
>>> OpenZFS migration).
>>>
>>> I'm trying to boot r365437.
>>>
>>> I load zfs from loader with zfs_load="YES" as usual and get this error
>>> message at the start of kernel output:
>>>
>>> link_elf_obj: symbol lockstat_enabled undefined
>>> KLD file zfs.ko - could not finalize loading
>>>
>>> The zfs.ko file is aligned with the kernel and I did not observe errors
>>> while compiling.
>>>
>>> I am able to make the machine using the kernel from the most recent head
>>> snapshot on ftp.freebsd.org [1]. I'm also going to try with a kernel
>>> with debug symbols and one with GENERIC config.
>>
>> A locally built GENERIC works fine, so this is my fault. I clearly have
>> something wrong in my kernel config.
>>
>> I'll report anyway as soon as I discover what it is.
> 
> Can you verify that adding "options KDTRACE_HOOKS" fixes the problem?  I
> note that the zfs.ko Makefile has -DKTRACE_HOOKS in CFLAGS, among a few
> other surprising things.

Yes, that one was the missing option.

I also noticed mmacy committer r365466 which should fix the issue.

Thanks to all!

-- 
Guido Falsi 
___
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: vfs.zfs.min_auto_ashift and OpenZFS

2020-09-08 Thread Niclas Zeising 

On 2020-05-02 02:20, Matthew Macy wrote:

OpenZFS doesn't have the same ashift optimization logic that FreeBSD
has. It's something that needs to be resolved before the code can be
integrated downstream.


So currently all pools created with OpenZFS will use 512 bit alignment, 
at least if the underlying storage device uses 512bit sectors (which 
most drives tend to do)?


If this is the case, it feels like a pessimisation.

Regards
--
Niclas

___
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: Last ZFS upgrade (r365347) breaks booting

2020-09-08 Thread Konstantin Belousov 
On Tue, Sep 08, 2020 at 09:39:18PM +0200, Piotr Kubaj via freebsd-ppc wrote:
> I'm currently on r365449 on powerpc64. I use ZFS on / with zfs.ko compiled in 
> kernel (because there's no loader on PowerNV systems).  
> 
> There seems to be a regression that happened recently, probably in r365347 
> (although I can't bisect it). Booting on my system, both with older kernels 
> and the newest I have, I'm getting:
> exec /sbin/init: error 8
> exec /sbin/init.bak: error 8
> exec /rescue/init: error 8
> init: not found in path /sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init
> panic: no init
> 
> This would suggest that the regression happened in the userspace. I can 
> confirm when running livecd that there is /sbin/init installed.
> ZFS, when loaded from that image 
> (https://download.freebsd.org/ftp/snapshots/powerpc/powerpc64/ISO-IMAGES/13.0/FreeBSD-13.0-CURRENT-powerpc-powerpc64-20200903-c122cf32f2a-disc1.iso)
>  seems to work fine.

Just in case, check r365433.
___
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: clang miscompiles OpenLibm on i686-*-freebsd

2020-09-08 Thread Dimitry Andric 
On 8 Sep 2020, at 19:47, Steve Kargl  wrote:
> 
> On Mon, Sep 07, 2020 at 07:55:13PM -0700, Steve Kargl wrote:
>> On Mon, Sep 07, 2020 at 07:10:02PM -0700, Steve Kargl wrote:
>>> 
>>> Interval tested for exp2f: [1,8]
>>>   ulp <= 0.5:  0.056% 14072 |   0.056% 14072
>>> 0.5 <  ulp <  0.6:  0.000% 8 |   0.056% 14080
>>> 3.0 <  ulp <  0.0: 99.944%  25151744 | 100.000%  25165824
>>> Max ulp: 22729.386719 at 1.00195301e+00
>>> 
>> 
>> Note, compiling s_exp2f.c with gcc9 gives the above
>> result with -O3 -march=i686 -m32. So, gcc9 is not
>> nearly as bad as clang, but both give bad results.
>> Comparing OpenLibm's s_exp2f.c and FreeBSD's s_exp2f.c,
>> one sees that the files are almost identical.
>> 
>> Note, FreeBSD's libm gives
>> 
>> % ./tlibm_libm -DEfP exp2
>> Interval tested for exp2f: [1,8]
>>   ulp <= 0.5: 99.959%  25155610 |  99.959%  25155610
>> 0.5 <  ulp <  0.6:  0.041% 10214 | 100.000%  25165824
>> Max ulp: 0.500980 at 1.97115958e+00
>> 
>> which is good, but this is compiled with CPUTYPE ?= core2
>> in /etc/make.conf.
>> 
> 
> I think I've found the problem, and it appears to be
> due to a change byt Openlibm developers to the file
> math_private.h copied from FreeBSD.  Namely, one finds
> 
> //VBS
> #define STRICT_ASSIGN(type, lval, rval) ((lval) = (rval))
> 
> /* VBS
> #ifdef FLT_EVAL_METHOD
> // Attempt to get strict C99 semantics for assignment with non-C99 compilers.
> #if FLT_EVAL_METHOD == 0 || __GNUC__ == 0
> #define STRICT_ASSIGN(type, lval, rval) ((lval) = (rval))
> #else
> #define STRICT_ASSIGN(type, lval, rval) do { \
> volatile type __lval;   \
>  \
> if (sizeof(type) >= sizeof(double)) \
>  (lval) = (rval);  \
> else { \
>  __lval = (rval);  \
>  (lval) = __lval;  \
> } \
> } while (0)
> #endif
> #endif
> */
> 
> So, STRICT_ASSIGN is broken in Openlibm.  I'll be reporting
> a bug upstream.  Apoogies for the noise.

Hi Steve,

I'm curious what their rationale was, as the commit that changed it is:

https://github.com/JuliaMath/openlibm/commit/f5fb92746715beb0441a60feca202ee16cb19fc9

with a description of just "Build with gcc"... Maybe they've assumed gcc
never needs the volatile approach?

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Boot error with OpenZFS

2020-09-08 Thread Guido Falsi 



On 08/09/20 19:30, Mark Johnston wrote:
> On Tue, Sep 08, 2020 at 07:24:38PM +0200, Guido Falsi wrote:
>> On 08/09/20 10:01, Guido Falsi wrote:
>>> Hi,
>>>
>>> I'm trying to update to recent head, but I can't boot my system with the
>>> compiled kernel.
>>>
>>> The system has ZFS on root and was working with previous kernel (before
>>> OpenZFS migration).
>>>
>>> I'm trying to boot r365437.
>>>
>>> I load zfs from loader with zfs_load="YES" as usual and get this error
>>> message at the start of kernel output:
>>>
>>> link_elf_obj: symbol lockstat_enabled undefined
>>> KLD file zfs.ko - could not finalize loading
>>>
>>> The zfs.ko file is aligned with the kernel and I did not observe errors
>>> while compiling.
>>>
>>> I am able to make the machine using the kernel from the most recent head
>>> snapshot on ftp.freebsd.org [1]. I'm also going to try with a kernel
>>> with debug symbols and one with GENERIC config.
>>
>> A locally built GENERIC works fine, so this is my fault. I clearly have
>> something wrong in my kernel config.
>>
>> I'll report anyway as soon as I discover what it is.
> 
> Can you verify that adding "options KDTRACE_HOOKS" fixes the problem?  I
> note that the zfs.ko Makefile has -DKTRACE_HOOKS in CFLAGS, among a few
> other surprising things.

I am in the process of testing that. The machine is compiling. I also
noticed in sys/conf/files:

kern/kern_lockstat.coptional kdtrace_hooks

I'll report back shortly once I've tested it.

-- 
Guido Falsi 
___
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: clang miscompiles OpenLibm on i686-*-freebsd

2020-09-08 Thread Steve Kargl 
On Mon, Sep 07, 2020 at 07:55:13PM -0700, Steve Kargl wrote:
> On Mon, Sep 07, 2020 at 07:10:02PM -0700, Steve Kargl wrote:
> > 
> > Interval tested for exp2f: [1,8]
> >ulp <= 0.5:  0.056% 14072 |   0.056% 14072
> > 0.5 <  ulp <  0.6:  0.000% 8 |   0.056% 14080
> > 3.0 <  ulp <  0.0: 99.944%  25151744 | 100.000%  25165824
> > Max ulp: 22729.386719 at 1.00195301e+00
> > 
> 
> Note, compiling s_exp2f.c with gcc9 gives the above
> result with -O3 -march=i686 -m32. So, gcc9 is not
> nearly as bad as clang, but both give bad results.
> Comparing OpenLibm's s_exp2f.c and FreeBSD's s_exp2f.c,
> one sees that the files are almost identical.
> 
> Note, FreeBSD's libm gives 
> 
> % ./tlibm_libm -DEfP exp2
> Interval tested for exp2f: [1,8]
>ulp <= 0.5: 99.959%  25155610 |  99.959%  25155610
> 0.5 <  ulp <  0.6:  0.041% 10214 | 100.000%  25165824
> Max ulp: 0.500980 at 1.97115958e+00
> 
> which is good, but this is compiled with CPUTYPE ?= core2
> in /etc/make.conf.
> 

I think I've found the problem, and it appears to be
due to a change byt Openlibm developers to the file
math_private.h copied from FreeBSD.  Namely, one finds

//VBS
#define STRICT_ASSIGN(type, lval, rval) ((lval) = (rval))

/* VBS
#ifdef FLT_EVAL_METHOD
// Attempt to get strict C99 semantics for assignment with non-C99 compilers.
#if FLT_EVAL_METHOD == 0 || __GNUC__ == 0
#define STRICT_ASSIGN(type, lval, rval) ((lval) = (rval))
#else
#define STRICT_ASSIGN(type, lval, rval) do { \
 volatile type __lval;   \
  \
 if (sizeof(type) >= sizeof(double)) \
  (lval) = (rval);  \
 else { \
  __lval = (rval);  \
  (lval) = __lval;  \
 } \
} while (0)
#endif
#endif
*/

So, STRICT_ASSIGN is broken in Openlibm.  I'll be reporting
a bug upstream.  Apoogies for the noise.

-- 
Steve
___
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: Boot error with OpenZFS

2020-09-08 Thread Mark Johnston 
On Tue, Sep 08, 2020 at 07:24:38PM +0200, Guido Falsi wrote:
> On 08/09/20 10:01, Guido Falsi wrote:
> > Hi,
> > 
> > I'm trying to update to recent head, but I can't boot my system with the
> > compiled kernel.
> > 
> > The system has ZFS on root and was working with previous kernel (before
> > OpenZFS migration).
> > 
> > I'm trying to boot r365437.
> > 
> > I load zfs from loader with zfs_load="YES" as usual and get this error
> > message at the start of kernel output:
> > 
> > link_elf_obj: symbol lockstat_enabled undefined
> > KLD file zfs.ko - could not finalize loading
> > 
> > The zfs.ko file is aligned with the kernel and I did not observe errors
> > while compiling.
> > 
> > I am able to make the machine using the kernel from the most recent head
> > snapshot on ftp.freebsd.org [1]. I'm also going to try with a kernel
> > with debug symbols and one with GENERIC config.
> 
> A locally built GENERIC works fine, so this is my fault. I clearly have
> something wrong in my kernel config.
> 
> I'll report anyway as soon as I discover what it is.

Can you verify that adding "options KDTRACE_HOOKS" fixes the problem?  I
note that the zfs.ko Makefile has -DKTRACE_HOOKS in CFLAGS, among a few
other surprising things.
___
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: Boot error with OpenZFS

2020-09-08 Thread Guido Falsi 
On 08/09/20 10:01, Guido Falsi wrote:
> Hi,
> 
> I'm trying to update to recent head, but I can't boot my system with the
> compiled kernel.
> 
> The system has ZFS on root and was working with previous kernel (before
> OpenZFS migration).
> 
> I'm trying to boot r365437.
> 
> I load zfs from loader with zfs_load="YES" as usual and get this error
> message at the start of kernel output:
> 
> link_elf_obj: symbol lockstat_enabled undefined
> KLD file zfs.ko - could not finalize loading
> 
> The zfs.ko file is aligned with the kernel and I did not observe errors
> while compiling.
> 
> I am able to make the machine using the kernel from the most recent head
> snapshot on ftp.freebsd.org [1]. I'm also going to try with a kernel
> with debug symbols and one with GENERIC config.

A locally built GENERIC works fine, so this is my fault. I clearly have
something wrong in my kernel config.

I'll report anyway as soon as I discover what it is.


-- 
Guido Falsi 
___
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 2020-09-06

2020-09-08 Thread Li-Wen Hsu 
(Please send the followup to freebsd-testing@ and note Reply-To is set.)

FreeBSD CI Weekly Report 2020-09-06
===

Here is a summary of the FreeBSD Continuous Integration results for the period
from 2020-08-31 to 2020-09-06.

During this period, we have:

* 2089 builds (92.0% (+3.7) passed, 8.0% (-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.
* 237 test runs (42.6% (-2.7) passed, 24.5% (-3.2) unstable, 32.9% (+5.9)
  exception) were executed on amd64, i386, riscv64 architectures for head,
  stable/12, stable/11 branches.
* 30 doc and www builds (100% passed)

Test case status (on 2020-09-06 23:59):
| Branch/Architecture | Total | Pass  | Fail   | Skipped  |
| --- | - | - | -- |  |
| head/amd64  | 7879 (+3) | 7789 (+4) | 0 (-1) | 90 (0)   |
| head/i386   | 7877 (+4) | 7769 (-4) | 0 (0)  | 108 (+8) |
| 12-STABLE/amd64 | 7626 (0)  | 7566 (-3) | 0 (0)  | 60 (+3)  |
| 12-STABLE/i386  | 7624 (0)  | 7556 (-3) | 0 (0)  | 68 (+3)  |
| 11-STABLE/amd64 | 6912 (0)  | 6861 (0)  | 0 (0)  | 51 (0)   |
| 11-STABLE/i386  | 6910 (0)  | 6857 (+3) | 0 (0)  | 53 (-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-20200906 and archive is available at
https://hackmd.io/@FreeBSD-CI/ , any help is welcomed.

## Fixed test cases

* sys.kern.kern_copyin.kern_copyin
  Fails after somewhere in (r364509, r364542]
  https://bugs.freebsd.org/248933
  Fixed in r365327 and r365337

## Failing jobs

* https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/
  There are still mutiple errors when building with gcc6, error log available at
  
https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/lastCompletedBuild/console
  See also:
  https://lists.freebsd.org/pipermail/svn-src-all/2020-September/202307.html
  
## Regressions

* lib.libexecinfo.backtrace_test.backtrace_fmt_basic starts failing on amd64 
after r360915
  https://bugs.freebsd.org/246537

* lib.msun.ctrig_test.test_inf_inputs starts failing after llvm10 import
  https://bugs.freebsd.org/244732
  Needs to check if llvm11 import fixes this.

* Lock-order reversals triggered by tests under sys.net.if_lagg_test.* on i386
  https://bugs.freebsd.org/244163
  Discovered by newly endabled sys.net.* tests. 
([r357857](https://svnweb.freebsd.org/changeset/base/357857))
  
* sys.net.if_lagg_test.lacp_linkstate_destroy_stress panics i386 kernel
  https://bugs.freebsd.org/244168
  Discovered by newly endabled sys.net.* tests. 
([r357857](https://svnweb.freebsd.org/changeset/base/357857))
  Fix committed as https://svnweb.freebsd.org/changeset/base/364220 , needs 
more verification.

* lib.libbe.be_create.* and sbin.bectl.bectl_test.*
  https://bugs.freebsd.org/249055
  Loading zfs.ko hangs i386 kernel
  
## 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
* common.ip.t_dtrace_contrib.tst_ipv4localsctp_ksh
* common.ip.t_dtrace_contrib.tst_localsctpstate_ksh

* https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/
* Total 681 tests, 524 success, 47 failures, 110 skipped, see
  
https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/
 for more details

* https://ci.freebsd.org/job/FreeBSD-head-amd64-test_ltp/
* Total 3749 tests, 2291 success, 645 failures, 813 skipped

## 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
* sys.sys.qmath_test.qdivq_s64q
  https://bugs.freebsd.org/240219
*

Boot error with OpenZFS

2020-09-08 Thread Guido Falsi 
Hi,

I'm trying to update to recent head, but I can't boot my system with the
compiled kernel.

The system has ZFS on root and was working with previous kernel (before
OpenZFS migration).

I'm trying to boot r365437.

I load zfs from loader with zfs_load="YES" as usual and get this error
message at the start of kernel output:

link_elf_obj: symbol lockstat_enabled undefined
KLD file zfs.ko - could not finalize loading

The zfs.ko file is aligned with the kernel and I did not observe errors
while compiling.

I am able to make the machine using the kernel from the most recent head
snapshot on ftp.freebsd.org [1]. I'm also going to try with a kernel
with debug symbols and one with GENERIC config.

Maybe I'm just missing some required kernel configuration option? Or
maybe with the migration to OpenZFS some required symbol is not being
exported anymore?

Thanks in advance!



[1] FreeBSD-13.0-CURRENT-amd64-20200903-c122cf32f2a-memstick.img.xz

-- 
Guido Falsi 
___
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"

OpenZFS and L2ARC

2020-09-08 Thread Stefan Esser 
OpenZFS seems to work quite well for me, in general, but I have 
questions regarding the L2ARC statistics.


The system uses a 3 * 6 TB raidz1 (plus further ZFS volumes that
are not relevant here, since without level 2 ARC) and an 1 TB M.2
SSD with a 256 GB partition for the L2ARC (and most of it currently
unused, else).

The L2ARC seems to have filled to the limit of 256 GB, but after
several reboots, sysctl reports a L2ARC size of nearly twice the
allocated space:

kstat.zfs.misc.arcstats.l2_size: 534620858880

That is 497 GiB, and might be possible with a lz4 compression
factor of 2 - if the value reported is not the space allocated,
but the actual (uncompressed) data held by the L2ARC.


The sysutils/zfs-stats port reports the following values for
this system, BTW:


ZFS Subsystem ReportTue Sep  8 09:02:46 2020


L2 ARC Summary: (HEALTHY)
Passed Headroom:0
Tried Lock Failures:0
IO In Progress: 0
Low Memory Aborts:  7
Free on Write:  123
Writes While Full:  0
R/W Clashes:0
Bad Checksums:  0
IO Errors:  0
SPA Mismatch:   0

L2 ARC Size: (Adaptive) 497.91  GiB
Header Size:0.11%   558.83  MiB

L2 ARC Evicts:
Lock Retries:   6
Upon Reading:   0

L2 ARC Breakdown:   5.75m
Hit Ratio:  81.94%  4.71m
Miss Ratio: 18.06%  1.04m
Feeds:  235.04  k

L2 ARC Buffer:
Bytes Scanned:  0   Bytes
Buffer Iterations:  0
List Iterations:0
NULL List Iterations:   0

L2 ARC Writes:
Writes Sent:100.00% 22.67   k



With the FreeBSD ZFS (without persistent L2ARC) I never got more
than 20% hit ratio on the L2ARC between reboots.

Quite a number of sysctl variable names have changed, and the port
needs to be adapted to the new names (therefore there are lots of 0
values in the -L output).

The following names used by zfs-stats do not exist in OpenZFS:

kstat.zfs.misc.arcstats.recycle_miss
kstat.zfs.misc.arcstats.l2_write_buffer_bytes_scanned
kstat.zfs.misc.arcstats.l2_write_buffer_iter
kstat.zfs.misc.arcstats.l2_write_buffer_list_iter
kstat.zfs.misc.arcstats.l2_write_buffer_list_null_iter
kstat.zfs.misc.arcstats.l2_write_full
kstat.zfs.misc.arcstats.l2_write_in_l2
kstat.zfs.misc.arcstats.l2_write_io_in_progress
kstat.zfs.misc.arcstats.l2_write_not_cacheable
kstat.zfs.misc.arcstats.l2_write_passed_headroom
kstat.zfs.misc.arcstats.l2_write_pios
kstat.zfs.misc.arcstats.l2_write_spa_mismatch
kstat.zfs.misc.arcstats.l2_write_trylock_fail
kstat.zfs.misc.arcstats.l2_writes_hdr_miss
vfs.zfs.vdev.cache.size

The existence of vfs.zfs.vdev.cache.size vs vfs.zfs.vdev.cache_size
can be used to detect OpenZFS, and is easily fixed.

But the above listed L2ARC values seem to have been removed from or
have never existed in OpenZFS, and I did not find any substitutes.

Are there any plans to re-create them in OpenZFS on FreeBSD or are
they gone for good?

I'd like to update the zfs-stats port for compatibilíty with OpenZFS ...
___
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"