From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 01:04:25 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 259CDF58; Sun, 20 Jul 2014 01:04:25 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 12B8C2FF0; Sun, 20 Jul 2014 01:04:25 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 3D535A3E; Sun, 20 Jul 2014 01:04:25 +0000 (UTC) Date: Sun, 20 Jul 2014 01:04:23 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org, jhb@FreeBSD.org, bapt@FreeBSD.org Message-ID: <519612446.0.1405818264970.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_stable_10 #515 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 01:04:25 -0000 See Changes: [bapt] MFC: r263648, r264789, r266636 This brings: - schema validation - xpath-like interface for ucl objects Adapt pkg(7) to the new libucl API [jhb] MFC 263432,265366,265376: Fixes for vcpu management in bhyve: - Use 'cpuset_t' to represent the vcpus active in a virtual machine. - Modify the "-p" option to be more flexible when associating a 'vcpu' with a 'hostcpu'. [jhb] MFC 262884,263236,265407: Various uart fixes: - Open the uart emulation's backing tty in non-blocking mode. - Support 16-bit register access. - Disable the 'uart_drain()' callback when the emulated receive FIFO is full. [jhb] MFC 259942,262274,263035,263054,263211,263744,264179,264324,264468,264631, 264648,264650,264651,266572,267558: Flesh out the AT PIC and 8254 PIT emulations and move them into the kernel. ------------------------------------------ [...truncated 154570 lines...] cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -o procstat procstat.o procstat_args.o procstat_auxv.o procstat_basic.o procstat_bin.o procstat_cred.o procstat_files.o procstat_kstack.o procstat_rlimit.o procstat_rusage.o procstat_sigs.o procstat_threads.o procstat_vm.o -lutil -lprocstat -lkvm --- usr.sbin.all__D --- --- audio.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o audio.o --- usr.bin.all__D --- --- all_subdir_revoke --- ===> usr.bin/revoke (all) --- usr.sbin.all__D --- --- authkeys.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o authkeys.o --- usr.bin.all__D --- --- revoke.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- usr.sbin.all__D --- --- all_subdir_pciconf --- --- err.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -c --- usr.bin.all__D --- --- revoke.1.gz --- gzip -cn > revoke.1.gz --- revoke --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -o revoke revoke.o --- all_subdir_rlogin --- ===> usr.bin/rlogin (all) --- usr.sbin.all__D --- --- pciconf.8.gz --- gzip -cn > pciconf.8.gz --- pciconf --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -o pciconf pciconf.o cap.o err.o --- usr.bin.all__D --- --- rlogin.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- usr.sbin.all__D --- --- all_subdir_ntp --- --- authreadkeys.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o authreadkeys.o --- usr.bin.all__D --- --- rlogin.1.gz --- gzip -cn > rlogin.1.gz --- all_subdir_rpcgen --- ===> usr.bin/rpcgen (all) --- rpc_main.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- rpc_clntout.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- usr.sbin.all__D --- --- authusekey.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o authusekey.o --- usr.bin.all__D --- --- all_subdir_rlogin --- --- rlogin --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -o rlogin rlogin.o --- usr.sbin.all__D --- --- all_subdir_periodic --- ===> usr.sbin/periodic (all) --- usr.bin.all__D --- --- all_subdir_rpcgen --- --- rpc_cout.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- usr.sbin.all__D --- --- periodic.8.gz --- gzip -cn > periodic.8.gz --- all_subdir_ntp --- --- buftvtots.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o buftvtots.o --- caljulian.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o caljulian.o --- usr.bin.all__D --- --- rpc_hout.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- usr.sbin.all__D --- --- caltontp.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o caltontp.o --- calyearstart.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o calyearstart.o --- usr.bin.all__D --- --- rpc_parse.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- rpc_sample.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- usr.sbin.all__D --- --- all_subdir_pkg --- --- all_subdir_ntp --- --- clocktime.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o clocktime.o --- all_subdir_pkg --- ===> usr.sbin/pkg (all) --- usr.bin.all__D --- --- all_subdir_rpcinfo --- ===> usr.bin/rpcinfo (all) --- all_subdir_rpcgen --- --- rpc_scan.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- usr.sbin.all__D --- --- pkg.o --- cc -O2 -pipe -I -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- usr.bin.all__D --- --- all_subdir_rpcinfo --- --- rpcinfo.o --- cc -O2 -pipe -DPORTMAP -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c --- usr.sbin.all__D --- --- all_subdir_ntp --- --- clocktypes.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o clocktypes.o --- usr.bin.all__D --- --- all_subdir_rpcgen --- --- rpc_svcout.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- usr.sbin.all__D --- --- decodenetnum.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o decodenetnum.o --- dofptoa.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o dofptoa.o --- dolfptoa.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o dolfptoa.o --- usr.bin.all__D --- --- rpc_tblout.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- usr.sbin.all__D --- --- emalloc.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o emalloc.o --- all_subdir_pkg --- --- dns_utils.o --- cc -O2 -pipe -I -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- usr.bin.all__D --- --- all_subdir_rpcinfo --- --- rpcinfo.8.gz --- gzip -cn > rpcinfo.8.gz --- all_subdir_rpcgen --- --- rpc_util.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- all_subdir_rpcinfo --- --- rpcinfo --- cc -O2 -pipe -DPORTMAP -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -o rpcinfo rpcinfo.o --- usr.sbin.all__D --- --- all_subdir_ntp --- --- findconfig.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o findconfig.o --- fptoa.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o fptoa.o --- all_subdir_pkg --- --- config.o --- cc -O2 -pipe -I -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- pkg.7.gz --- gzip -cn > pkg.7.gz --- all_subdir_pmcannotate --- ===> usr.sbin/pmcannotate (all) --- all_subdir_ntp --- --- fptoms.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o fptoms.o --- all_subdir_pmcannotate --- --- pmcannotate.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- all_subdir_ntp --- --- getopt.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o getopt.o --- usr.bin.all__D --- --- all_subdir_rpcgen --- --- rpcgen.1.gz --- gzip -cn > rpcgen.1.gz --- rpcgen --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -o rpcgen rpc_main.o rpc_clntout.o rpc_cout.o rpc_hout.o rpc_parse.o rpc_sample.o rpc_scan.o rpc_svcout.o rpc_tblout.o rpc_util.o --- usr.sbin.all__D --- --- hextoint.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o hextoint.o --- usr.bin.all__D --- --- all_subdir_rs --- ===> usr.bin/rs (all) --- rs.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- usr.sbin.all__D --- --- hextolfp.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o hextolfp.o --- all_subdir_pkg --- --- pkg --- cc -O2 -pipe -I -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -L/usr/obj -rpath /usr/lib/private -o pkg pkg.o dns_utils.o config.o -larchive -lelf -lfetch -lucl -lsbuf -lssl -lcrypto /usr/obj: undefined reference to `remainder' --- all_subdir_ntp --- --- humandate.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o humandate.o --- all_subdir_pkg --- cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [pkg] Error code 1 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_pkg] Error code 2 make[3]: stopped in --- all_subdir_ntp --- A failure has been detected in another branch of the parallel make make[5]: stopped in --- all_subdir_pmcannotate --- A failure has been detected in another branch of the parallel make make[4]: stopped in --- all_subdir_ntp --- *** [all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in --- all_subdir_pmcannotate --- *** [all_subdir_pmcannotate] Error code 2 make[3]: stopped in --- all_subdir_ntp --- *** [all_subdir_ntp] Error code 2 make[3]: stopped in 3 errors make[3]: stopped in *** [usr.sbin.all__D] Error code 2 make[2]: stopped in --- usr.bin.all__D --- A failure has been detected in another branch of the parallel make make[4]: stopped in *** [all_subdir_rs] Error code 2 make[3]: stopped in 1 error make[3]: stopped in *** [usr.bin.all__D] Error code 2 make[2]: stopped in 2 errors make[2]: stopped in *** [everything] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildworld] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 04:30:50 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73CB6FA9; Sun, 20 Jul 2014 04:30:50 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 5CD9F2E10; Sun, 20 Jul 2014 04:30:50 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 1831FA82; Sun, 20 Jul 2014 04:30:50 +0000 (UTC) Date: Sun, 20 Jul 2014 04:30:43 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org, jhb@FreeBSD.org, bapt@FreeBSD.org, hiren@FreeBSD.org Message-ID: <58449660.1.1405830649448.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <519612446.0.1405818264970.JavaMail.jenkins@jenkins-9.freebsd.org> References: <519612446.0.1405818264970.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_stable_10 #516 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 04:30:50 -0000 See Changes: [hiren] MFC r268790 Fix a typo. [bapt] MFC: r261032 Add quiet support for kldstat -n PR:=09=09bin/180014 Submitted by:=09Olivier Cochard-Labb=C3=A9 [bapt] MFC: r267376 Add a zlib pkg-config file (more and more ports requires it) Approved by:=09delphij [bapt] MFC: r267131, r267132, r267133, r268493, r268671 Use NULL instead of 0 (Patch by Sascha Wildner for Drago= nfly) Remove unnecessary semicolons (Patch by Sascha Wildner f= or Dragonfly) Add support for arbitrary http requests [1] Support EAGAIN in fetch_writev Submitted by:=09Alex Hornung [1] Reviewed by:=09des [bapt] MFC: r257315, r260445, r264803 Update byacc to 20140422 ------------------------------------------ [...truncated 160380 lines...] --- dolfptoa.o --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o dolfptoa.o --- usr.bin.all__D --- --- all_subdir_leave --- --- usr.sbin.all__D --- --- emalloc.o --- --- usr.bin.all__D --- =3D=3D=3D> usr.bin/leave (all) --- usr.sbin.all__D --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o emalloc.o --- usr.bin.all__D --- --- leave.o --- cc -O2 -pipe -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-= headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-pro= totypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwr= ite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscr= ipts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wm= issing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-= plus-int -Wno-unused-const-variable -Wno-format -c --- usr.sbin.all__D --- --- findconfig.o --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o findconfig.o --- fptoa.o --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o fptoa.o --- usr.bin.all__D --- --- leave.1.gz --- gzip -cn > leave.1.gz --- usr.sbin.all__D --- --- all_subdir_pc-sysinstall --- =3D=3D=3D> usr.sbin/pc-sysinstall (all) --- usr.bin.all__D --- --- leave --- cc -O2 -pipe -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-= headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-pro= totypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwr= ite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscr= ipts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wm= issing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-= plus-int -Wno-unused-const-variable -Wno-format -o leave leave.o=20 --- usr.sbin.all__D --- --- all --- =3D=3D=3D> usr.sbin/pc-sysinstall/backend (all) --- all_subdir_ntp --- --- fptoms.o --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o fptoms.o --- all_subdir_pc-sysinstall --- =3D=3D=3D> usr.sbin/pc-sysinstall/backend-partmanager (all) =3D=3D=3D> usr.sbin/pc-sysinstall/backend-query (all) --- usr.bin.all__D --- --- all_subdir_less --- =3D=3D=3D> usr.bin/less (all) --- usr.sbin.all__D --- =3D=3D=3D> usr.sbin/pc-sysinstall/conf (all) --- usr.bin.all__D --- --- main.o --- --- usr.sbin.all__D --- --- all_subdir_ntp --- --- getopt.o --- --- usr.bin.all__D --- cc -O2 -pipe -I -I -std=3Dgnu99 -Qunused-argum= ents -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-emp= ty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-c= ompare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wn= o-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter = -Wno-parentheses -c --- usr.sbin.all__D --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o getopt.o --- all_subdir_pc-sysinstall --- =3D=3D=3D> usr.sbin/pc-sysinstall/doc (all) =3D=3D=3D> usr.sbin/pc-sysinstall/examples (all) =3D=3D=3D> usr.sbin/pc-sysinstall/pc-sysinstall (all) --- pc-sysinstall.8.gz --- gzip -cn > pc-sysinstall.8.gz --- all_subdir_pciconf --- =3D=3D=3D> usr.sbin/pciconf (all) --- pciconf.o --- cc -O2 -pipe -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-= headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-pro= totypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointe= r-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno= -tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unus= ed-function -Wno-enum-conversion -c --- all_subdir_ntp --- --- hextoint.o --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o hextoint.o --- usr.bin.all__D --- --- screen.o --- cc -O2 -pipe -I -I -std=3Dgnu99 -Qunused-argum= ents -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-emp= ty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-c= ompare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wn= o-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter = -Wno-parentheses -c --- usr.sbin.all__D --- --- hextolfp.o --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o hextolfp.o --- humandate.o --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o humandate.o --- icom.o --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o icom.o --- usr.bin.all__D --- --- brac.o --- cc -O2 -pipe -I -I -std=3Dgnu99 -Qunused-argum= ents -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-emp= ty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-c= ompare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wn= o-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter = -Wno-parentheses -c --- usr.sbin.all__D --- --- all_subdir_pciconf --- --- cap.o --- cc -O2 -pipe -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-= headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-pro= totypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointe= r-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno= -tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unus= ed-function -Wno-enum-conversion -c --- usr.bin.all__D --- --- ch.o --- cc -O2 -pipe -I -I -std=3Dgnu99 -Qunused-argum= ents -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-emp= ty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-c= ompare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wn= o-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter = -Wno-parentheses -c --- usr.sbin.all__D --- --- all_subdir_ntp --- --- inttoa.o --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o inttoa.o --- iosignal.o --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o iosignal.o --- all_subdir_pciconf --- --- err.o --- cc -O2 -pipe -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-= headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-pro= totypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointe= r-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno= -tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unus= ed-function -Wno-enum-conversion -c --- usr.bin.all__D --- --- charset.o --- cc -O2 -pipe -I -I -std=3Dgnu99 -Qunused-argum= ents -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-emp= ty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-c= ompare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wn= o-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter = -Wno-parentheses -c --- usr.sbin.all__D --- --- pciconf.8.gz --- gzip -cn > pciconf.8.gz --- all_subdir_ntp --- --- lib_strbuf.o --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o lib_strbuf.o --- all_subdir_pciconf --- --- pciconf --- cc -O2 -pipe -std=3Dgnu99 -Qunused-arguments -fstack-protector -Wsystem-= headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-pro= totypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointe= r-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno= -tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unus= ed-function -Wno-enum-conversion -o pciconf pciconf.o cap.o err.o=20 --- all_subdir_periodic --- =3D=3D=3D> usr.sbin/periodic (all) --- all_subdir_ntp --- --- machines.o --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o machines.o --- all_subdir_periodic --- --- periodic.8.gz --- gzip -cn > periodic.8.gz --- all_subdir_ntp --- --- md5c.o --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o md5c.o --- all_subdir_pkg --- =3D=3D=3D> usr.sbin/pkg (all) --- pkg.o --- cc -O2 -pipe -I -std=3Dgnu99 -Qunused-argume= nts -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -W= no-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-para= meter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-= decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-s= ign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- all_subdir_ntp --- --- memmove.o --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o memmove.o --- usr.bin.all__D --- --- cmdbuf.o --- cc -O2 -pipe -I -I -std=3Dgnu99 -Qunused-argum= ents -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-emp= ty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-c= ompare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wn= o-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter = -Wno-parentheses -c --- usr.sbin.all__D --- --- mfptoa.o --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o mfptoa.o --- mfptoms.o --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o mfptoms.o --- mktime.o --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o mktime.o --- modetoa.o --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o modetoa.o --- mstolfp.o --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o mstolfp.o --- usr.bin.all__D --- --- command.o --- cc -O2 -pipe -I -I -std=3Dgnu99 -Qunused-argum= ents -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-emp= ty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-c= ompare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wn= o-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter = -Wno-parentheses -c --- usr.sbin.all__D --- --- ntp_random.o --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o ntp_random.o --- all_subdir_pkg --- --- dns_utils.o --- cc -O2 -pipe -I -std=3Dgnu99 -Qunused-argume= nts -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -W= no-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-para= meter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-= decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-s= ign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- all_subdir_ntp --- --- msutotsf.o --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o msutotsf.o --- msyslog.o --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o msyslog.o --- all_subdir_pkg --- --- config.o --- cc -O2 -pipe -I -std=3Dgnu99 -Qunused-argume= nts -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -W= no-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-para= meter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-= decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-s= ign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- all_subdir_ntp --- --- netof.o --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o netof.o --- usr.bin.all__D --- --- cvt.o --- cc -O2 -pipe -I -I -std=3Dgnu99 -Qunused-argum= ents -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-emp= ty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-c= ompare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wn= o-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter = -Wno-parentheses -c --- usr.sbin.all__D --- --- ntp_rfc2553.o --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o ntp_rfc2553.o --- usr.bin.all__D --- --- decode.o --- cc -O2 -pipe -I -I -std=3Dgnu99 -Qunused-argum= ents -fstack-protector -Wsystem-headers -Werror -Wno-pointer-sign -Wno-emp= ty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-c= ompare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wn= o-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter = -Wno-parentheses -c --- usr.sbin.all__D --- --- all_subdir_pkg --- --- pkg.7.gz --- gzip -cn > pkg.7.gz --- pkg --- cc -O2 -pipe -I -std=3Dgnu99 -Qunused-argume= nts -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -W= no-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arit= h -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-para= meter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-= decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-s= ign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -L/usr= /obj -rpath /usr/lib/private -o pkg pkg.o dns_utils.o config.o -larc= hive -lelf -lfetch -lucl -lsbuf -lssl -lcrypto --- all_subdir_ntp --- --- numtoa.o --- cc -O2 -pipe -I -I -DSYS_= FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=3Dgnu99 -Qunused-arguments = -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -= Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-= parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch = -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o numtoa.o --- all_subdir_pkg --- /usr/obj: undefined reference to `remainder' cc: error: linker command failed with exit code 1 (use -v to see invocation= ) *** [pkg] Error code 1 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_pkg] Error code 2 make[3]: stopped in --- usr.bin.all__D --- A failure has been detected in another branch of the parallel make make[4]: stopped in *** [all_subdir_less] Error code 2 make[3]: stopped in --- usr.sbin.all__D --- --- all_subdir_ntp --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_ntp] Error code 2 make[3]: stopped in 2 errors make[3]: stopped in *** [usr.sbin.all__D] Error code 2 make[2]: stopped in --- usr.bin.all__D --- --- all_subdir_clang --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [all_subdir_tblgen] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_clang] Error code 2 make[3]: stopped in 2 errors make[3]: stopped in *** [usr.bin.all__D] Error code 2 make[2]: stopped in 2 errors make[2]: stopped in *** [everything] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildworld] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 06:24:17 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 12135DA5 for ; Sun, 20 Jul 2014 06:24:17 +0000 (UTC) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by mx1.freebsd.org (Postfix) with ESMTP id E900F263C for ; Sun, 20 Jul 2014 06:24:16 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta12.emeryville.ca.mail.comcast.net with comcast id UWP11o0011HpZEs01WQEL1; Sun, 20 Jul 2014 06:24:14 +0000 Received: from jdc.koitsu.org ([69.181.136.108]) by omta14.emeryville.ca.mail.comcast.net with comcast id UWQD1o00D2LW5AV8aWQEFs; Sun, 20 Jul 2014 06:24:14 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 844C61744B1; Sat, 19 Jul 2014 23:24:13 -0700 (PDT) Date: Sat, 19 Jul 2014 23:24:13 -0700 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Subject: Consistently "high" CPU load on 10.0-STABLE Message-ID: <20140720062413.GA56318@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405837454; bh=0WNquybfF878xTsYmes1tiSw3V7Ekm6DTPPv/0RQ43E=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=BMnmczl8zNYnl0DUQfszGE0yvX1EuHVgZqdRI4by6G0GQ6FGn3pLBDY3Fj5qn+hiV vQGuezE1BAeUfa8j9RozXBI/pIwoeeKgk+U6rAqw7rUidrC8MP7kNOP5XKuGLG+ddh n9j09/Narn0Z70HKvsXTDUfDnDg6W97tQGR6+aLBX+2NACef3TYvDELG/OLkc/Um+D MJeQUqRa9kmQR8AFKltLH1FJ9TkQb7Ca+JWqMVA+21xod31rI9KAXkwTg+MuLqGYsa IrfJ59B+pQJ5B42clmAksNJN2EsVCCttkVGd1WU7t8oHbbMCMZ9DPqWxfb0NusTfBC fBY4SUAYPb1+A== X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 06:24:17 -0000 (Please keep me CC'd as I'm not subscribed to freebsd-stable@) Today I took the liberty of upgrading my main home server from 9.3-STABLE (r268785) to 10.0-STABLE (r268894). The upgrade consisted of doing a fresh install of 10.0-STABLE on a brand new unused SSD. Most everything went as planned, barring a couple ports-related anomalies, and I seemed fairly impressed by the fact that buildworld times had dropped to 27 minutes and buildkernel to 4 minutes with clang (something I'd been avoiding like the plague for a long while). Kudos. But after an hour or so, I noticed a consistent (i.e. reproducible) trend: the system load average tends to hang around 0.10 to 0.15 all the time. There are times where the load drops to 0.03 or 0.04 but then something kicks it back up to 0.15 or 0.20 and then it slowly levels out again (over the course of a few minutes) then repeats. Obviously this is normal behaviour for a system when something is going on periodically. So I figured it might have been a userland process behaving differently under 10.x than 9.x. I let top -a -S -s 1 run and paid very very close attention to it for several minutes. Nothing. It doesn't appear to be something userland -- it appears to be something kernel-level, but nothing in top -S shows up as taking up any CPU time other than "[idle]" so I have no idea what might be doing it. The box isn't doing anything like routing network traffic/NAT, it's pure IPv4 (IPv6 disabled in world and kernel, and my home network does basically no IPv6) and sits idle most of the time fetching mail. It does use ZFS, but not for /, swap, /var, /tmp, or /usr. vmstat -i doesn't particularly show anything awful. All the cpuX:timer entries tend to fluctuate in rate, usually 120-200 or so; I'd expect an interrupt storm to be showing something in the 1000+ range. The only thing I can think of is the fact that the SSD being used has no 4K quirk entry in the kernel (and its ATA IDENTIFY responds with 512 logical, 512 physical, even though we know it's 4K). The partitions are all 1MB-aligned regardless. This is all bare-metal, by the way -- no virtualisation involved. I do have DTrace enabled/built on this box but I have absolutely no clue how to go about profiling things. For example maybe output of this sort would be helpful (but I've no idea how to get it): http://lists.freebsd.org/pipermail/freebsd-stable/2014-July/079276.html I'm certain I didn't see this behaviour in 9.x so I'd be happy to try and track it down if I had a little bit of hand-holding. I've put all the things I can think of that might be relevant to "system config/tuning bits" up here: http://jdc.koitsu.org/freebsd/releng10_perf_issue/ I should note my kernel config is slightly inaccurate (I've removed some stuff from the file in attempt to rebuild, but building world prior to kernel failed due to r268896 breaking world, but anyone subscribed here has already seen the Jenkins job of that ;-) ). Thanks. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 07:13:06 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2FE64AF for ; Sun, 20 Jul 2014 07:13:06 +0000 (UTC) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9513C2987 for ; Sun, 20 Jul 2014 07:13:06 +0000 (UTC) Received: by mail-qg0-f49.google.com with SMTP id j107so4368978qga.22 for ; Sun, 20 Jul 2014 00:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gqWrNWBvnmmLe7qiQbepGB3yG0d2u6QRaLlrvnnIGJQ=; b=W6Y2r7oRTM0mp/u+ZcLQBBDYkBhC6lbSOgrELFzx5DpmwrH8aPE6HkEo5xVN8DypQk 2Y/JfUDz6inHP07OaFu/WfByUYSy+e53CETW9CRtMBWpefEl71JmRVAvBB/j0aPvDtYA M1ODfhkicNyRvveTatwW5XM6899kSOQl39sO/mEjAMXmP+MAfALnton9eE0SrBvy4/pZ Z/TJqyw3qFMjN5MXVOCxOQQB7QPwG68mpDQpbO7OX95TGNnCee1mpODZRDCh/t0c4AlM eIP04t9ElVEIzB4GLJETYOixvy12ejPELR2nvKHmzWh9Uf2H15x712Xc2tQnqg1GCeNQ 8a9Q== MIME-Version: 1.0 X-Received: by 10.224.223.135 with SMTP id ik7mr27769899qab.26.1405840385637; Sun, 20 Jul 2014 00:13:05 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.1.6 with HTTP; Sun, 20 Jul 2014 00:13:05 -0700 (PDT) In-Reply-To: <20140720062413.GA56318@icarus.home.lan> References: <20140720062413.GA56318@icarus.home.lan> Date: Sun, 20 Jul 2014 00:13:05 -0700 X-Google-Sender-Auth: XBQOwhb0vILcwqJaP6uEi5ol-FI Message-ID: Subject: Re: Consistently "high" CPU load on 10.0-STABLE From: Adrian Chadd To: Jeremy Chadwick Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 07:13:06 -0000 Hi, I don't know how to do this with dtrace, but take a look at tools/sched/schedgraph.py and enable KTR to get some trace records. KTR logs the scheduler activity -and- the loadav with it. -a On 19 July 2014 23:24, Jeremy Chadwick wrote: > (Please keep me CC'd as I'm not subscribed to freebsd-stable@) > > Today I took the liberty of upgrading my main home server from > 9.3-STABLE (r268785) to 10.0-STABLE (r268894). The upgrade consisted of > doing a fresh install of 10.0-STABLE on a brand new unused SSD. Most > everything went as planned, barring a couple ports-related anomalies, > and I seemed fairly impressed by the fact that buildworld times had > dropped to 27 minutes and buildkernel to 4 minutes with clang (something > I'd been avoiding like the plague for a long while). Kudos. > > But after an hour or so, I noticed a consistent (i.e. reproducible) > trend: the system load average tends to hang around 0.10 to 0.15 all the > time. There are times where the load drops to 0.03 or 0.04 but then > something kicks it back up to 0.15 or 0.20 and then it slowly levels out > again (over the course of a few minutes) then repeats. > > Obviously this is normal behaviour for a system when something is going > on periodically. So I figured it might have been a userland process > behaving differently under 10.x than 9.x. I let top -a -S -s 1 run and > paid very very close attention to it for several minutes. Nothing. It > doesn't appear to be something userland -- it appears to be something > kernel-level, but nothing in top -S shows up as taking up any CPU time > other than "[idle]" so I have no idea what might be doing it. > > The box isn't doing anything like routing network traffic/NAT, it's pure > IPv4 (IPv6 disabled in world and kernel, and my home network does > basically no IPv6) and sits idle most of the time fetching mail. It > does use ZFS, but not for /, swap, /var, /tmp, or /usr. > > vmstat -i doesn't particularly show anything awful. All the cpuX:timer > entries tend to fluctuate in rate, usually 120-200 or so; I'd expect an > interrupt storm to be showing something in the 1000+ range. > > The only thing I can think of is the fact that the SSD being used has no > 4K quirk entry in the kernel (and its ATA IDENTIFY responds with 512 > logical, 512 physical, even though we know it's 4K). The partitions are > all 1MB-aligned regardless. > > This is all bare-metal, by the way -- no virtualisation involved. > > I do have DTrace enabled/built on this box but I have absolutely no clue > how to go about profiling things. For example maybe output of this sort > would be helpful (but I've no idea how to get it): > > http://lists.freebsd.org/pipermail/freebsd-stable/2014-July/079276.html > > I'm certain I didn't see this behaviour in 9.x so I'd be happy to try > and track it down if I had a little bit of hand-holding. > > I've put all the things I can think of that might be relevant to "system > config/tuning bits" up here: > > http://jdc.koitsu.org/freebsd/releng10_perf_issue/ > > I should note my kernel config is slightly inaccurate (I've removed some > stuff from the file in attempt to rebuild, but building world prior to > kernel failed due to r268896 breaking world, but anyone subscribed here > has already seen the Jenkins job of that ;-) ). > > Thanks. > > -- > | Jeremy Chadwick jdc@koitsu.org | > | UNIX Systems Administrator http://jdc.koitsu.org/ | > | Making life hard for others since 1977. PGP 4BD6C0CB | > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 08:54:40 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BA1B634C for ; Sun, 20 Jul 2014 08:54:40 +0000 (UTC) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:48]) by mx1.freebsd.org (Postfix) with ESMTP id 97C0A20B2 for ; Sun, 20 Jul 2014 08:54:40 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta05.emeryville.ca.mail.comcast.net with comcast id UYta1o0011afHeLA5Yuf9G; Sun, 20 Jul 2014 08:54:39 +0000 Received: from jdc.koitsu.org ([69.181.136.108]) by omta17.emeryville.ca.mail.comcast.net with comcast id UYue1o00B2LW5AV8dYuftX; Sun, 20 Jul 2014 08:54:39 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 9BE0D1744B1; Sun, 20 Jul 2014 01:54:38 -0700 (PDT) Date: Sun, 20 Jul 2014 01:54:38 -0700 From: Jeremy Chadwick To: Adrian Chadd Subject: Re: Consistently "high" CPU load on 10.0-STABLE Message-ID: <20140720085438.GA59359@icarus.home.lan> References: <20140720062413.GA56318@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405846479; bh=4CXIcZfFNPrhDp3tW2PtX7HxZLB8GwknY2PYYMvmI7g=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=qO9D7KMAokWtwUtR9UfxaeS9irDmQ/laKy1Y/x1n6mjajVjHV9vTguZtlr2jPfeeQ WX/t5fnIHwsFIp1Y0FZXTugeFXPgb7TClgGcsMC4xESbMtSGJpQQf9VXPfl8F6AipJ fkknDUpzQ5ziQsNkY65rEp59u1MwWGTvimXtzkXXQcOsRrSCJw1IPd1334mx0xuKBc dI/9xzYgAp8/QWOzbzOpkCeyKm2N98WBW8Gr8ZL0pd3TEQ3U1xrMavQwnjNyOzVPxV X4ISh3Z8X5Oy0e3n+GaUAJ1omZ1XG/A/r8sLMxeLw3ZOJEDZoAyN+tYOhAJ3q7gSwq 8JIxOfRwqTIvQ== Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 08:54:40 -0000 Okay, so I had to install FreeBSD on a VM (on a different box) to deal with Xorg and all that jazz, then did the following on the bare-metal system: - Let it sit idle (barring cronjobs and existing daemons) for about 10 minutes - sysctl debug.ktr.mask=0 - Waited 10-15 seconds - ktrdump -ctq > ktr.out - sysctl debug.ktr.mask=0x20000000 (what the value was originally) - scp'd ktr.out to the VM box - On VM in X: python /usr/src/tools/sched/schedgraph.py ktr.out 2.8 What I end up with is an application that is a bit difficult for me to grasp. It seems to indicate spanning a time frame of 256.47 seconds, and KTR had collected 247735 events from a total of 83 sources. I can, of course, scroll through all those sources (vertically) but I'm not really sure what it is that's being graphed on a per-event basis. What the graphs (individually) represent on a vertical scale I'm not sure. Horizontally they seem to be "sectionalised" in some manner, like into blocks (possibly of time?) but I can't tell if that's "how long something was running for" and if that actually correlates with CPU load or not. This is very hard to explain in text, quite honestly, and I can't find a single example of how to use this tool anywhere online. rwatson's site has some vague information (that also seems outdated, particularly shoving the ktrdump output through sort -n). I've put a screenshot up of the relevant window, specifically the CPU n load parts. Part of me wonders if the repeated "spikes" (especially on CPU 0?) are indicators of what I'm experiencing, but I really don't know: http://jdc.koitsu.org/freebsd/releng10_perf_issue/sched01.png I'm happy to provide the ktr.out if it's of any use, by the way. My KTR kernel configuration settings on the bare metal box are: options KTR options KTR_ENTRIES=262144 options KTR_COMPILE=(KTR_SCHED) options KTR_MASK=(KTR_SCHED) Which based on reading the python script vs. what's on the web seem to be what's generally desired. I suppose I can try doing things like shutting off all the daemons I normally run and then see if the problem goes away (and if so try to track it down to a single daemon), but like I said I don't really see anything userland-process-wise suddenly start taking up CPU time. Whatever it is is "heavy" enough to cause the load to go from 0.03 to 0.24 or so within a few seconds and then settle down again. Part of me wonders if it's ZFS (periodic txg flushing or something). Oh, one thing I did find manually: top -S -H -b 999999 on two different boxes: the "swapper" thread seems interesting and I'll explain why: RELENG_10 box: 1:49AM up 5:52, 1 user, load averages: 0.32, 0.16, 0.10 0 root -16 0 0K 4912K swapin 0 1:04 0.00% [kernel{swapper}] RELENG_9 box: 1:49AM up 39 days, 8:19, 1 user, load averages: 0.04, 0.06, 0.02 0 root -16 0 0K 160K swapin 0 0:55 0.00% [kernel{swapper}] I don't know what the "swapper" thread is for or doing (I assume not related to pagedaemon?), but I find it interesting that the RELENG_10 system has already used 1:04 worth of system time (I think that's 1 minute 4 seconds worth?) for a system that's only been up 5 hours and not using any swap, while a different RELENG_9 box that's been up for 39 days and doing a lot more I/O (receiving mail, logging things, running a public web server with logs, etc.) has only used 0:55 (and is actually using 104MBytes of swap). TL;DR -- I wonder if it's "swapper" that's doing it. In the schedgraph, swapper shows up in little chunks of 10 second durations, but that may be normal. :/ On Sun, Jul 20, 2014 at 12:13:05AM -0700, Adrian Chadd wrote: > Hi, > > I don't know how to do this with dtrace, but take a look at > tools/sched/schedgraph.py and enable KTR to get some trace records. > > KTR logs the scheduler activity -and- the loadav with it. > > > -a > > > On 19 July 2014 23:24, Jeremy Chadwick wrote: > > (Please keep me CC'd as I'm not subscribed to freebsd-stable@) > > > > Today I took the liberty of upgrading my main home server from > > 9.3-STABLE (r268785) to 10.0-STABLE (r268894). The upgrade consisted of > > doing a fresh install of 10.0-STABLE on a brand new unused SSD. Most > > everything went as planned, barring a couple ports-related anomalies, > > and I seemed fairly impressed by the fact that buildworld times had > > dropped to 27 minutes and buildkernel to 4 minutes with clang (something > > I'd been avoiding like the plague for a long while). Kudos. > > > > But after an hour or so, I noticed a consistent (i.e. reproducible) > > trend: the system load average tends to hang around 0.10 to 0.15 all the > > time. There are times where the load drops to 0.03 or 0.04 but then > > something kicks it back up to 0.15 or 0.20 and then it slowly levels out > > again (over the course of a few minutes) then repeats. > > > > Obviously this is normal behaviour for a system when something is going > > on periodically. So I figured it might have been a userland process > > behaving differently under 10.x than 9.x. I let top -a -S -s 1 run and > > paid very very close attention to it for several minutes. Nothing. It > > doesn't appear to be something userland -- it appears to be something > > kernel-level, but nothing in top -S shows up as taking up any CPU time > > other than "[idle]" so I have no idea what might be doing it. > > > > The box isn't doing anything like routing network traffic/NAT, it's pure > > IPv4 (IPv6 disabled in world and kernel, and my home network does > > basically no IPv6) and sits idle most of the time fetching mail. It > > does use ZFS, but not for /, swap, /var, /tmp, or /usr. > > > > vmstat -i doesn't particularly show anything awful. All the cpuX:timer > > entries tend to fluctuate in rate, usually 120-200 or so; I'd expect an > > interrupt storm to be showing something in the 1000+ range. > > > > The only thing I can think of is the fact that the SSD being used has no > > 4K quirk entry in the kernel (and its ATA IDENTIFY responds with 512 > > logical, 512 physical, even though we know it's 4K). The partitions are > > all 1MB-aligned regardless. > > > > This is all bare-metal, by the way -- no virtualisation involved. > > > > I do have DTrace enabled/built on this box but I have absolutely no clue > > how to go about profiling things. For example maybe output of this sort > > would be helpful (but I've no idea how to get it): > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2014-July/079276.html > > > > I'm certain I didn't see this behaviour in 9.x so I'd be happy to try > > and track it down if I had a little bit of hand-holding. > > > > I've put all the things I can think of that might be relevant to "system > > config/tuning bits" up here: > > > > http://jdc.koitsu.org/freebsd/releng10_perf_issue/ > > > > I should note my kernel config is slightly inaccurate (I've removed some > > stuff from the file in attempt to rebuild, but building world prior to > > kernel failed due to r268896 breaking world, but anyone subscribed here > > has already seen the Jenkins job of that ;-) ). > > > > Thanks. > > > > -- > > | Jeremy Chadwick jdc@koitsu.org | > > | UNIX Systems Administrator http://jdc.koitsu.org/ | > > | Making life hard for others since 1977. PGP 4BD6C0CB | > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 09:05:01 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C8E9881 for ; Sun, 20 Jul 2014 09:05:01 +0000 (UTC) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BDEB217C for ; Sun, 20 Jul 2014 09:05:01 +0000 (UTC) Received: by mail-qa0-f50.google.com with SMTP id s7so4366686qap.9 for ; Sun, 20 Jul 2014 02:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=avQWXHW7yz8Xs+lGdIb3IFYUJVWRolG7OCV7sxvLBc4=; b=JpQFCgQ9l0/g/w7C9fOrH2ofDA4wBPHhZrjfXt4eiPar+0A3p3GDv+3QActlbsHhGC EO1Hz8F6qoMkoIchparCh7S4eYF9D5ogFg+welbr3JhHymDwhk8vtzUE8GZvuVQDTq2E 7lijk7tCKDFkPiOkMYURJvC4zyVkrVkOtIE8B8665zu/wk6XtgLAmBf1eJxnm7jqiNpt PYlGDEMrNyLqELsG3xUg36WqfhGDQf0OEW0qoVBuQCvNzYuuN70YZAdeRI2Ns23Twqqb gLNK34Ghi33jmxprht3UxtYO2FJ5HVezP/KkxseAFneWNhptQrecMxrLNMW0Bq1cKRSg aSEA== MIME-Version: 1.0 X-Received: by 10.140.38.169 with SMTP id t38mr25636207qgt.3.1405847100162; Sun, 20 Jul 2014 02:05:00 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.1.6 with HTTP; Sun, 20 Jul 2014 02:05:00 -0700 (PDT) In-Reply-To: <20140720085438.GA59359@icarus.home.lan> References: <20140720062413.GA56318@icarus.home.lan> <20140720085438.GA59359@icarus.home.lan> Date: Sun, 20 Jul 2014 02:05:00 -0700 X-Google-Sender-Auth: OzX6g9lIG4dX2GURF5DVBt1USak Message-ID: Subject: Re: Consistently "high" CPU load on 10.0-STABLE From: Adrian Chadd To: Jeremy Chadwick Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 09:05:01 -0000 Hi, You can zoom in to see the specific details for each event that's being scheduled. The idle/scheduled/running events are differently coloured. Look at the periods of your CPUs having >1 task scheduled and see what's currently being scheduled. Chances are there's a couple of cascading kernel threads being woken up for something and it's temporarily raising the load av to 2 for short durations. I believe there were some changes in the loadav calculation between 9 and 10. This will let you see exactly what's going on. -a On 20 July 2014 01:54, Jeremy Chadwick wrote: > > Okay, so I had to install FreeBSD on a VM (on a different box) to deal > with Xorg and all that jazz, then did the following on the bare-metal > system: > > - Let it sit idle (barring cronjobs and existing daemons) for about 10 > minutes > - sysctl debug.ktr.mask=0 > - Waited 10-15 seconds > - ktrdump -ctq > ktr.out > - sysctl debug.ktr.mask=0x20000000 (what the value was originally) > - scp'd ktr.out to the VM box > - On VM in X: python /usr/src/tools/sched/schedgraph.py ktr.out 2.8 > > What I end up with is an application that is a bit difficult for me to > grasp. It seems to indicate spanning a time frame of 256.47 seconds, > and KTR had collected 247735 events from a total of 83 sources. I can, > of course, scroll through all those sources (vertically) but I'm not > really sure what it is that's being graphed on a per-event basis. > > What the graphs (individually) represent on a vertical scale I'm not > sure. Horizontally they seem to be "sectionalised" in some manner, like > into blocks (possibly of time?) but I can't tell if that's "how long > something was running for" and if that actually correlates with CPU load > or not. > > This is very hard to explain in text, quite honestly, and I can't find a > single example of how to use this tool anywhere online. rwatson's site > has some vague information (that also seems outdated, particularly > shoving the ktrdump output through sort -n). > > I've put a screenshot up of the relevant window, specifically the CPU n > load parts. Part of me wonders if the repeated "spikes" (especially on > CPU 0?) are indicators of what I'm experiencing, but I really don't > know: > > http://jdc.koitsu.org/freebsd/releng10_perf_issue/sched01.png > > I'm happy to provide the ktr.out if it's of any use, by the way. My KTR > kernel configuration settings on the bare metal box are: > > options KTR > options KTR_ENTRIES=262144 > options KTR_COMPILE=(KTR_SCHED) > options KTR_MASK=(KTR_SCHED) > > Which based on reading the python script vs. what's on the web seem to > be what's generally desired. > > I suppose I can try doing things like shutting off all the daemons I > normally run and then see if the problem goes away (and if so try to > track it down to a single daemon), but like I said I don't really see > anything userland-process-wise suddenly start taking up CPU time. > Whatever it is is "heavy" enough to cause the load to go from 0.03 to > 0.24 or so within a few seconds and then settle down again. Part of me > wonders if it's ZFS (periodic txg flushing or something). > > Oh, one thing I did find manually: top -S -H -b 999999 on two different > boxes: the "swapper" thread seems interesting and I'll explain why: > > RELENG_10 box: > > 1:49AM up 5:52, 1 user, load averages: 0.32, 0.16, 0.10 > 0 root -16 0 0K 4912K swapin 0 1:04 0.00% [kernel{swapper}] > > RELENG_9 box: > > 1:49AM up 39 days, 8:19, 1 user, load averages: 0.04, 0.06, 0.02 > 0 root -16 0 0K 160K swapin 0 0:55 0.00% [kernel{swapper}] > > I don't know what the "swapper" thread is for or doing (I assume not > related to pagedaemon?), but I find it interesting that the RELENG_10 > system has already used 1:04 worth of system time (I think that's 1 > minute 4 seconds worth?) for a system that's only been up 5 hours and > not using any swap, while a different RELENG_9 box that's been up for 39 > days and doing a lot more I/O (receiving mail, logging things, running a > public web server with logs, etc.) has only used 0:55 (and is actually > using 104MBytes of swap). TL;DR -- I wonder if it's "swapper" that's > doing it. > > In the schedgraph, swapper shows up in little chunks of 10 second > durations, but that may be normal. :/ > > On Sun, Jul 20, 2014 at 12:13:05AM -0700, Adrian Chadd wrote: >> Hi, >> >> I don't know how to do this with dtrace, but take a look at >> tools/sched/schedgraph.py and enable KTR to get some trace records. >> >> KTR logs the scheduler activity -and- the loadav with it. >> >> >> -a >> >> >> On 19 July 2014 23:24, Jeremy Chadwick wrote: >> > (Please keep me CC'd as I'm not subscribed to freebsd-stable@) >> > >> > Today I took the liberty of upgrading my main home server from >> > 9.3-STABLE (r268785) to 10.0-STABLE (r268894). The upgrade consisted of >> > doing a fresh install of 10.0-STABLE on a brand new unused SSD. Most >> > everything went as planned, barring a couple ports-related anomalies, >> > and I seemed fairly impressed by the fact that buildworld times had >> > dropped to 27 minutes and buildkernel to 4 minutes with clang (something >> > I'd been avoiding like the plague for a long while). Kudos. >> > >> > But after an hour or so, I noticed a consistent (i.e. reproducible) >> > trend: the system load average tends to hang around 0.10 to 0.15 all the >> > time. There are times where the load drops to 0.03 or 0.04 but then >> > something kicks it back up to 0.15 or 0.20 and then it slowly levels out >> > again (over the course of a few minutes) then repeats. >> > >> > Obviously this is normal behaviour for a system when something is going >> > on periodically. So I figured it might have been a userland process >> > behaving differently under 10.x than 9.x. I let top -a -S -s 1 run and >> > paid very very close attention to it for several minutes. Nothing. It >> > doesn't appear to be something userland -- it appears to be something >> > kernel-level, but nothing in top -S shows up as taking up any CPU time >> > other than "[idle]" so I have no idea what might be doing it. >> > >> > The box isn't doing anything like routing network traffic/NAT, it's pure >> > IPv4 (IPv6 disabled in world and kernel, and my home network does >> > basically no IPv6) and sits idle most of the time fetching mail. It >> > does use ZFS, but not for /, swap, /var, /tmp, or /usr. >> > >> > vmstat -i doesn't particularly show anything awful. All the cpuX:timer >> > entries tend to fluctuate in rate, usually 120-200 or so; I'd expect an >> > interrupt storm to be showing something in the 1000+ range. >> > >> > The only thing I can think of is the fact that the SSD being used has no >> > 4K quirk entry in the kernel (and its ATA IDENTIFY responds with 512 >> > logical, 512 physical, even though we know it's 4K). The partitions are >> > all 1MB-aligned regardless. >> > >> > This is all bare-metal, by the way -- no virtualisation involved. >> > >> > I do have DTrace enabled/built on this box but I have absolutely no clue >> > how to go about profiling things. For example maybe output of this sort >> > would be helpful (but I've no idea how to get it): >> > >> > http://lists.freebsd.org/pipermail/freebsd-stable/2014-July/079276.html >> > >> > I'm certain I didn't see this behaviour in 9.x so I'd be happy to try >> > and track it down if I had a little bit of hand-holding. >> > >> > I've put all the things I can think of that might be relevant to "system >> > config/tuning bits" up here: >> > >> > http://jdc.koitsu.org/freebsd/releng10_perf_issue/ >> > >> > I should note my kernel config is slightly inaccurate (I've removed some >> > stuff from the file in attempt to rebuild, but building world prior to >> > kernel failed due to r268896 breaking world, but anyone subscribed here >> > has already seen the Jenkins job of that ;-) ). >> > >> > Thanks. >> > >> > -- >> > | Jeremy Chadwick jdc@koitsu.org | >> > | UNIX Systems Administrator http://jdc.koitsu.org/ | >> > | Making life hard for others since 1977. PGP 4BD6C0CB | >> > >> > _______________________________________________ >> > freebsd-stable@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > -- > | Jeremy Chadwick jdc@koitsu.org | > | UNIX Systems Administrator http://jdc.koitsu.org/ | > | Making life hard for others since 1977. PGP 4BD6C0CB | > From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 10:21:01 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F80A115; Sun, 20 Jul 2014 10:21:01 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 08BFE2635; Sun, 20 Jul 2014 10:21:01 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 43C52129; Sun, 20 Jul 2014 10:21:01 +0000 (UTC) Date: Sun, 20 Jul 2014 10:20:55 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org, jhb@FreeBSD.org, bapt@FreeBSD.org, hiren@FreeBSD.org, mav@FreeBSD.org Message-ID: <1837391044.20.1405851661250.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <58449660.1.1405830649448.JavaMail.jenkins@jenkins-9.freebsd.org> References: <58449660.1.1405830649448.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Build failed in Jenkins: FreeBSD_stable_10 #517 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: FAILURE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 10:21:01 -0000 See Changes: [mav] MFC r268795: Fix ctld crash on startup if target alias is not set. ------------------------------------------ [...truncated 157798 lines...] cc -O2 -pipe -DCONFIG_PATH="\"/etc/nscd.conf\"" -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -o nscd agent.o nscd.o nscdcli.o cachelib.o cacheplcs.o debug.o log.o config.o query.o mp_ws_query.o mp_rs_query.o singletons.o protocol.o parser.o passwd.o group.o services.o -lm -lpthread -lutil --- usr.bin.all__D --- 4 warnings generated. --- opiekey.1.gz --- gzip -cn > opiekey.1.gz --- usr.sbin.all__D --- --- all_subdir_ntp --- --- atolfp.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o atolfp.o --- usr.bin.all__D --- --- opiekey --- cc -O2 -pipe -I -I -DINSECURE_OVERRIDE -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -o opiekey opiekey.o -lopie -lmd --- all_subdir_opiepasswd --- ===> usr.bin/opiepasswd (all) --- opiepasswd.o --- cc -O2 -pipe -I -I -DINSECURE_OVERRIDE -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c --- usr.sbin.all__D --- --- all_subdir_periodic --- ===> usr.sbin/periodic (all) --- periodic.8.gz --- gzip -cn > periodic.8.gz --- usr.bin.all__D --- :140:7: warning: implicit declaration of function 'opieversion' is invalid in C99 [-Wimplicit-function-declaration] opieversion(); ^ :221:9: warning: implicit declaration of function 'opienewseed' is invalid in C99 [-Wimplicit-function-declaration] if (opienewseed(seed) < 0) { ^ --- all_subdir_pagesize --- --- all_subdir_opiepasswd --- :342:11: warning: implicit declaration of function 'opieinsecure' is invalid in C99 [-Wimplicit-function-declaration] if (opieinsecure() && !force) { ^ --- all_subdir_pagesize --- ===> usr.bin/pagesize (all) --- usr.sbin.all__D --- --- all_subdir_ntp --- --- atouint.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o atouint.o --- usr.bin.all__D --- --- pagesize.1.gz --- gzip -cn > pagesize.1.gz --- usr.sbin.all__D --- --- audio.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o audio.o --- all_subdir_pciconf --- --- cap.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -c --- usr.bin.all__D --- --- all_subdir_opiepasswd --- 3 warnings generated. --- opiepasswd.1.gz --- gzip -cn > opiepasswd.1.gz --- opiepasswd --- cc -O2 -pipe -I -I -DINSECURE_OVERRIDE -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -o opiepasswd opiepasswd.o -lopie -lmd --- usr.sbin.all__D --- --- all_subdir_ntp --- --- authkeys.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o authkeys.o --- usr.bin.all__D --- --- all_subdir_passwd --- ===> usr.bin/passwd (all) --- passwd.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- usr.sbin.all__D --- --- all_subdir_pciconf --- --- err.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -c --- usr.bin.all__D --- --- passwd.1.gz --- gzip -cn > passwd.1.gz --- passwd --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -o passwd passwd.o -lpam --- usr.sbin.all__D --- --- all_subdir_pkg --- ===> usr.sbin/pkg (all) --- usr.bin.all__D --- --- all_subdir_paste --- ===> usr.bin/paste (all) --- usr.sbin.all__D --- --- all_subdir_pciconf --- --- pciconf.8.gz --- --- all_subdir_ntp --- --- authreadkeys.o --- --- all_subdir_pciconf --- gzip -cn > pciconf.8.gz --- all_subdir_ntp --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o authreadkeys.o --- all_subdir_pciconf --- --- pciconf --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -o pciconf pciconf.o cap.o err.o --- usr.bin.all__D --- --- paste.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- usr.sbin.all__D --- --- all_subdir_pkg --- --- pkg.o --- cc -O2 -pipe -I -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- usr.bin.all__D --- --- all_subdir_patch --- ===> usr.bin/patch (all) --- backupfile.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- all_subdir_paste --- --- paste.1.gz --- gzip -cn > paste.1.gz --- paste --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -o paste paste.o --- usr.sbin.all__D --- --- all_subdir_ntp --- --- authusekey.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o authusekey.o --- usr.bin.all__D --- --- all_subdir_patch --- --- inp.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- mkpath.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- usr.sbin.all__D --- --- buftvtots.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o buftvtots.o --- all_subdir_pkg --- --- dns_utils.o --- cc -O2 -pipe -I -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- all_subdir_ntp --- --- caljulian.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o caljulian.o --- usr.bin.all__D --- --- all_subdir_pathchk --- ===> usr.bin/pathchk (all) --- pathchk.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- usr.sbin.all__D --- --- all_subdir_pkg --- --- config.o --- cc -O2 -pipe -I -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- all_subdir_ntp --- --- caltontp.o --- --- usr.bin.all__D --- --- all_subdir_patch --- --- patch.o --- --- usr.sbin.all__D --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o caltontp.o --- usr.bin.all__D --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- usr.sbin.all__D --- --- calyearstart.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o calyearstart.o --- usr.bin.all__D --- --- all_subdir_pathchk --- --- pathchk.1.gz --- gzip -cn > pathchk.1.gz --- pathchk --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -o pathchk pathchk.o --- usr.sbin.all__D --- --- all_subdir_pkg --- --- pkg.7.gz --- gzip -cn > pkg.7.gz --- all_subdir_pmcannotate --- --- all_subdir_ntp --- --- clocktime.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o clocktime.o --- all_subdir_pmcannotate --- ===> usr.sbin/pmcannotate (all) --- pmcannotate.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- all_subdir_ntp --- --- clocktypes.o --- --- all_subdir_pkg --- --- pkg --- --- all_subdir_ntp --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o clocktypes.o --- all_subdir_pkg --- cc -O2 -pipe -I -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -L/usr/obj -rpath /usr/lib/private -o pkg pkg.o dns_utils.o config.o -larchive -lelf -lfetch -lucl -lsbuf -lssl -lcrypto --- usr.bin.all__D --- --- all_subdir_patch --- --- pch.o --- cc -O2 -pipe -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -c --- usr.sbin.all__D --- --- all_subdir_ntp --- --- decodenetnum.o --- cc -O2 -pipe -I -I -DSYS_FREEBSD -DPARSE -DHAVE_CONFIG_H -DOPENSSL -std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -c -o decodenetnum.o --- all_subdir_pkg --- /usr/obj: undefined reference to `remainder' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [pkg] Error code 1 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_pkg] Error code 2 make[3]: stopped in --- all_subdir_pmcannotate --- A failure has been detected in another branch of the parallel make make[4]: stopped in *** [all_subdir_pmcannotate] Error code 2 make[3]: stopped in --- all_subdir_ntp --- A failure has been detected in another branch of the parallel make make[5]: stopped in *** [all] Error code 2 make[4]: stopped in 1 error make[4]: stopped in *** [all_subdir_ntp] Error code 2 make[3]: stopped in 3 errors make[3]: stopped in *** [usr.sbin.all__D] Error code 2 make[2]: stopped in --- usr.bin.all__D --- A failure has been detected in another branch of the parallel make make[4]: stopped in *** [all_subdir_patch] Error code 2 make[3]: stopped in 1 error make[3]: stopped in *** [usr.bin.all__D] Error code 2 make[2]: stopped in 2 errors make[2]: stopped in *** [everything] Error code 2 make[1]: stopped in 1 error make[1]: stopped in *** [buildworld] Error code 2 make: stopped in 1 error make: stopped in Build step 'Execute shell' marked build as failure From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 11:43:30 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0CFB1F58 for ; Sun, 20 Jul 2014 11:43:30 +0000 (UTC) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 89A892C26 for ; Sun, 20 Jul 2014 11:43:29 +0000 (UTC) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.14.9/8.14.9) with ESMTP id s6KBhMF3013035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 20 Jul 2014 13:43:23 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.14.9/8.14.9/Submit) with ESMTP id s6KBhMGX013032 for ; Sun, 20 Jul 2014 13:43:22 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Sun, 20 Jul 2014 13:43:22 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD stable Subject: stable/10 broken by r286896 Message-ID: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2055831798-1602684596-1405856602=:93123" X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.fig.ol.no X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 11:43:30 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2055831798-1602684596-1405856602=:93123 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT r268896 breaks stable/10. libucl depends on remainder() and fabs(), and needs libm.so. The attached patch add libm to usr.sbin/pkg as a temporary measure. Index: usr.sbin/pkg/Makefile =================================================================== --- usr.sbin/pkg/Makefile (revision 268917) +++ usr.sbin/pkg/Makefile (working copy) @@ -7,8 +7,8 @@ CFLAGS+=-I${.CURDIR}/../../contrib/libucl/include .PATH: ${.CURDIR}/../../contrib/libucl/include DPADD= ${LIBARCHIVE} ${LIBELF} ${LIBFETCH} ${LIBUCL} ${LIBSBUF} ${LIBSSL} \ - ${LIBCRYPTO} -LDADD= -larchive -lelf -lfetch -lucl -lsbuf -lssl -lcrypto + ${LIBCRYPTO} ${LIBM} +LDADD= -larchive -lelf -lfetch -lucl -lsbuf -lssl -lcrypto -lm USEPRIVATELIB= ucl .include -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ --2055831798-1602684596-1405856602=:93123 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=usr.sbin-pkg-Makefile.diff Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Patch for stable/10/usr.sbin/pkg/Makefile Content-Disposition: attachment; filename=usr.sbin-pkg-Makefile.diff SW5kZXg6IHVzci5zYmluL3BrZy9NYWtlZmlsZQ0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KLS0tIHVzci5zYmluL3BrZy9NYWtlZmlsZQkocmV2aXNpb24g MjY4OTE3KQ0KKysrIHVzci5zYmluL3BrZy9NYWtlZmlsZQkod29ya2luZyBj b3B5KQ0KQEAgLTcsOCArNyw4IEBADQogQ0ZMQUdTKz0tSSR7LkNVUkRJUn0v Li4vLi4vY29udHJpYi9saWJ1Y2wvaW5jbHVkZQ0KIC5QQVRIOgkkey5DVVJE SVJ9Ly4uLy4uL2NvbnRyaWIvbGlidWNsL2luY2x1ZGUNCiBEUEFERD0JJHtM SUJBUkNISVZFfSAke0xJQkVMRn0gJHtMSUJGRVRDSH0gJHtMSUJVQ0x9ICR7 TElCU0JVRn0gJHtMSUJTU0x9IFwNCi0JJHtMSUJDUllQVE99DQotTERBREQ9 CS1sYXJjaGl2ZSAtbGVsZiAtbGZldGNoIC1sdWNsIC1sc2J1ZiAtbHNzbCAt bGNyeXB0bw0KKwkke0xJQkNSWVBUT30gJHtMSUJNfQ0KK0xEQUREPQktbGFy Y2hpdmUgLWxlbGYgLWxmZXRjaCAtbHVjbCAtbHNidWYgLWxzc2wgLWxjcnlw dG8gLWxtDQogVVNFUFJJVkFURUxJQj0JdWNsDQogDQogLmluY2x1ZGUgPGJz ZC5wcm9nLm1rPg0K --2055831798-1602684596-1405856602=:93123-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 13:01:27 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A82512B4 for ; Sun, 20 Jul 2014 13:01:27 +0000 (UTC) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B74821A6 for ; Sun, 20 Jul 2014 13:01:27 +0000 (UTC) Received: by mail-we0-f174.google.com with SMTP id x48so6432732wes.5 for ; Sun, 20 Jul 2014 06:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=nsLokO1bqlCQwo+71woYZGqWPijKlpOvA9qbk7LPvRE=; b=cfTnbDbKaFUR6MmHhM/0W9Q5dH3gudbXEAmqr2RbJPOhnHQHMJ23T70cBSOJcHX5Fy rF/xQL9uNEU+jvMqRCX+iVUZgHBXvv1/CMjdXYTAv6fHe0QQJ762/pf1rvbLO572xD11 aweaaSZfqqunTHQZKSUaj6ZEo8kCUGBl2XvHDOIRGRdZj7UzF0KKN+FApuiCgzb4nonQ 0csH8PV4+/DYWu8livcW6AKnajrq0aLphsz9TCgeWPoH0GzxQ7XLhXsTnZTXvMoKsEnw b2jVE+wqcAgPspKONFJM88REWWQnHaZZe9sygGx2C5tVRR1SCB/Z1IaxNGa1towa3RVl Bn1A== X-Received: by 10.180.96.97 with SMTP id dr1mr49012379wib.19.1405861284614; Sun, 20 Jul 2014 06:01:24 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id d12sm29603524wjx.0.2014.07.20.06.01.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Jul 2014 06:01:23 -0700 (PDT) Sender: Baptiste Daroussin Date: Sun, 20 Jul 2014 15:01:20 +0200 From: Baptiste Daroussin To: Trond =?iso-8859-1?Q?Endrest=F8l?= Subject: Re: stable/10 broken by r286896 Message-ID: <20140720130120.GE26778@ivaldir.etoilebsd.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LSp5EJdfMPwZcMS1" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 13:01:27 -0000 --LSp5EJdfMPwZcMS1 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 20, 2014 at 01:43:22PM +0200, Trond Endrest=F8l wrote: > r268896 breaks stable/10. >=20 > libucl depends on remainder() and fabs(), and needs libm.so. >=20 > The attached patch add libm to usr.sbin/pkg as a temporary measure. >=20 thank you for your patch, however I have already fixed it. Sorry for the breakage. Best regards, Bapt --LSp5EJdfMPwZcMS1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPLvaAACgkQ8kTtMUmk6EwhuQCfbXwd9KZhKFy+YGooI6INmJeP EtQAoK2arsvqqEC3z+KA9l3mT3I6R0dL =KtYL -----END PGP SIGNATURE----- --LSp5EJdfMPwZcMS1-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 13:33:22 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F0DF805; Sun, 20 Jul 2014 13:33:22 +0000 (UTC) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 8D5892430; Sun, 20 Jul 2014 13:33:22 +0000 (UTC) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id A2B47180; Sun, 20 Jul 2014 13:33:22 +0000 (UTC) Date: Sun, 20 Jul 2014 13:33:21 +0000 (GMT) From: jenkins-admin@freebsd.org To: jenkins-admin@FreeBSD.org, freebsd-stable@freebsd.org, jhb@FreeBSD.org, bapt@FreeBSD.org, hiren@FreeBSD.org, mav@FreeBSD.org Message-ID: <602686981.35.1405863202432.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1837391044.20.1405851661250.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1837391044.20.1405851661250.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: Jenkins build is back to normal : FreeBSD_stable_10 #518 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Jenkins-Job: FreeBSD_stable_10 X-Jenkins-Result: SUCCESS X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 13:33:22 -0000 See From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 14:26:12 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11802485 for ; Sun, 20 Jul 2014 14:26:12 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 9F5FB2839 for ; Sun, 20 Jul 2014 14:26:11 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 5879020E7088D; Sun, 20 Jul 2014 14:26:09 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.3 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_DYNAMIC,STOX_REPLY_TYPE autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 4DF3B20E7088A; Sun, 20 Jul 2014 14:26:04 +0000 (UTC) Message-ID: <97EA8E571E634DBBAA70F7AA7F0DE97C@multiplay.co.uk> From: "Steven Hartland" To: "Jeremy Chadwick" , References: <20140720062413.GA56318@icarus.home.lan> Subject: Re: Consistently "high" CPU load on 10.0-STABLE Date: Sun, 20 Jul 2014 15:26:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 14:26:12 -0000 If you add -H -z to your top command does anything stand out? Regards Steve ----- Original Message ----- From: "Jeremy Chadwick" To: Sent: Sunday, July 20, 2014 7:24 AM Subject: Consistently "high" CPU load on 10.0-STABLE > (Please keep me CC'd as I'm not subscribed to freebsd-stable@) > > Today I took the liberty of upgrading my main home server from > 9.3-STABLE (r268785) to 10.0-STABLE (r268894). The upgrade consisted of > doing a fresh install of 10.0-STABLE on a brand new unused SSD. Most > everything went as planned, barring a couple ports-related anomalies, > and I seemed fairly impressed by the fact that buildworld times had > dropped to 27 minutes and buildkernel to 4 minutes with clang (something > I'd been avoiding like the plague for a long while). Kudos. > > But after an hour or so, I noticed a consistent (i.e. reproducible) > trend: the system load average tends to hang around 0.10 to 0.15 all the > time. There are times where the load drops to 0.03 or 0.04 but then > something kicks it back up to 0.15 or 0.20 and then it slowly levels out > again (over the course of a few minutes) then repeats. > > Obviously this is normal behaviour for a system when something is going > on periodically. So I figured it might have been a userland process > behaving differently under 10.x than 9.x. I let top -a -S -s 1 run and > paid very very close attention to it for several minutes. Nothing. It > doesn't appear to be something userland -- it appears to be something > kernel-level, but nothing in top -S shows up as taking up any CPU time > other than "[idle]" so I have no idea what might be doing it. > > The box isn't doing anything like routing network traffic/NAT, it's pure > IPv4 (IPv6 disabled in world and kernel, and my home network does > basically no IPv6) and sits idle most of the time fetching mail. It > does use ZFS, but not for /, swap, /var, /tmp, or /usr. > > vmstat -i doesn't particularly show anything awful. All the cpuX:timer > entries tend to fluctuate in rate, usually 120-200 or so; I'd expect an > interrupt storm to be showing something in the 1000+ range. > > The only thing I can think of is the fact that the SSD being used has no > 4K quirk entry in the kernel (and its ATA IDENTIFY responds with 512 > logical, 512 physical, even though we know it's 4K). The partitions are > all 1MB-aligned regardless. > > This is all bare-metal, by the way -- no virtualisation involved. > > I do have DTrace enabled/built on this box but I have absolutely no clue > how to go about profiling things. For example maybe output of this sort > would be helpful (but I've no idea how to get it): > > http://lists.freebsd.org/pipermail/freebsd-stable/2014-July/079276.html > > I'm certain I didn't see this behaviour in 9.x so I'd be happy to try > and track it down if I had a little bit of hand-holding. > > I've put all the things I can think of that might be relevant to "system > config/tuning bits" up here: > > http://jdc.koitsu.org/freebsd/releng10_perf_issue/ > > I should note my kernel config is slightly inaccurate (I've removed some > stuff from the file in attempt to rebuild, but building world prior to > kernel failed due to r268896 breaking world, but anyone subscribed here > has already seen the Jenkins job of that ;-) ). > > Thanks. > > -- > | Jeremy Chadwick jdc@koitsu.org | > | UNIX Systems Administrator http://jdc.koitsu.org/ | > | Making life hard for others since 1977. PGP 4BD6C0CB | > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 16:19:23 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0C25C863 for ; Sun, 20 Jul 2014 16:19:23 +0000 (UTC) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C0F9B2282 for ; Sun, 20 Jul 2014 16:19:22 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id j7so4497472qaq.0 for ; Sun, 20 Jul 2014 09:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=nOw3KiOClWS4VvAGAEb7NMcStnqJ7v7j7yOgtr6vvoQ=; b=fVRBA+lOpubOszk8L70tqC+VnfpSuRNyt0B6aTxkkBMstwo6AGw4YZyOZ0Oxa4Q25s PRjLih7eqhlhGOxVpr0aGL9igUeAuKtgwuBdBv9KxIs/8VKz8Q/4aooeZ8fsg6WmKPQ5 QWW6f7uSTKp3APrhKJK2BIdhlWRsSsuaRzVBaK+up1tqEwwyUUmV1+aQT9BG8bwdkSoT cIExgUfLNZ4opMwO0/esVAbwJzw4v6hHG18yo0u+Kd6/zSn29kpquvXwQ4l5gEnqQ08X QWq7f89sr8gDxPCymp3qi9+ARfUKK3NmRMFDz2WEOx0UNnfIztQvyV8bVHa8sEr4+oGf NYVA== MIME-Version: 1.0 X-Received: by 10.224.156.145 with SMTP id x17mr13542213qaw.49.1405873159383; Sun, 20 Jul 2014 09:19:19 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.1.6 with HTTP; Sun, 20 Jul 2014 09:19:19 -0700 (PDT) In-Reply-To: <20140720085438.GA59359@icarus.home.lan> References: <20140720062413.GA56318@icarus.home.lan> <20140720085438.GA59359@icarus.home.lan> Date: Sun, 20 Jul 2014 09:19:19 -0700 X-Google-Sender-Auth: 4RQ1SDg8WyMbDoJ-wIiCEL5xvpM Message-ID: Subject: Re: Consistently "high" CPU load on 10.0-STABLE From: Adrian Chadd To: Jeremy Chadwick Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 16:19:23 -0000 Hi And if you put the ktr text output you fed to schedgraph somewhere, I can fire it up locally to take a look. -a On 20 July 2014 01:54, Jeremy Chadwick wrote: > > Okay, so I had to install FreeBSD on a VM (on a different box) to deal > with Xorg and all that jazz, then did the following on the bare-metal > system: > > - Let it sit idle (barring cronjobs and existing daemons) for about 10 > minutes > - sysctl debug.ktr.mask=0 > - Waited 10-15 seconds > - ktrdump -ctq > ktr.out > - sysctl debug.ktr.mask=0x20000000 (what the value was originally) > - scp'd ktr.out to the VM box > - On VM in X: python /usr/src/tools/sched/schedgraph.py ktr.out 2.8 > > What I end up with is an application that is a bit difficult for me to > grasp. It seems to indicate spanning a time frame of 256.47 seconds, > and KTR had collected 247735 events from a total of 83 sources. I can, > of course, scroll through all those sources (vertically) but I'm not > really sure what it is that's being graphed on a per-event basis. > > What the graphs (individually) represent on a vertical scale I'm not > sure. Horizontally they seem to be "sectionalised" in some manner, like > into blocks (possibly of time?) but I can't tell if that's "how long > something was running for" and if that actually correlates with CPU load > or not. > > This is very hard to explain in text, quite honestly, and I can't find a > single example of how to use this tool anywhere online. rwatson's site > has some vague information (that also seems outdated, particularly > shoving the ktrdump output through sort -n). > > I've put a screenshot up of the relevant window, specifically the CPU n > load parts. Part of me wonders if the repeated "spikes" (especially on > CPU 0?) are indicators of what I'm experiencing, but I really don't > know: > > http://jdc.koitsu.org/freebsd/releng10_perf_issue/sched01.png > > I'm happy to provide the ktr.out if it's of any use, by the way. My KTR > kernel configuration settings on the bare metal box are: > > options KTR > options KTR_ENTRIES=262144 > options KTR_COMPILE=(KTR_SCHED) > options KTR_MASK=(KTR_SCHED) > > Which based on reading the python script vs. what's on the web seem to > be what's generally desired. > > I suppose I can try doing things like shutting off all the daemons I > normally run and then see if the problem goes away (and if so try to > track it down to a single daemon), but like I said I don't really see > anything userland-process-wise suddenly start taking up CPU time. > Whatever it is is "heavy" enough to cause the load to go from 0.03 to > 0.24 or so within a few seconds and then settle down again. Part of me > wonders if it's ZFS (periodic txg flushing or something). > > Oh, one thing I did find manually: top -S -H -b 999999 on two different > boxes: the "swapper" thread seems interesting and I'll explain why: > > RELENG_10 box: > > 1:49AM up 5:52, 1 user, load averages: 0.32, 0.16, 0.10 > 0 root -16 0 0K 4912K swapin 0 1:04 0.00% [kernel{swapper}] > > RELENG_9 box: > > 1:49AM up 39 days, 8:19, 1 user, load averages: 0.04, 0.06, 0.02 > 0 root -16 0 0K 160K swapin 0 0:55 0.00% [kernel{swapper}] > > I don't know what the "swapper" thread is for or doing (I assume not > related to pagedaemon?), but I find it interesting that the RELENG_10 > system has already used 1:04 worth of system time (I think that's 1 > minute 4 seconds worth?) for a system that's only been up 5 hours and > not using any swap, while a different RELENG_9 box that's been up for 39 > days and doing a lot more I/O (receiving mail, logging things, running a > public web server with logs, etc.) has only used 0:55 (and is actually > using 104MBytes of swap). TL;DR -- I wonder if it's "swapper" that's > doing it. > > In the schedgraph, swapper shows up in little chunks of 10 second > durations, but that may be normal. :/ > > On Sun, Jul 20, 2014 at 12:13:05AM -0700, Adrian Chadd wrote: >> Hi, >> >> I don't know how to do this with dtrace, but take a look at >> tools/sched/schedgraph.py and enable KTR to get some trace records. >> >> KTR logs the scheduler activity -and- the loadav with it. >> >> >> -a >> >> >> On 19 July 2014 23:24, Jeremy Chadwick wrote: >> > (Please keep me CC'd as I'm not subscribed to freebsd-stable@) >> > >> > Today I took the liberty of upgrading my main home server from >> > 9.3-STABLE (r268785) to 10.0-STABLE (r268894). The upgrade consisted of >> > doing a fresh install of 10.0-STABLE on a brand new unused SSD. Most >> > everything went as planned, barring a couple ports-related anomalies, >> > and I seemed fairly impressed by the fact that buildworld times had >> > dropped to 27 minutes and buildkernel to 4 minutes with clang (something >> > I'd been avoiding like the plague for a long while). Kudos. >> > >> > But after an hour or so, I noticed a consistent (i.e. reproducible) >> > trend: the system load average tends to hang around 0.10 to 0.15 all the >> > time. There are times where the load drops to 0.03 or 0.04 but then >> > something kicks it back up to 0.15 or 0.20 and then it slowly levels out >> > again (over the course of a few minutes) then repeats. >> > >> > Obviously this is normal behaviour for a system when something is going >> > on periodically. So I figured it might have been a userland process >> > behaving differently under 10.x than 9.x. I let top -a -S -s 1 run and >> > paid very very close attention to it for several minutes. Nothing. It >> > doesn't appear to be something userland -- it appears to be something >> > kernel-level, but nothing in top -S shows up as taking up any CPU time >> > other than "[idle]" so I have no idea what might be doing it. >> > >> > The box isn't doing anything like routing network traffic/NAT, it's pure >> > IPv4 (IPv6 disabled in world and kernel, and my home network does >> > basically no IPv6) and sits idle most of the time fetching mail. It >> > does use ZFS, but not for /, swap, /var, /tmp, or /usr. >> > >> > vmstat -i doesn't particularly show anything awful. All the cpuX:timer >> > entries tend to fluctuate in rate, usually 120-200 or so; I'd expect an >> > interrupt storm to be showing something in the 1000+ range. >> > >> > The only thing I can think of is the fact that the SSD being used has no >> > 4K quirk entry in the kernel (and its ATA IDENTIFY responds with 512 >> > logical, 512 physical, even though we know it's 4K). The partitions are >> > all 1MB-aligned regardless. >> > >> > This is all bare-metal, by the way -- no virtualisation involved. >> > >> > I do have DTrace enabled/built on this box but I have absolutely no clue >> > how to go about profiling things. For example maybe output of this sort >> > would be helpful (but I've no idea how to get it): >> > >> > http://lists.freebsd.org/pipermail/freebsd-stable/2014-July/079276.html >> > >> > I'm certain I didn't see this behaviour in 9.x so I'd be happy to try >> > and track it down if I had a little bit of hand-holding. >> > >> > I've put all the things I can think of that might be relevant to "system >> > config/tuning bits" up here: >> > >> > http://jdc.koitsu.org/freebsd/releng10_perf_issue/ >> > >> > I should note my kernel config is slightly inaccurate (I've removed some >> > stuff from the file in attempt to rebuild, but building world prior to >> > kernel failed due to r268896 breaking world, but anyone subscribed here >> > has already seen the Jenkins job of that ;-) ). >> > >> > Thanks. >> > >> > -- >> > | Jeremy Chadwick jdc@koitsu.org | >> > | UNIX Systems Administrator http://jdc.koitsu.org/ | >> > | Making life hard for others since 1977. PGP 4BD6C0CB | >> > >> > _______________________________________________ >> > freebsd-stable@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > -- > | Jeremy Chadwick jdc@koitsu.org | > | UNIX Systems Administrator http://jdc.koitsu.org/ | > | Making life hard for others since 1977. PGP 4BD6C0CB | > From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 17:15:59 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87AF9D43 for ; Sun, 20 Jul 2014 17:15:59 +0000 (UTC) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:96]) by mx1.freebsd.org (Postfix) with ESMTP id 6536527BE for ; Sun, 20 Jul 2014 17:15:59 +0000 (UTC) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta09.emeryville.ca.mail.comcast.net with comcast id Uh4t1o0040lTkoCA9hFy35; Sun, 20 Jul 2014 17:15:58 +0000 Received: from jdc.koitsu.org ([69.181.136.108]) by omta04.emeryville.ca.mail.comcast.net with comcast id UhFx1o0052LW5AV8QhFx0p; Sun, 20 Jul 2014 17:15:57 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id EAE611744B1; Sun, 20 Jul 2014 10:15:56 -0700 (PDT) Date: Sun, 20 Jul 2014 10:15:56 -0700 From: Jeremy Chadwick To: Adrian Chadd Subject: Re: Consistently "high" CPU load on 10.0-STABLE Message-ID: <20140720171556.GA66979@icarus.home.lan> References: <20140720062413.GA56318@icarus.home.lan> <20140720085438.GA59359@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405876558; bh=v/nUrUXrlEiuChmaeSZbPngpcMl2aEZpBezXKgrEgo4=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=WyLgiz8A2SWiRjFMFCU7nA49FfP6+l78khf42y2oROJ2gsiLmr6zjtTJ1357R3XPE tfFmNp8QV+rTwDyT9becmal1azQa3wd8SzZsZOJfs40mW43Iu0E04Hij4uyR9zWVQR /gBr1pziDvFCRAqvMz2JembnBrj5fz+AXnur1n0cdMIWR/k87JWuW9FytB73HVTrzE 8oQHwu8Anuzhgjn0rBDzBgNzZK1G7oE4kcWqc2RAK9sozCBICLkKGmh5ViZxHMKEGm F9NjHnQNA6Y23dUcQvaK42mHSVIMY+SpYaKRGifu9HhW2Tp4dJQpUVHccGyfdJaGjv XfKgrc9YEeCeQ== Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 17:15:59 -0000 It's available (ktr.out.gz): http://jdc.koitsu.org/freebsd/releng10_perf_issue/ On Sun, Jul 20, 2014 at 09:19:19AM -0700, Adrian Chadd wrote: > Hi > > And if you put the ktr text output you fed to schedgraph somewhere, I > can fire it up locally to take a look. > > > -a > > > On 20 July 2014 01:54, Jeremy Chadwick wrote: > > > > Okay, so I had to install FreeBSD on a VM (on a different box) to deal > > with Xorg and all that jazz, then did the following on the bare-metal > > system: > > > > - Let it sit idle (barring cronjobs and existing daemons) for about 10 > > minutes > > - sysctl debug.ktr.mask=0 > > - Waited 10-15 seconds > > - ktrdump -ctq > ktr.out > > - sysctl debug.ktr.mask=0x20000000 (what the value was originally) > > - scp'd ktr.out to the VM box > > - On VM in X: python /usr/src/tools/sched/schedgraph.py ktr.out 2.8 > > > > What I end up with is an application that is a bit difficult for me to > > grasp. It seems to indicate spanning a time frame of 256.47 seconds, > > and KTR had collected 247735 events from a total of 83 sources. I can, > > of course, scroll through all those sources (vertically) but I'm not > > really sure what it is that's being graphed on a per-event basis. > > > > What the graphs (individually) represent on a vertical scale I'm not > > sure. Horizontally they seem to be "sectionalised" in some manner, like > > into blocks (possibly of time?) but I can't tell if that's "how long > > something was running for" and if that actually correlates with CPU load > > or not. > > > > This is very hard to explain in text, quite honestly, and I can't find a > > single example of how to use this tool anywhere online. rwatson's site > > has some vague information (that also seems outdated, particularly > > shoving the ktrdump output through sort -n). > > > > I've put a screenshot up of the relevant window, specifically the CPU n > > load parts. Part of me wonders if the repeated "spikes" (especially on > > CPU 0?) are indicators of what I'm experiencing, but I really don't > > know: > > > > http://jdc.koitsu.org/freebsd/releng10_perf_issue/sched01.png > > > > I'm happy to provide the ktr.out if it's of any use, by the way. My KTR > > kernel configuration settings on the bare metal box are: > > > > options KTR > > options KTR_ENTRIES=262144 > > options KTR_COMPILE=(KTR_SCHED) > > options KTR_MASK=(KTR_SCHED) > > > > Which based on reading the python script vs. what's on the web seem to > > be what's generally desired. > > > > I suppose I can try doing things like shutting off all the daemons I > > normally run and then see if the problem goes away (and if so try to > > track it down to a single daemon), but like I said I don't really see > > anything userland-process-wise suddenly start taking up CPU time. > > Whatever it is is "heavy" enough to cause the load to go from 0.03 to > > 0.24 or so within a few seconds and then settle down again. Part of me > > wonders if it's ZFS (periodic txg flushing or something). > > > > Oh, one thing I did find manually: top -S -H -b 999999 on two different > > boxes: the "swapper" thread seems interesting and I'll explain why: > > > > RELENG_10 box: > > > > 1:49AM up 5:52, 1 user, load averages: 0.32, 0.16, 0.10 > > 0 root -16 0 0K 4912K swapin 0 1:04 0.00% [kernel{swapper}] > > > > RELENG_9 box: > > > > 1:49AM up 39 days, 8:19, 1 user, load averages: 0.04, 0.06, 0.02 > > 0 root -16 0 0K 160K swapin 0 0:55 0.00% [kernel{swapper}] > > > > I don't know what the "swapper" thread is for or doing (I assume not > > related to pagedaemon?), but I find it interesting that the RELENG_10 > > system has already used 1:04 worth of system time (I think that's 1 > > minute 4 seconds worth?) for a system that's only been up 5 hours and > > not using any swap, while a different RELENG_9 box that's been up for 39 > > days and doing a lot more I/O (receiving mail, logging things, running a > > public web server with logs, etc.) has only used 0:55 (and is actually > > using 104MBytes of swap). TL;DR -- I wonder if it's "swapper" that's > > doing it. > > > > In the schedgraph, swapper shows up in little chunks of 10 second > > durations, but that may be normal. :/ > > > > On Sun, Jul 20, 2014 at 12:13:05AM -0700, Adrian Chadd wrote: > >> Hi, > >> > >> I don't know how to do this with dtrace, but take a look at > >> tools/sched/schedgraph.py and enable KTR to get some trace records. > >> > >> KTR logs the scheduler activity -and- the loadav with it. > >> > >> > >> -a > >> > >> > >> On 19 July 2014 23:24, Jeremy Chadwick wrote: > >> > (Please keep me CC'd as I'm not subscribed to freebsd-stable@) > >> > > >> > Today I took the liberty of upgrading my main home server from > >> > 9.3-STABLE (r268785) to 10.0-STABLE (r268894). The upgrade consisted of > >> > doing a fresh install of 10.0-STABLE on a brand new unused SSD. Most > >> > everything went as planned, barring a couple ports-related anomalies, > >> > and I seemed fairly impressed by the fact that buildworld times had > >> > dropped to 27 minutes and buildkernel to 4 minutes with clang (something > >> > I'd been avoiding like the plague for a long while). Kudos. > >> > > >> > But after an hour or so, I noticed a consistent (i.e. reproducible) > >> > trend: the system load average tends to hang around 0.10 to 0.15 all the > >> > time. There are times where the load drops to 0.03 or 0.04 but then > >> > something kicks it back up to 0.15 or 0.20 and then it slowly levels out > >> > again (over the course of a few minutes) then repeats. > >> > > >> > Obviously this is normal behaviour for a system when something is going > >> > on periodically. So I figured it might have been a userland process > >> > behaving differently under 10.x than 9.x. I let top -a -S -s 1 run and > >> > paid very very close attention to it for several minutes. Nothing. It > >> > doesn't appear to be something userland -- it appears to be something > >> > kernel-level, but nothing in top -S shows up as taking up any CPU time > >> > other than "[idle]" so I have no idea what might be doing it. > >> > > >> > The box isn't doing anything like routing network traffic/NAT, it's pure > >> > IPv4 (IPv6 disabled in world and kernel, and my home network does > >> > basically no IPv6) and sits idle most of the time fetching mail. It > >> > does use ZFS, but not for /, swap, /var, /tmp, or /usr. > >> > > >> > vmstat -i doesn't particularly show anything awful. All the cpuX:timer > >> > entries tend to fluctuate in rate, usually 120-200 or so; I'd expect an > >> > interrupt storm to be showing something in the 1000+ range. > >> > > >> > The only thing I can think of is the fact that the SSD being used has no > >> > 4K quirk entry in the kernel (and its ATA IDENTIFY responds with 512 > >> > logical, 512 physical, even though we know it's 4K). The partitions are > >> > all 1MB-aligned regardless. > >> > > >> > This is all bare-metal, by the way -- no virtualisation involved. > >> > > >> > I do have DTrace enabled/built on this box but I have absolutely no clue > >> > how to go about profiling things. For example maybe output of this sort > >> > would be helpful (but I've no idea how to get it): > >> > > >> > http://lists.freebsd.org/pipermail/freebsd-stable/2014-July/079276.html > >> > > >> > I'm certain I didn't see this behaviour in 9.x so I'd be happy to try > >> > and track it down if I had a little bit of hand-holding. > >> > > >> > I've put all the things I can think of that might be relevant to "system > >> > config/tuning bits" up here: > >> > > >> > http://jdc.koitsu.org/freebsd/releng10_perf_issue/ > >> > > >> > I should note my kernel config is slightly inaccurate (I've removed some > >> > stuff from the file in attempt to rebuild, but building world prior to > >> > kernel failed due to r268896 breaking world, but anyone subscribed here > >> > has already seen the Jenkins job of that ;-) ). > >> > > >> > Thanks. > >> > > >> > -- > >> > | Jeremy Chadwick jdc@koitsu.org | > >> > | UNIX Systems Administrator http://jdc.koitsu.org/ | > >> > | Making life hard for others since 1977. PGP 4BD6C0CB | > >> > > >> > _______________________________________________ > >> > freebsd-stable@freebsd.org mailing list > >> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > >> _______________________________________________ > >> freebsd-stable@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > > -- > > | Jeremy Chadwick jdc@koitsu.org | > > | UNIX Systems Administrator http://jdc.koitsu.org/ | > > | Making life hard for others since 1977. PGP 4BD6C0CB | > > -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 17:35:26 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16AA5360 for ; Sun, 20 Jul 2014 17:35:26 +0000 (UTC) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:212]) by mx1.freebsd.org (Postfix) with ESMTP id EA5C12968 for ; Sun, 20 Jul 2014 17:35:25 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta14.emeryville.ca.mail.comcast.net with comcast id UhYi1o0051vN32cAEhbR34; Sun, 20 Jul 2014 17:35:25 +0000 Received: from jdc.koitsu.org ([69.181.136.108]) by omta22.emeryville.ca.mail.comcast.net with comcast id UhbQ1o00A2LW5AV8ihbQTc; Sun, 20 Jul 2014 17:35:24 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1C83E1744B1; Sun, 20 Jul 2014 10:35:24 -0700 (PDT) Date: Sun, 20 Jul 2014 10:35:24 -0700 From: Jeremy Chadwick To: Steven Hartland Subject: Re: Consistently "high" CPU load on 10.0-STABLE Message-ID: <20140720173524.GA67065@icarus.home.lan> References: <20140720062413.GA56318@icarus.home.lan> <97EA8E571E634DBBAA70F7AA7F0DE97C@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <97EA8E571E634DBBAA70F7AA7F0DE97C@multiplay.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405877725; bh=2H4EI0h84RJ0XyQp6v8iiXZHVABlXJI0fwO8JvEFml0=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=m5aPk/zW47ccmzAHvcdAvvU30PV8o3qoACv7Nmp4W4mI0rwUja8ToNoss89NVSgyi EZQ4cgZ8VAk7gB6cyXjXlmFJT2M3L9ELWv129v2IrdOeB6TcGr5pw7IDMveorHNyV3 85gAkCc6lWFqJee7aukHx13TT1el4D34DlcR3gBSNkHnzZU1R11aF4a4dpjPEjXg28 jB/f2N+uemkmmnCoc9/woGn/Ry1jzzCJcVH1308MOY+OoKR4rTsCou9aqCqh3rurU7 J8uo604x4q8v50G+BHH02bKBYzb8YqVazZPGVv0GmEpQJjrtns/jL9P3VsEwduNJ8W 0jCU/ja0XjDNA== Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 17:35:26 -0000 Yes and no, heh... :-) Using top -a -H -S -z -s 1 and watching very very closely, what I end up seeing is that occasionally syncer reaches WCPU percentages of around 0.50% (or maybe higher) -- but when that happens, the actual load average **does not** suddenly increase. The load just seems to go from like 0.01 or 0.02 to 0.12 or 0.20 sporadically with no real evidence of "why" in top. Possibly this is because I'm using -s 1 (one second update intervals) and whatever happens is so fast/quick that it lasts less than a second / top doesn't catch it, but still impacts the load? Anyway, the "top" processes per TIME in the above command are here: PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 17 root 16 - 0K 16K syncer 2 1:31 0.49% syncer 0 root -16 0 0K 4912K swapin 0 1:04 0.00% kernel{swapper} 0 root -92 0 0K 4912K - 2 0:17 0.00% kernel{em0 que} 1767 root 20 0 57312K 10104K select 1 0:15 0.00% smbd 12 root -60 - 0K 528K WAIT 0 0:13 0.00% intr{swi4: clock} 643 dhcpd 20 0 24524K 13044K select 1 0:07 0.00% dhcpd 12 root -88 - 0K 528K WAIT 1 0:04 0.00% intr{irq259: ahci0:ch} 14 root -16 - 0K 16K - 2 0:04 0.00% rand_harvestq 58515 jdc 20 0 37028K 6196K select 2 0:03 0.00% sshd 420 bind 20 0 70872K 36552K kqread 0 0:02 0.00% named{named} 19 root 20 - 0K 16K sdflus 2 0:02 0.00% softdepflush 420 bind 20 0 70872K 36552K uwait 3 0:02 0.00% named{named} This is with a system uptime of 14 hours. Comparatively, the RELENG_9 box I have (although it's on a VPS), which does a lot more in general and has an uptime of 39 days, shows something like this: PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root -60 - 0K 224K WAIT 0 132:49 0.00% intr{swi4: clock} 0 root -92 0 0K 160K - 0 89:01 0.00% kernel{em0 taskq} 17 root 16 - 0K 16K syncer 0 45:46 0.00% syncer 12 root -88 - 0K 224K WAIT 1 16:31 0.00% intr{irq14: ata0} 12 root -60 - 0K 224K WAIT 1 12:52 0.00% intr{swi4: clock} 13 root -8 - 0K 48K - 1 8:03 0.00% geom{g_down} 15490 halbot 20 0 76172K 22532K select 0 6:34 0.00% perl 593 bind 20 0 92288K 23740K uwait 1 4:39 0.00% named{named} 593 bind 20 0 92288K 23740K uwait 0 4:36 0.00% named{named} So syncer looks like it might be about right for both systems, but "swapper" (still not sure what that is exactly) sure seems to be much more busy on the RELENG_10 box doing nothing vs. the RELENG_9 box. Here's the swapper line from the RELENG_9 box: $ top -a -H -S -b 9999 | grep swapper 0 root -16 0 0K 160K swapin 0 0:55 0.00% kernel{swapper} It's the only suspect I have at this point but it's not very good evidence of anything. :/ Maybe I can use while : ; do top -a -S -H -z -b 99999 >> somelog.txt ; sleep 0.25 ; done and let that run for a while in hopes of catching something? But I also worry that such a test would actually impact the load itself. On Sun, Jul 20, 2014 at 03:26:02PM +0100, Steven Hartland wrote: > If you add -H -z to your top command does anything stand out? > > Regards > Steve > ----- Original Message ----- > From: "Jeremy Chadwick" > To: > Sent: Sunday, July 20, 2014 7:24 AM > Subject: Consistently "high" CPU load on 10.0-STABLE > > > > (Please keep me CC'd as I'm not subscribed to freebsd-stable@) > > > > Today I took the liberty of upgrading my main home server from > > 9.3-STABLE (r268785) to 10.0-STABLE (r268894). The upgrade consisted of > > doing a fresh install of 10.0-STABLE on a brand new unused SSD. Most > > everything went as planned, barring a couple ports-related anomalies, > > and I seemed fairly impressed by the fact that buildworld times had > > dropped to 27 minutes and buildkernel to 4 minutes with clang (something > > I'd been avoiding like the plague for a long while). Kudos. > > > > But after an hour or so, I noticed a consistent (i.e. reproducible) > > trend: the system load average tends to hang around 0.10 to 0.15 all the > > time. There are times where the load drops to 0.03 or 0.04 but then > > something kicks it back up to 0.15 or 0.20 and then it slowly levels out > > again (over the course of a few minutes) then repeats. > > > > Obviously this is normal behaviour for a system when something is going > > on periodically. So I figured it might have been a userland process > > behaving differently under 10.x than 9.x. I let top -a -S -s 1 run and > > paid very very close attention to it for several minutes. Nothing. It > > doesn't appear to be something userland -- it appears to be something > > kernel-level, but nothing in top -S shows up as taking up any CPU time > > other than "[idle]" so I have no idea what might be doing it. > > > > The box isn't doing anything like routing network traffic/NAT, it's pure > > IPv4 (IPv6 disabled in world and kernel, and my home network does > > basically no IPv6) and sits idle most of the time fetching mail. It > > does use ZFS, but not for /, swap, /var, /tmp, or /usr. > > > > vmstat -i doesn't particularly show anything awful. All the cpuX:timer > > entries tend to fluctuate in rate, usually 120-200 or so; I'd expect an > > interrupt storm to be showing something in the 1000+ range. > > > > The only thing I can think of is the fact that the SSD being used has no > > 4K quirk entry in the kernel (and its ATA IDENTIFY responds with 512 > > logical, 512 physical, even though we know it's 4K). The partitions are > > all 1MB-aligned regardless. > > > > This is all bare-metal, by the way -- no virtualisation involved. > > > > I do have DTrace enabled/built on this box but I have absolutely no clue > > how to go about profiling things. For example maybe output of this sort > > would be helpful (but I've no idea how to get it): > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2014-July/079276.html > > > > I'm certain I didn't see this behaviour in 9.x so I'd be happy to try > > and track it down if I had a little bit of hand-holding. > > > > I've put all the things I can think of that might be relevant to "system > > config/tuning bits" up here: > > > > http://jdc.koitsu.org/freebsd/releng10_perf_issue/ > > > > I should note my kernel config is slightly inaccurate (I've removed some > > stuff from the file in attempt to rebuild, but building world prior to > > kernel failed due to r268896 breaking world, but anyone subscribed here > > has already seen the Jenkins job of that ;-) ). > > > > Thanks. > > > > -- > > | Jeremy Chadwick jdc@koitsu.org | > > | UNIX Systems Administrator http://jdc.koitsu.org/ | > > | Making life hard for others since 1977. PGP 4BD6C0CB | > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 19:09:58 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73118689 for ; Sun, 20 Jul 2014 19:09:58 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 2432D21A2 for ; Sun, 20 Jul 2014 19:09:57 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id BD5FD20E7088C; Sun, 20 Jul 2014 19:09:55 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.3 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_DYNAMIC,STOX_REPLY_TYPE autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 9F82720E7088A; Sun, 20 Jul 2014 19:09:51 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Jeremy Chadwick" References: <20140720062413.GA56318@icarus.home.lan> <97EA8E571E634DBBAA70F7AA7F0DE97C@multiplay.co.uk> <20140720173524.GA67065@icarus.home.lan> Subject: Re: Consistently "high" CPU load on 10.0-STABLE Date: Sun, 20 Jul 2014 20:09:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 19:09:58 -0000 Hmm does vmstat -s indicate that 10 is swapping much more than 9? I know there was some issues in early 10 which resulted in it swapping more but I was under the impression this was fixed by: http://svnweb.freebsd.org/base?view=revision&revision=265944 http://svnweb.freebsd.org/base?view=revision&revision=265945 May be there's still and issue there? Regards Steve ----- Original Message ----- From: "Jeremy Chadwick" To: "Steven Hartland" Cc: Sent: Sunday, July 20, 2014 6:35 PM Subject: Re: Consistently "high" CPU load on 10.0-STABLE > Yes and no, heh... :-) > > Using top -a -H -S -z -s 1 and watching very very closely, what I end up > seeing is that occasionally syncer reaches WCPU percentages of around > 0.50% (or maybe higher) -- but when that happens, the actual load average > **does not** suddenly increase. > > The load just seems to go from like 0.01 or 0.02 to 0.12 or 0.20 > sporadically with no real evidence of "why" in top. Possibly this is > because I'm using -s 1 (one second update intervals) and whatever > happens is so fast/quick that it lasts less than a second / top doesn't > catch it, but still impacts the load? > > Anyway, the "top" processes per TIME in the above command are here: > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 17 root 16 - 0K 16K syncer 2 1:31 0.49% syncer > 0 root -16 0 0K 4912K swapin 0 1:04 0.00% kernel{swapper} > 0 root -92 0 0K 4912K - 2 0:17 0.00% kernel{em0 que} > 1767 root 20 0 57312K 10104K select 1 0:15 0.00% smbd > 12 root -60 - 0K 528K WAIT 0 0:13 0.00% intr{swi4: clock} > 643 dhcpd 20 0 24524K 13044K select 1 0:07 0.00% dhcpd > 12 root -88 - 0K 528K WAIT 1 0:04 0.00% intr{irq259: ahci0:ch} > 14 root -16 - 0K 16K - 2 0:04 0.00% rand_harvestq > 58515 jdc 20 0 37028K 6196K select 2 0:03 0.00% sshd > 420 bind 20 0 70872K 36552K kqread 0 0:02 0.00% named{named} > 19 root 20 - 0K 16K sdflus 2 0:02 0.00% softdepflush > 420 bind 20 0 70872K 36552K uwait 3 0:02 0.00% named{named} > > This is with a system uptime of 14 hours. > > Comparatively, the RELENG_9 box I have (although it's on a VPS), which > does a lot more in general and has an uptime of 39 days, shows something > like this: > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > 12 root -60 - 0K 224K WAIT 0 132:49 0.00% intr{swi4: clock} > 0 root -92 0 0K 160K - 0 89:01 0.00% kernel{em0 taskq} > 17 root 16 - 0K 16K syncer 0 45:46 0.00% syncer > 12 root -88 - 0K 224K WAIT 1 16:31 0.00% intr{irq14: ata0} > 12 root -60 - 0K 224K WAIT 1 12:52 0.00% intr{swi4: clock} > 13 root -8 - 0K 48K - 1 8:03 0.00% geom{g_down} > 15490 halbot 20 0 76172K 22532K select 0 6:34 0.00% perl > 593 bind 20 0 92288K 23740K uwait 1 4:39 0.00% named{named} > 593 bind 20 0 92288K 23740K uwait 0 4:36 0.00% named{named} > > So syncer looks like it might be about right for both systems, but > "swapper" (still not sure what that is exactly) sure seems to be much > more busy on the RELENG_10 box doing nothing vs. the RELENG_9 box. > Here's the swapper line from the RELENG_9 box: > > $ top -a -H -S -b 9999 | grep swapper > 0 root -16 0 0K 160K swapin 0 0:55 0.00% kernel{swapper} > > It's the only suspect I have at this point but it's not very good > evidence of anything. :/ > > Maybe I can use while : ; do top -a -S -H -z -b 99999 >> somelog.txt ; > sleep 0.25 ; done and let that run for a while in hopes of catching > something? But I also worry that such a test would actually impact the > load itself. > > On Sun, Jul 20, 2014 at 03:26:02PM +0100, Steven Hartland wrote: >> If you add -H -z to your top command does anything stand out? >> >> Regards >> Steve >> ----- Original Message ----- >> From: "Jeremy Chadwick" >> To: >> Sent: Sunday, July 20, 2014 7:24 AM >> Subject: Consistently "high" CPU load on 10.0-STABLE >> >> >> > (Please keep me CC'd as I'm not subscribed to freebsd-stable@) >> > >> > Today I took the liberty of upgrading my main home server from >> > 9.3-STABLE (r268785) to 10.0-STABLE (r268894). The upgrade consisted of >> > doing a fresh install of 10.0-STABLE on a brand new unused SSD. Most >> > everything went as planned, barring a couple ports-related anomalies, >> > and I seemed fairly impressed by the fact that buildworld times had >> > dropped to 27 minutes and buildkernel to 4 minutes with clang (something >> > I'd been avoiding like the plague for a long while). Kudos. >> > >> > But after an hour or so, I noticed a consistent (i.e. reproducible) >> > trend: the system load average tends to hang around 0.10 to 0.15 all the >> > time. There are times where the load drops to 0.03 or 0.04 but then >> > something kicks it back up to 0.15 or 0.20 and then it slowly levels out >> > again (over the course of a few minutes) then repeats. >> > >> > Obviously this is normal behaviour for a system when something is going >> > on periodically. So I figured it might have been a userland process >> > behaving differently under 10.x than 9.x. I let top -a -S -s 1 run and >> > paid very very close attention to it for several minutes. Nothing. It >> > doesn't appear to be something userland -- it appears to be something >> > kernel-level, but nothing in top -S shows up as taking up any CPU time >> > other than "[idle]" so I have no idea what might be doing it. >> > >> > The box isn't doing anything like routing network traffic/NAT, it's pure >> > IPv4 (IPv6 disabled in world and kernel, and my home network does >> > basically no IPv6) and sits idle most of the time fetching mail. It >> > does use ZFS, but not for /, swap, /var, /tmp, or /usr. >> > >> > vmstat -i doesn't particularly show anything awful. All the cpuX:timer >> > entries tend to fluctuate in rate, usually 120-200 or so; I'd expect an >> > interrupt storm to be showing something in the 1000+ range. >> > >> > The only thing I can think of is the fact that the SSD being used has no >> > 4K quirk entry in the kernel (and its ATA IDENTIFY responds with 512 >> > logical, 512 physical, even though we know it's 4K). The partitions are >> > all 1MB-aligned regardless. >> > >> > This is all bare-metal, by the way -- no virtualisation involved. >> > >> > I do have DTrace enabled/built on this box but I have absolutely no clue >> > how to go about profiling things. For example maybe output of this sort >> > would be helpful (but I've no idea how to get it): >> > >> > http://lists.freebsd.org/pipermail/freebsd-stable/2014-July/079276.html >> > >> > I'm certain I didn't see this behaviour in 9.x so I'd be happy to try >> > and track it down if I had a little bit of hand-holding. >> > >> > I've put all the things I can think of that might be relevant to "system >> > config/tuning bits" up here: >> > >> > http://jdc.koitsu.org/freebsd/releng10_perf_issue/ >> > >> > I should note my kernel config is slightly inaccurate (I've removed some >> > stuff from the file in attempt to rebuild, but building world prior to >> > kernel failed due to r268896 breaking world, but anyone subscribed here >> > has already seen the Jenkins job of that ;-) ). >> > >> > Thanks. >> > >> > -- >> > | Jeremy Chadwick jdc@koitsu.org | >> > | UNIX Systems Administrator http://jdc.koitsu.org/ | >> > | Making life hard for others since 1977. PGP 4BD6C0CB | >> > >> > _______________________________________________ >> > freebsd-stable@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > > > -- > | Jeremy Chadwick jdc@koitsu.org | > | UNIX Systems Administrator http://jdc.koitsu.org/ | > | Making life hard for others since 1977. PGP 4BD6C0CB | > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 20:16:58 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51F5EBC3 for ; Sun, 20 Jul 2014 20:16:58 +0000 (UTC) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:80]) by mx1.freebsd.org (Postfix) with ESMTP id 2FDF9277A for ; Sun, 20 Jul 2014 20:16:57 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta08.emeryville.ca.mail.comcast.net with comcast id UkAX1o0030vp7WLA8kGwyD; Sun, 20 Jul 2014 20:16:56 +0000 Received: from jdc.koitsu.org ([69.181.136.108]) by omta05.emeryville.ca.mail.comcast.net with comcast id UkGv1o0082LW5AV8RkGv67; Sun, 20 Jul 2014 20:16:56 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 569261744B1; Sun, 20 Jul 2014 13:16:55 -0700 (PDT) Date: Sun, 20 Jul 2014 13:16:55 -0700 From: Jeremy Chadwick To: Steven Hartland Subject: Re: Consistently "high" CPU load on 10.0-STABLE Message-ID: <20140720201655.GA70545@icarus.home.lan> References: <20140720062413.GA56318@icarus.home.lan> <97EA8E571E634DBBAA70F7AA7F0DE97C@multiplay.co.uk> <20140720173524.GA67065@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405887416; bh=PsrQae0hcSHFZgsJWLOiEogNw1Uv/fNHtkY7eRTMYLE=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=d9/nMi6cFLV6Gue39MssauQPAAi1jaNqNRGpcUMwQVBT01MAFlvaNQ6mk6eyjtgnY GDEGe9axLszkhHf4qGyXQfTKciVqF+rw90bkMB0ctzLTKyW0yCqvatjXk0H+AUksBl 2dVe47N5osQvcRNpYX5sk+CQGdNFfo0SzfGNQJdc6dTrf1sA1Lb523rSzLnSZATEB2 KXYEFATntYKhwvGthoKds2wxeM135lg/drZQgPqn0n239BrkD2D+vMh+qmc4Ff4Km0 fbqPgV+/t3cgo1vPHXyaxcwPKqmCV/fGB9oCy4swxddQlt2cR0elQ7VPXMklASxdU1 NlT7OTdX+UG8w== Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 20:16:58 -0000 I suppose I could try "reverting" r265944 + r265945 and see if there's any improvement, and if not, then try "reverting" r254304 and see if there's any behavioural change. In the interim, I ended up writing this silly one-liner: while : ; do (uptime ; vmstat -s ; echo) | tee -a uptime_vmstat_s.txt ; sleep 2 ; done Then waited for moments where the load suddenly shot up when the system really wasn't (from my perspective) doing anything. An example (a small snippet from the log, where the load went from 0.06 to 0.30 for no reason I can discern, but the full log has some other occurrences too): http://jdc.koitsu.org/freebsd/releng10_perf_issue/uptime_vmstat_s.txt Obviously that output for analysis is not ideal/difficult for a human to read, so I can write a perl or awk script which accomplishes the same thing -- focusing on specific vmstat -s fields/lines and prints both the load in addition to deltas (between previous run and most recent run) between statistics so we can see what counters suddenly "jump" in correlation with load average jumping up. Think of it like a "vmstat 1" or "iostat 1" combined with printing the load, all on one line. I just need to know what lines in vmstat -s are of interest. One thing I haven't tried is booting the system into single-user and letting it sit there + see if the issue happens then. But I have tried these with no change in behaviour: - Shut off samba, isc-dhcpd, named, apache22, redis, and powerd - Commented out all cron jobs - Ran swapoff -a I'm hoping this isn't some ZFS-related thing. (Yes I can try to rule out ZFS if necessary, but I gotta copy data over to UFS filesystems and so on to make the system usable in that state; thankfully I keep root/swap/var/tmp/usr on UFS). On Sun, Jul 20, 2014 at 08:09:49PM +0100, Steven Hartland wrote: > Hmm does vmstat -s indicate that 10 is swapping much more than 9? > > I know there was some issues in early 10 which resulted in it > swapping more but I was under the impression this was fixed by: > http://svnweb.freebsd.org/base?view=revision&revision=265944 > http://svnweb.freebsd.org/base?view=revision&revision=265945 > > May be there's still and issue there? > > Regards > Steve > ----- Original Message ----- > From: "Jeremy Chadwick" > To: "Steven Hartland" > Cc: > Sent: Sunday, July 20, 2014 6:35 PM > Subject: Re: Consistently "high" CPU load on 10.0-STABLE > > > > Yes and no, heh... :-) > > > > Using top -a -H -S -z -s 1 and watching very very closely, what I end up > > seeing is that occasionally syncer reaches WCPU percentages of around > > 0.50% (or maybe higher) -- but when that happens, the actual load average > > **does not** suddenly increase. > > > > The load just seems to go from like 0.01 or 0.02 to 0.12 or 0.20 > > sporadically with no real evidence of "why" in top. Possibly this is > > because I'm using -s 1 (one second update intervals) and whatever > > happens is so fast/quick that it lasts less than a second / top doesn't > > catch it, but still impacts the load? > > > > Anyway, the "top" processes per TIME in the above command are here: > > > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > 17 root 16 - 0K 16K syncer 2 1:31 0.49% syncer > > 0 root -16 0 0K 4912K swapin 0 1:04 0.00% kernel{swapper} > > 0 root -92 0 0K 4912K - 2 0:17 0.00% kernel{em0 que} > > 1767 root 20 0 57312K 10104K select 1 0:15 0.00% smbd > > 12 root -60 - 0K 528K WAIT 0 0:13 0.00% intr{swi4: clock} > > 643 dhcpd 20 0 24524K 13044K select 1 0:07 0.00% dhcpd > > 12 root -88 - 0K 528K WAIT 1 0:04 0.00% intr{irq259: ahci0:ch} > > 14 root -16 - 0K 16K - 2 0:04 0.00% rand_harvestq > > 58515 jdc 20 0 37028K 6196K select 2 0:03 0.00% sshd > > 420 bind 20 0 70872K 36552K kqread 0 0:02 0.00% named{named} > > 19 root 20 - 0K 16K sdflus 2 0:02 0.00% softdepflush > > 420 bind 20 0 70872K 36552K uwait 3 0:02 0.00% named{named} > > > > This is with a system uptime of 14 hours. > > > > Comparatively, the RELENG_9 box I have (although it's on a VPS), which > > does a lot more in general and has an uptime of 39 days, shows something > > like this: > > > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > > 12 root -60 - 0K 224K WAIT 0 132:49 0.00% intr{swi4: clock} > > 0 root -92 0 0K 160K - 0 89:01 0.00% kernel{em0 taskq} > > 17 root 16 - 0K 16K syncer 0 45:46 0.00% syncer > > 12 root -88 - 0K 224K WAIT 1 16:31 0.00% intr{irq14: ata0} > > 12 root -60 - 0K 224K WAIT 1 12:52 0.00% intr{swi4: clock} > > 13 root -8 - 0K 48K - 1 8:03 0.00% geom{g_down} > > 15490 halbot 20 0 76172K 22532K select 0 6:34 0.00% perl > > 593 bind 20 0 92288K 23740K uwait 1 4:39 0.00% named{named} > > 593 bind 20 0 92288K 23740K uwait 0 4:36 0.00% named{named} > > > > So syncer looks like it might be about right for both systems, but > > "swapper" (still not sure what that is exactly) sure seems to be much > > more busy on the RELENG_10 box doing nothing vs. the RELENG_9 box. > > Here's the swapper line from the RELENG_9 box: > > > > $ top -a -H -S -b 9999 | grep swapper > > 0 root -16 0 0K 160K swapin 0 0:55 0.00% kernel{swapper} > > > > It's the only suspect I have at this point but it's not very good > > evidence of anything. :/ > > > > Maybe I can use while : ; do top -a -S -H -z -b 99999 >> somelog.txt ; > > sleep 0.25 ; done and let that run for a while in hopes of catching > > something? But I also worry that such a test would actually impact the > > load itself. > > > > On Sun, Jul 20, 2014 at 03:26:02PM +0100, Steven Hartland wrote: > >> If you add -H -z to your top command does anything stand out? > >> > >> Regards > >> Steve > >> ----- Original Message ----- > >> From: "Jeremy Chadwick" > >> To: > >> Sent: Sunday, July 20, 2014 7:24 AM > >> Subject: Consistently "high" CPU load on 10.0-STABLE > >> > >> > >> > (Please keep me CC'd as I'm not subscribed to freebsd-stable@) > >> > > >> > Today I took the liberty of upgrading my main home server from > >> > 9.3-STABLE (r268785) to 10.0-STABLE (r268894). The upgrade consisted of > >> > doing a fresh install of 10.0-STABLE on a brand new unused SSD. Most > >> > everything went as planned, barring a couple ports-related anomalies, > >> > and I seemed fairly impressed by the fact that buildworld times had > >> > dropped to 27 minutes and buildkernel to 4 minutes with clang (something > >> > I'd been avoiding like the plague for a long while). Kudos. > >> > > >> > But after an hour or so, I noticed a consistent (i.e. reproducible) > >> > trend: the system load average tends to hang around 0.10 to 0.15 all the > >> > time. There are times where the load drops to 0.03 or 0.04 but then > >> > something kicks it back up to 0.15 or 0.20 and then it slowly levels out > >> > again (over the course of a few minutes) then repeats. > >> > > >> > Obviously this is normal behaviour for a system when something is going > >> > on periodically. So I figured it might have been a userland process > >> > behaving differently under 10.x than 9.x. I let top -a -S -s 1 run and > >> > paid very very close attention to it for several minutes. Nothing. It > >> > doesn't appear to be something userland -- it appears to be something > >> > kernel-level, but nothing in top -S shows up as taking up any CPU time > >> > other than "[idle]" so I have no idea what might be doing it. > >> > > >> > The box isn't doing anything like routing network traffic/NAT, it's pure > >> > IPv4 (IPv6 disabled in world and kernel, and my home network does > >> > basically no IPv6) and sits idle most of the time fetching mail. It > >> > does use ZFS, but not for /, swap, /var, /tmp, or /usr. > >> > > >> > vmstat -i doesn't particularly show anything awful. All the cpuX:timer > >> > entries tend to fluctuate in rate, usually 120-200 or so; I'd expect an > >> > interrupt storm to be showing something in the 1000+ range. > >> > > >> > The only thing I can think of is the fact that the SSD being used has no > >> > 4K quirk entry in the kernel (and its ATA IDENTIFY responds with 512 > >> > logical, 512 physical, even though we know it's 4K). The partitions are > >> > all 1MB-aligned regardless. > >> > > >> > This is all bare-metal, by the way -- no virtualisation involved. > >> > > >> > I do have DTrace enabled/built on this box but I have absolutely no clue > >> > how to go about profiling things. For example maybe output of this sort > >> > would be helpful (but I've no idea how to get it): > >> > > >> > http://lists.freebsd.org/pipermail/freebsd-stable/2014-July/079276.html > >> > > >> > I'm certain I didn't see this behaviour in 9.x so I'd be happy to try > >> > and track it down if I had a little bit of hand-holding. > >> > > >> > I've put all the things I can think of that might be relevant to "system > >> > config/tuning bits" up here: > >> > > >> > http://jdc.koitsu.org/freebsd/releng10_perf_issue/ > >> > > >> > I should note my kernel config is slightly inaccurate (I've removed some > >> > stuff from the file in attempt to rebuild, but building world prior to > >> > kernel failed due to r268896 breaking world, but anyone subscribed here > >> > has already seen the Jenkins job of that ;-) ). > >> > > >> > Thanks. > >> > > >> > -- > >> > | Jeremy Chadwick jdc@koitsu.org | > >> > | UNIX Systems Administrator http://jdc.koitsu.org/ | > >> > | Making life hard for others since 1977. PGP 4BD6C0CB | > >> > > >> > _______________________________________________ > >> > freebsd-stable@freebsd.org mailing list > >> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > >> > > > > > -- > > | Jeremy Chadwick jdc@koitsu.org | > > | UNIX Systems Administrator http://jdc.koitsu.org/ | > > | Making life hard for others since 1977. PGP 4BD6C0CB | > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 22:09:57 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26448C33 for ; Sun, 20 Jul 2014 22:09:57 +0000 (UTC) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DA37E217E for ; Sun, 20 Jul 2014 22:09:56 +0000 (UTC) Received: by mail-qc0-f173.google.com with SMTP id c9so4951317qcz.4 for ; Sun, 20 Jul 2014 15:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=AKrk450a/o3SDC6JVyTLz14QDmxqR3Rtzhk+Iuu9ZP4=; b=g2p/d+mx8yw/+vgnek2mKf3+9MoeSuQ0L92yTC3LGULOyTU4kiBxx8OtSpPgGYMX2d 3EKQ/uNgADRc/EbBSszhh/yPOvwuxrFqiO7vU3BTMK5kFR25W1ESf9dpe+2mtC0eWsmV RilpF5viXQL3FLgtF0D3UaoEbVeSRdmnajICah9jsF3/thEVRFHPqehqGsbqEIsyKxdE G3+01vRoDo5lnlmTX2ygmLn1/qJx3/nwaMRwrUrP99mLuoHS3Wa6MVEW/kjKxBI6T8EL yhCuOZNp/MC/fLkgpRHBOLq3JtOblRmnVrK2ZkCPKWb6ftBv4EfWkV+280k4OLECgNa9 ySgA== MIME-Version: 1.0 X-Received: by 10.224.71.198 with SMTP id i6mr35814332qaj.76.1405894195870; Sun, 20 Jul 2014 15:09:55 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.1.6 with HTTP; Sun, 20 Jul 2014 15:09:55 -0700 (PDT) In-Reply-To: <20140720201655.GA70545@icarus.home.lan> References: <20140720062413.GA56318@icarus.home.lan> <97EA8E571E634DBBAA70F7AA7F0DE97C@multiplay.co.uk> <20140720173524.GA67065@icarus.home.lan> <20140720201655.GA70545@icarus.home.lan> Date: Sun, 20 Jul 2014 15:09:55 -0700 X-Google-Sender-Auth: FnPEna_Kwabv726m3dXZWIffBQ4 Message-ID: Subject: Re: Consistently "high" CPU load on 10.0-STABLE From: Adrian Chadd To: Jeremy Chadwick Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Stable Mailing List , Steven Hartland X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 22:09:57 -0000 hi, it looks like a whole lot of things are waking up at the same time: * dhcpd * em * usb devices So, do you have some shared interrupts going on here? That seems to be what's causing things to all wake up all at once. -a From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 22:58:48 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53DFDA1E for ; Sun, 20 Jul 2014 22:58:48 +0000 (UTC) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by mx1.freebsd.org (Postfix) with ESMTP id 3018F2614 for ; Sun, 20 Jul 2014 22:58:47 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta07.emeryville.ca.mail.comcast.net with comcast id Umw91o0021Y3wxoA7mymdq; Sun, 20 Jul 2014 22:58:46 +0000 Received: from jdc.koitsu.org ([69.181.136.108]) by omta15.emeryville.ca.mail.comcast.net with comcast id Umyl1o00S2LW5AV8bmymts; Sun, 20 Jul 2014 22:58:46 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 96DEF1744B1; Sun, 20 Jul 2014 15:58:45 -0700 (PDT) Date: Sun, 20 Jul 2014 15:58:45 -0700 From: Jeremy Chadwick To: Adrian Chadd Subject: Re: Consistently "high" CPU load on 10.0-STABLE Message-ID: <20140720225845.GA81033@icarus.home.lan> References: <20140720062413.GA56318@icarus.home.lan> <97EA8E571E634DBBAA70F7AA7F0DE97C@multiplay.co.uk> <20140720173524.GA67065@icarus.home.lan> <20140720201655.GA70545@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405897126; bh=6OvcBrZcTuLSSnoXk/Sy2U/0vv/kTmsDG2VLrwkxF0g=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=an+V8eNWyPO6iN7R7cxlsHO50DnP3psw7nDqa46A6PC5Ae9cR6UlBIt4nry4JhnRV KNziyp/sQkgygGdYGTxVMST0aeY6Kzj7AD0coZUVOJ8xb2jg1igEPQFaCAh6uQ8NBw beBr749VIQcN9wJNACErEPA4b2gZ0UaIABp9JcFhEF3d/ozXHyHTmeputTfuQWKzZB UZSKOg4EbUb3JcZImTMZxKZ/i4i8iboCMir47TN0Z+nS9GeRlXdQbDI7gv9PHvipKt Mj8S9ouvKsFOoUgOTklgUcQFjipPHg6LYWVW1HRP0BR9BBq39hmOPPaXB7gIP5kePG cqOVQmRU115ZA== Cc: Steven Hartland , FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 22:58:48 -0000 On Sun, Jul 20, 2014 at 03:09:55PM -0700, Adrian Chadd wrote: > hi, > > it looks like a whole lot of things are waking up at the same time: > > * dhcpd > * em > * usb devices > > So, do you have some shared interrupts going on here? That seems to be > what's causing things to all wake up all at once. I forget how to get an interrupt mapping from the I/O APIC, but dmesg indicates the following. Sorted by IRQ order so that you can tell what's associated with what, and also RELENG_9 vs. RELENG_10 (because I do have an old dmesg.today from this box running RELENG_9). All the IRQs match up: dev RELENG_10 RELENG_9 -------- ------------- ------------- ioapic0 IRQs 0 to 23 IRQs 0 to 23 (same) ioapic1 IRQs 24 to 47 IRQs 24 to 47 (same) attimer0 IRQ 0 IRQ 0 (same) atkbdc0 IRQ 1 IRQ 1 (same) atkbd0 IRQ 1 IRQ 1 (same) uart1 IRQ 3 IRQ 3 (same) uart0 IRQ 4 IRQ 4 (same) atrtc0 IRQ 8 IRQ 8 (same) em0 IRQ 16 IRQ 16 (same) pcib1 IRQ 16 IRQ 16 (same) pcib3 IRQ 16 IRQ 16 (same) pcib4 IRQ 16 IRQ 16 (same) uhci0 IRQ 16 IRQ 16 (same) ahci0 IRQ 17 IRQ 17 (same) em1 IRQ 17 IRQ 17 (same) ichsmb0 IRQ 17 IRQ 17 (same) pcib5 IRQ 17 IRQ 17 (same) uhci1 IRQ 17 IRQ 17 (same) ehci0 IRQ 18 IRQ 18 (same) uhci2 IRQ 18 IRQ 18 (same) uhci5 IRQ 18 IRQ 18 (same) siis0 IRQ 21 IRQ 21 (same) uhci4 IRQ 22 IRQ 22 (same) ehci1 IRQ 23 IRQ 23 (same) uhci3 IRQ 23 IRQ 23 (same) And the higher-numbered IRQs per vmstat -i. I only have this for RELENG_10 however: irq256: em0 1848856 26 irq259: ahci0:ch0 273086 3 irq260: ahci0:ch1 9990 0 irq261: ahci0:ch2 48514 0 irq262: ahci0:ch3 48046 0 irq263: ahci0:ch4 48258 0 irq264: ahci0:ch5 48052 0 vmstat -i for this is kinda painful (discussed this with jhb@ in the past, re: kernel just appending "+" to the string to indicate "many things using this IRQ"). I have absolute no USB devices attached to the system (meaning there are USB controllers and ports, yeah, but nothing attached to any of them). The keyboard is PS/2. All disks are on ahci0 (no disks currently attached to siis0). As for dhcpd: I don't know how that'd be responsible. If I stop the process entirely I still see the problem. I can provide some more ktrdumps, along with turning off as many daemons + cron jobs as I can, if you feel that'd be helpful. Likewise I can provide an ACPI DSDT dump if that would be useful (maybe to someone else). I haven't tried booting the box in single-user and letting it sit there to see if anything shows up there. In the interim I wrote the perl script I mentioned in my mail to Steve. When the load shoots up, there is literally no field in "vmstat -s" that shows a humongous increase (or decrease) consistently. Meaning I'd say 95% of the time when there's a sudden load jump, none of those statistics I can correlate with it. It's a pretty "meh" script, but it does the job of showing deltas between vmstat -s runs and indicating visually when there's a jump in load average (1m avg). It requires a VERY wide terminal (about 301 characters): http://jdc.koitsu.org/freebsd/releng10_perf_issue/load_vmstat.pl Some example output is here (obviously can't see the red+bold highlighting of the line): http://jdc.koitsu.org/freebsd/releng10_perf_issue/example_data.txt Load jumps at the following time indexes: 124.0 (from 0.02 to 0.10, load delta: 0.08) 153.0 (from 0.06 to 0.14, load delta: 0.08, time delta: 29.0 sec) 178.5 (from 0.10 to 0.17, load delta: 0.07, time delta: 25.5 sec) 217.0 (from 0.09 to 0.17, load delta: 0.08, time delta: 38.5 sec) 236.0 (from 0.12 to 0.19, load delta: 0.07, time delta: 19.0 sec) 244.0 (from 0.17 to 0.24, load delta: 0.07, time delta: 8.0 sec) 259.0 (from 0.20 to 0.27, load delta: 0.07, time delta: 15.0 sec) 284.5 (from 0.19 to 0.25, load delta: 0.06, time delta: 25.5 sec) 310.0 (from 0.18 to 0.25, load delta: 0.07, time delta: 25.5 sec) 341.5 (from 0.27 to 0.33, load delta: 0.06, time delta: 31.5 sec) Some of these could be due to cron jobs I run (though they really aren't that intensive on disk, CPU, or memory), but there's a pretty consistent pattern going on there load-wise. The reason noted time deltas was watching for "periodic tasks", e.g. ZFS txg flush. But this seems to have a little bit more variance. It's just that none of the vmstat -s statistics change rapidly alongside the load. But I'm sure there are VM bits that aren't tracked in vmstat. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 23:16:57 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 880CEE3D; Sun, 20 Jul 2014 23:16:57 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 3AB2827B8; Sun, 20 Jul 2014 23:16:56 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 0E8D720E7088C; Sun, 20 Jul 2014 23:16:54 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_DYNAMIC,STOX_REPLY_TYPE autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 0DD2B20E7088A; Sun, 20 Jul 2014 23:16:50 +0000 (UTC) Message-ID: <3E5D732C440140B9AEE204B91E5B120E@multiplay.co.uk> From: "Steven Hartland" To: "Jeremy Chadwick" , "Adrian Chadd" References: <20140720062413.GA56318@icarus.home.lan> <97EA8E571E634DBBAA70F7AA7F0DE97C@multiplay.co.uk> <20140720173524.GA67065@icarus.home.lan> <20140720201655.GA70545@icarus.home.lan> <20140720225845.GA81033@icarus.home.lan> Subject: Re: Consistently "high" CPU load on 10.0-STABLE Date: Mon, 21 Jul 2014 00:16:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 23:16:57 -0000 ----- Original Message ----- From: "Jeremy Chadwick" To: "Adrian Chadd" Cc: "Steven Hartland" ; "FreeBSD Stable Mailing List" Sent: Sunday, July 20, 2014 11:58 PM Subject: Re: Consistently "high" CPU load on 10.0-STABLE > On Sun, Jul 20, 2014 at 03:09:55PM -0700, Adrian Chadd wrote: >> hi, >> >> it looks like a whole lot of things are waking up at the same time: >> >> * dhcpd >> * em >> * usb devices >> >> So, do you have some shared interrupts going on here? That seems to be >> what's causing things to all wake up all at once. > > I forget how to get an interrupt mapping from the I/O APIC, but dmesg > indicates the following. Sorted by IRQ order so that you can tell > what's associated with what, and also RELENG_9 vs. RELENG_10 (because I > do have an old dmesg.today from this box running RELENG_9). All the > IRQs match up: > > dev RELENG_10 RELENG_9 > -------- ------------- ------------- > ioapic0 IRQs 0 to 23 IRQs 0 to 23 (same) > ioapic1 IRQs 24 to 47 IRQs 24 to 47 (same) > attimer0 IRQ 0 IRQ 0 (same) > atkbdc0 IRQ 1 IRQ 1 (same) > atkbd0 IRQ 1 IRQ 1 (same) > uart1 IRQ 3 IRQ 3 (same) > uart0 IRQ 4 IRQ 4 (same) > atrtc0 IRQ 8 IRQ 8 (same) > em0 IRQ 16 IRQ 16 (same) > pcib1 IRQ 16 IRQ 16 (same) > pcib3 IRQ 16 IRQ 16 (same) > pcib4 IRQ 16 IRQ 16 (same) > uhci0 IRQ 16 IRQ 16 (same) > ahci0 IRQ 17 IRQ 17 (same) > em1 IRQ 17 IRQ 17 (same) > ichsmb0 IRQ 17 IRQ 17 (same) > pcib5 IRQ 17 IRQ 17 (same) > uhci1 IRQ 17 IRQ 17 (same) > ehci0 IRQ 18 IRQ 18 (same) > uhci2 IRQ 18 IRQ 18 (same) > uhci5 IRQ 18 IRQ 18 (same) > siis0 IRQ 21 IRQ 21 (same) > uhci4 IRQ 22 IRQ 22 (same) > ehci1 IRQ 23 IRQ 23 (same) > uhci3 IRQ 23 IRQ 23 (same) > > And the higher-numbered IRQs per vmstat -i. I only have this for > RELENG_10 however: > > irq256: em0 1848856 26 > irq259: ahci0:ch0 273086 3 > irq260: ahci0:ch1 9990 0 > irq261: ahci0:ch2 48514 0 > irq262: ahci0:ch3 48046 0 > irq263: ahci0:ch4 48258 0 > irq264: ahci0:ch5 48052 0 > > vmstat -i for this is kinda painful (discussed this with jhb@ in the > past, re: kernel just appending "+" to the string to indicate "many > things using this IRQ"). > > I have absolute no USB devices attached to the system (meaning there are > USB controllers and ports, yeah, but nothing attached to any of them). > The keyboard is PS/2. All disks are on ahci0 (no disks currently > attached to siis0). > > As for dhcpd: I don't know how that'd be responsible. If I stop the > process entirely I still see the problem. > > I can provide some more ktrdumps, along with turning off as many daemons > + cron jobs as I can, if you feel that'd be helpful. > > Likewise I can provide an ACPI DSDT dump if that would be useful (maybe > to someone else). > > I haven't tried booting the box in single-user and letting it sit there > to see if anything shows up there. > > In the interim I wrote the perl script I mentioned in my mail to Steve. > When the load shoots up, there is literally no field in "vmstat -s" > that shows a humongous increase (or decrease) consistently. Meaning > I'd say 95% of the time when there's a sudden load jump, none of those > statistics I can correlate with it. It's a pretty "meh" script, but > it does the job of showing deltas between vmstat -s runs and indicating > visually when there's a jump in load average (1m avg). It requires a > VERY wide terminal (about 301 characters): > > http://jdc.koitsu.org/freebsd/releng10_perf_issue/load_vmstat.pl > > Some example output is here (obviously can't see the red+bold > highlighting of the line): > > http://jdc.koitsu.org/freebsd/releng10_perf_issue/example_data.txt > > Load jumps at the following time indexes: > > 124.0 (from 0.02 to 0.10, load delta: 0.08) > 153.0 (from 0.06 to 0.14, load delta: 0.08, time delta: 29.0 sec) > 178.5 (from 0.10 to 0.17, load delta: 0.07, time delta: 25.5 sec) > 217.0 (from 0.09 to 0.17, load delta: 0.08, time delta: 38.5 sec) > 236.0 (from 0.12 to 0.19, load delta: 0.07, time delta: 19.0 sec) > 244.0 (from 0.17 to 0.24, load delta: 0.07, time delta: 8.0 sec) > 259.0 (from 0.20 to 0.27, load delta: 0.07, time delta: 15.0 sec) > 284.5 (from 0.19 to 0.25, load delta: 0.06, time delta: 25.5 sec) > 310.0 (from 0.18 to 0.25, load delta: 0.07, time delta: 25.5 sec) > 341.5 (from 0.27 to 0.33, load delta: 0.06, time delta: 31.5 sec) > > Some of these could be due to cron jobs I run (though they really aren't > that intensive on disk, CPU, or memory), but there's a pretty consistent > pattern going on there load-wise. The reason noted time deltas was > watching for "periodic tasks", e.g. ZFS txg flush. But this seems to > have a little bit more variance. > > It's just that none of the vmstat -s statistics change rapidly alongside > the load. But I'm sure there are VM bits that aren't tracked in vmstat. Not sure if its in stable/10 but there was some talk about making ZFS use lz4 for some things by default, wonder if that might have something to do with it? Regards Steve From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 23:22:46 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 75D1C23D; Sun, 20 Jul 2014 23:22:46 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 357FE286E; Sun, 20 Jul 2014 23:22:45 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 6047F20E7088D; Sun, 20 Jul 2014 23:22:45 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_DYNAMIC,TO_EQ_FM_DIRECT_MX autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id C2D9920E7088A; Sun, 20 Jul 2014 23:22:40 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Steven Hartland" , "Jeremy Chadwick" , "Adrian Chadd" References: <20140720062413.GA56318@icarus.home.lan> <97EA8E571E634DBBAA70F7AA7F0DE97C@multiplay.co.uk> <20140720173524.GA67065@icarus.home.lan> <20140720201655.GA70545@icarus.home.lan> <20140720225845.GA81033@icarus.home.lan> <3E5D732C440140B9AEE204B91E5B120E@multiplay.co.uk> Subject: Re: Consistently "high" CPU load on 10.0-STABLE Date: Mon, 21 Jul 2014 00:22:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 23:22:46 -0000 ----- Original Message ----- From: "Steven Hartland" > Not sure if its in stable/10 but there was some talk about making > ZFS use lz4 for some things by default, wonder if that might have > something to do with it? Another silly question is do you see the same increase on 10.0-RELEASE? Regards Steve From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 23:35:58 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7CC108DE for ; Sun, 20 Jul 2014 23:35:58 +0000 (UTC) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by mx1.freebsd.org (Postfix) with ESMTP id 569C0296B for ; Sun, 20 Jul 2014 23:35:58 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta07.emeryville.ca.mail.comcast.net with comcast id UnT41o0021u4NiLA7nbyk8; Sun, 20 Jul 2014 23:35:58 +0000 Received: from jdc.koitsu.org ([69.181.136.108]) by omta21.emeryville.ca.mail.comcast.net with comcast id Unbx1o00F2LW5AV8hnbxcP; Sun, 20 Jul 2014 23:35:57 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 3BA6A1744B1; Sun, 20 Jul 2014 16:35:57 -0700 (PDT) Date: Sun, 20 Jul 2014 16:35:57 -0700 From: Jeremy Chadwick To: Steven Hartland Subject: Re: Consistently "high" CPU load on 10.0-STABLE Message-ID: <20140720233557.GA88887@icarus.home.lan> References: <20140720062413.GA56318@icarus.home.lan> <97EA8E571E634DBBAA70F7AA7F0DE97C@multiplay.co.uk> <20140720173524.GA67065@icarus.home.lan> <20140720201655.GA70545@icarus.home.lan> <20140720225845.GA81033@icarus.home.lan> <3E5D732C440140B9AEE204B91E5B120E@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E5D732C440140B9AEE204B91E5B120E@multiplay.co.uk> User-Agent: Mutt/1.5.23 (2014-03-12) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405899358; bh=A/yF3FQNGGCX3YUn6FKG5xDugzYJU2GKCuCWKJSax/I=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=WdJxIka/cYGv8sQampqevWqomxnW8q+L3uDbPraKwTaHUHnfEnU75ehCj1BTe25qc 8rSkgrODi2jlMmE0+Ffb6RDcEL2Sor1Fls+xKE8aw4Sm6mvJHJviGwaM6h0LvWTTr/ 4h+EJ7mxIHTeDEaFAkaK/TC5KLKC5pFAHZs/HcDkSXO1moyGEeD/IqDyuhTx6MKBD2 msfkpZCjmLR5Twks3Qi2Y3OPBbUmmd+o20Sk6qsMq+327Yi4vlQ4qp+y2dZn9mZbb/ asARWA6MkH82JXtbpReIfBnA8bpwXSutRxlXUcWkCNOA1TMtXKdA8Hqaa0q7To+p2a tDwcUqQftOCbA== Cc: Adrian Chadd , FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 23:35:58 -0000 On Mon, Jul 21, 2014 at 12:16:48AM +0100, Steven Hartland wrote: > > ----- Original Message ----- > From: "Jeremy Chadwick" > To: "Adrian Chadd" > Cc: "Steven Hartland" ; "FreeBSD Stable Mailing List" > Sent: Sunday, July 20, 2014 11:58 PM > Subject: Re: Consistently "high" CPU load on 10.0-STABLE > > > > On Sun, Jul 20, 2014 at 03:09:55PM -0700, Adrian Chadd wrote: > >> hi, > >> > >> it looks like a whole lot of things are waking up at the same time: > >> > >> * dhcpd > >> * em > >> * usb devices > >> > >> So, do you have some shared interrupts going on here? That seems to be > >> what's causing things to all wake up all at once. > > > > I forget how to get an interrupt mapping from the I/O APIC, but dmesg > > indicates the following. Sorted by IRQ order so that you can tell > > what's associated with what, and also RELENG_9 vs. RELENG_10 (because I > > do have an old dmesg.today from this box running RELENG_9). All the > > IRQs match up: > > > > dev RELENG_10 RELENG_9 > > -------- ------------- ------------- > > ioapic0 IRQs 0 to 23 IRQs 0 to 23 (same) > > ioapic1 IRQs 24 to 47 IRQs 24 to 47 (same) > > attimer0 IRQ 0 IRQ 0 (same) > > atkbdc0 IRQ 1 IRQ 1 (same) > > atkbd0 IRQ 1 IRQ 1 (same) > > uart1 IRQ 3 IRQ 3 (same) > > uart0 IRQ 4 IRQ 4 (same) > > atrtc0 IRQ 8 IRQ 8 (same) > > em0 IRQ 16 IRQ 16 (same) > > pcib1 IRQ 16 IRQ 16 (same) > > pcib3 IRQ 16 IRQ 16 (same) > > pcib4 IRQ 16 IRQ 16 (same) > > uhci0 IRQ 16 IRQ 16 (same) > > ahci0 IRQ 17 IRQ 17 (same) > > em1 IRQ 17 IRQ 17 (same) > > ichsmb0 IRQ 17 IRQ 17 (same) > > pcib5 IRQ 17 IRQ 17 (same) > > uhci1 IRQ 17 IRQ 17 (same) > > ehci0 IRQ 18 IRQ 18 (same) > > uhci2 IRQ 18 IRQ 18 (same) > > uhci5 IRQ 18 IRQ 18 (same) > > siis0 IRQ 21 IRQ 21 (same) > > uhci4 IRQ 22 IRQ 22 (same) > > ehci1 IRQ 23 IRQ 23 (same) > > uhci3 IRQ 23 IRQ 23 (same) > > > > And the higher-numbered IRQs per vmstat -i. I only have this for > > RELENG_10 however: > > > > irq256: em0 1848856 26 > > irq259: ahci0:ch0 273086 3 > > irq260: ahci0:ch1 9990 0 > > irq261: ahci0:ch2 48514 0 > > irq262: ahci0:ch3 48046 0 > > irq263: ahci0:ch4 48258 0 > > irq264: ahci0:ch5 48052 0 > > > > vmstat -i for this is kinda painful (discussed this with jhb@ in the > > past, re: kernel just appending "+" to the string to indicate "many > > things using this IRQ"). > > > > I have absolute no USB devices attached to the system (meaning there are > > USB controllers and ports, yeah, but nothing attached to any of them). > > The keyboard is PS/2. All disks are on ahci0 (no disks currently > > attached to siis0). > > > > As for dhcpd: I don't know how that'd be responsible. If I stop the > > process entirely I still see the problem. > > > > I can provide some more ktrdumps, along with turning off as many daemons > > + cron jobs as I can, if you feel that'd be helpful. > > > > Likewise I can provide an ACPI DSDT dump if that would be useful (maybe > > to someone else). > > > > I haven't tried booting the box in single-user and letting it sit there > > to see if anything shows up there. > > > > In the interim I wrote the perl script I mentioned in my mail to Steve. > > When the load shoots up, there is literally no field in "vmstat -s" > > that shows a humongous increase (or decrease) consistently. Meaning > > I'd say 95% of the time when there's a sudden load jump, none of those > > statistics I can correlate with it. It's a pretty "meh" script, but > > it does the job of showing deltas between vmstat -s runs and indicating > > visually when there's a jump in load average (1m avg). It requires a > > VERY wide terminal (about 301 characters): > > > > http://jdc.koitsu.org/freebsd/releng10_perf_issue/load_vmstat.pl > > > > Some example output is here (obviously can't see the red+bold > > highlighting of the line): > > > > http://jdc.koitsu.org/freebsd/releng10_perf_issue/example_data.txt > > > > Load jumps at the following time indexes: > > > > 124.0 (from 0.02 to 0.10, load delta: 0.08) > > 153.0 (from 0.06 to 0.14, load delta: 0.08, time delta: 29.0 sec) > > 178.5 (from 0.10 to 0.17, load delta: 0.07, time delta: 25.5 sec) > > 217.0 (from 0.09 to 0.17, load delta: 0.08, time delta: 38.5 sec) > > 236.0 (from 0.12 to 0.19, load delta: 0.07, time delta: 19.0 sec) > > 244.0 (from 0.17 to 0.24, load delta: 0.07, time delta: 8.0 sec) > > 259.0 (from 0.20 to 0.27, load delta: 0.07, time delta: 15.0 sec) > > 284.5 (from 0.19 to 0.25, load delta: 0.06, time delta: 25.5 sec) > > 310.0 (from 0.18 to 0.25, load delta: 0.07, time delta: 25.5 sec) > > 341.5 (from 0.27 to 0.33, load delta: 0.06, time delta: 31.5 sec) > > > > Some of these could be due to cron jobs I run (though they really aren't > > that intensive on disk, CPU, or memory), but there's a pretty consistent > > pattern going on there load-wise. The reason noted time deltas was > > watching for "periodic tasks", e.g. ZFS txg flush. But this seems to > > have a little bit more variance. > > > > It's just that none of the vmstat -s statistics change rapidly alongside > > the load. But I'm sure there are VM bits that aren't tracked in vmstat. > > Not sure if its in stable/10 but there was some talk about making > ZFS use lz4 for some things by default, wonder if that might have > something to do with it? I hope not -- the ZFS pools and filesystems both were created on RELENG_9 circa January 2014 (according to "zpool history"). Well, actually, the backups pool was created a few days ago (on RELENG_9) due to a disk failure. ZFS details: http://jdc.koitsu.org/freebsd/releng10_perf_issue/zfs_get_all.txt http://jdc.koitsu.org/freebsd/releng10_perf_issue/zpool_status.txt http://jdc.koitsu.org/freebsd/releng10_perf_issue/zdb_ashift.txt I do use lz4 compression on two specific filesystems (data/www and data/cvs); content on data/www is only fed by Apache, and data/cvs isn't used by anything unless I'm using "cvs" (I do run cvspserver). I don't use dedup or snapshots. The backing disks are 4K-sector (they lack 4K kernel quirks in FreeBSD) but ashift is 12 on all of them. If we think it's related to lz4, I can absolutely recreate those filesystems sans compression with little effort -- they're very small and contain very little data: $ zfs list data/www data/cvs NAME USED AVAIL REFER MOUNTPOINT data/cvs 520K 1.27T 520K /cvs data/www 25.9M 1.27T 25.9M /www I don't dare run "zpool upgrade" until this can be figured out or at least determined for sure to be "specific to my environment" (I'll just go back to RELENG_9 in that case, no worries). -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 23:36:11 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 396F89C7 for ; Sun, 20 Jul 2014 23:36:11 +0000 (UTC) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F172C2970 for ; Sun, 20 Jul 2014 23:36:10 +0000 (UTC) Received: by mail-qc0-f173.google.com with SMTP id c9so4984841qcz.4 for ; Sun, 20 Jul 2014 16:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m1qFLwEiX6i9h0Y9DIbA+XGZQ3jT3FN8iw6dqYQhp0U=; b=y7dXaBU7UTkalArqJnA0oM9oSjlc+CCsJPuhjvyM3cE2UhSiliM0XKlavZ4oZElzph X5U1VduKkGWAv24vh/9SFjUGXPIXoShlLlU0k1brKWkNyYe4HnckruDGqcz+f2OXLoll WeTsaNXtqKxHSoOXicYKe9RXbOULHlMG2f7NcNzRSuah4bDNwtNaQuPY3rOz0RGCYtt+ +9gxiPSAMaLCJzDV3E5pnJm+zPTgBU5BuSVnvwr9A0S3c6/dmiocnedqRmnCh/QK8ZlY ygBn1+BTPxcelFoZ+cNf9gBcZW7vAVgAWGu00DfNbQ3xXCFhSbBLVi4/KtsAh7/rmZeT cHzg== MIME-Version: 1.0 X-Received: by 10.224.36.130 with SMTP id t2mr4167839qad.45.1405899370126; Sun, 20 Jul 2014 16:36:10 -0700 (PDT) Received: by 10.96.73.39 with HTTP; Sun, 20 Jul 2014 16:36:10 -0700 (PDT) In-Reply-To: <20140720062413.GA56318@icarus.home.lan> References: <20140720062413.GA56318@icarus.home.lan> Date: Sun, 20 Jul 2014 16:36:10 -0700 Message-ID: Subject: Re: Consistently "high" CPU load on 10.0-STABLE From: hiren panchasara To: Jeremy Chadwick Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 23:36:11 -0000 On Sat, Jul 19, 2014 at 11:24 PM, Jeremy Chadwick wrote: > (Please keep me CC'd as I'm not subscribed to freebsd-stable@) [skip] > > I do have DTrace enabled/built on this box but I have absolutely no clue > how to go about profiling things. For example maybe output of this sort > would be helpful (but I've no idea how to get it): > > http://lists.freebsd.org/pipermail/freebsd-stable/2014-July/079276.html You can probably use hotkernel or something similar? http://www.freebsd.org/doc/handbook/dtrace-using.html cheers, Hiren [skip] From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 23:41:39 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50ED3B3B for ; Sun, 20 Jul 2014 23:41:39 +0000 (UTC) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:40]) by mx1.freebsd.org (Postfix) with ESMTP id 2BD162A19 for ; Sun, 20 Jul 2014 23:41:39 +0000 (UTC) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta04.emeryville.ca.mail.comcast.net with comcast id Unew1o0020x6nqcA4nhepR; Sun, 20 Jul 2014 23:41:38 +0000 Received: from jdc.koitsu.org ([69.181.136.108]) by omta12.emeryville.ca.mail.comcast.net with comcast id Unhd1o00P2LW5AV8YnheKL; Sun, 20 Jul 2014 23:41:38 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id DAC651744B1; Sun, 20 Jul 2014 16:41:37 -0700 (PDT) Date: Sun, 20 Jul 2014 16:41:37 -0700 From: Jeremy Chadwick To: Steven Hartland Subject: Re: Consistently "high" CPU load on 10.0-STABLE Message-ID: <20140720234137.GA89084@icarus.home.lan> References: <20140720062413.GA56318@icarus.home.lan> <97EA8E571E634DBBAA70F7AA7F0DE97C@multiplay.co.uk> <20140720173524.GA67065@icarus.home.lan> <20140720201655.GA70545@icarus.home.lan> <20140720225845.GA81033@icarus.home.lan> <3E5D732C440140B9AEE204B91E5B120E@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405899698; bh=u6PJnm3/Xn+7yTNZHm4uMjkLPLt6D7IHhRRDKcZhAEQ=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=ul/NZVtvHwaz6cxSt0qV8v8EdZ0R6WtRsCiIb+f25ZJgTgDP3d8qN2lFLzk4uNtsQ WZVWnS8v9uwIoyyipWs4dvt3+6TGrwtIKKueheO3OBrl2Lg30xPFHZKR2eyEtWLw0k lu8256UpildlB7h23gC6o7h5IAMzojrx9UaL1g52TYo9vh5wibdnGvbefgDUGkLCnn N5thUKarnVMRlExYCvGAfU5wXz1jWQ/IoAQOY4hcHgDNYu29MefZAEX8W1N76AfG50 lMbDy4qOisaNji8vvWttPG+FpZN76vtxDFepxVBLTof54phuRuTRLp0eOJHEvgTWR1 BfTcJIN2Q/8Ag== Cc: Adrian Chadd , FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 23:41:39 -0000 On Mon, Jul 21, 2014 at 12:22:38AM +0100, Steven Hartland wrote: > ----- Original Message ----- > From: "Steven Hartland" > > > Not sure if its in stable/10 but there was some talk about making > > ZFS use lz4 for some things by default, wonder if that might have > > something to do with it? > > Another silly question is do you see the same increase on 10.0-RELEASE? Good question, not silly. The answer is I don't know -- when I moved from RELENG_9 to RELENG_10, I reinstalled straight from memstick here: ftp://ftp4.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/10.0/ I always install -STABLE and not -RELEASE because for nearly 15 years I've found too many broken things in -RELEASE that don't get fixed soon enough for me. I can try "rolling back" in SVN to r256281 and try that (I'm afraid to find out what buildkernel/buildworld will break on though, heh). I think that's the rev as close to 10.0-RELEASE as possible? http://svnweb.freebsd.org/base?view=revision&revision=256281 -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Jul 20 23:59:47 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E17C260 for ; Sun, 20 Jul 2014 23:59:47 +0000 (UTC) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by mx1.freebsd.org (Postfix) with ESMTP id 1D9DC2B3A for ; Sun, 20 Jul 2014 23:59:47 +0000 (UTC) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta02.emeryville.ca.mail.comcast.net with comcast id UnQ81o0080FhH24A2nzm1u; Sun, 20 Jul 2014 23:59:46 +0000 Received: from jdc.koitsu.org ([69.181.136.108]) by omta08.emeryville.ca.mail.comcast.net with comcast id Unzl1o00b2LW5AV8Unzmew; Sun, 20 Jul 2014 23:59:46 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id B9A621744B1; Sun, 20 Jul 2014 16:59:45 -0700 (PDT) Date: Sun, 20 Jul 2014 16:59:45 -0700 From: Jeremy Chadwick To: hiren panchasara Subject: Re: Consistently "high" CPU load on 10.0-STABLE Message-ID: <20140720235945.GA90603@icarus.home.lan> References: <20140720062413.GA56318@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405900786; bh=cGMuYzoZadN3GhiH0zUPK1pSMkVC47w9B2PpvD/8ZVM=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=nahkbyJtVToJZJ/qoixJi+ZeXKeXwi5h4CiODzlvEBkVO4MqfJJ9YLMNxr2pWYIJo bqs91bP77C2DF5CuzAx7PbA8ezgZ3x1MBO8Mb1m/dberxuawyyAi1dUlpKAsfVLtKf CqcuoABElahcBm5NkV50DEuaX83DWD27H7laYzgUSkYQShftgQ7eWOsXqoiX5yhWuR 6Cqczz2W4lYfapkMOi4sFSBcSnJiKVgEiWyWrgWGLjiXDxR3/zIz6K3AAmffHcnrms kGZR7y4OPUWwS71eCJw4eyY1HUzAIFoLWbC+U8D9HLAHCvk+j+tZ6lx7NeyRRNbRT8 wd5YKO1DvKrcQ== Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 23:59:47 -0000 On Sun, Jul 20, 2014 at 04:36:10PM -0700, hiren panchasara wrote: > On Sat, Jul 19, 2014 at 11:24 PM, Jeremy Chadwick wrote: > > (Please keep me CC'd as I'm not subscribed to freebsd-stable@) > [skip] > > > > I do have DTrace enabled/built on this box but I have absolutely no clue > > how to go about profiling things. For example maybe output of this sort > > would be helpful (but I've no idea how to get it): > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2014-July/079276.html > > You can probably use hotkernel or something similar? > http://www.freebsd.org/doc/handbook/dtrace-using.html Yeah, I've given that a try. I think all that script does, in layman's terms, is count the number of occurrences of a kernel function/symbol being called. If there was a single kernel function being called repeatedly in excess then it would show up there, but if it's more like a mutex being held for a long time I don't think hotkernel would show this. Meaning: it doesn't actually indicate "how much" time something took, just the number of times something was run. I think this was why Adrian was advocating KTR. procsystime might be more useful if I had reason to think it was a userland process, but the jury's still out on that one (I haven't seen anything userland show up in top that would indicate CPU usage, which is why I'm more suspicious of the kernel). -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 03:48:20 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 73957215 for ; Mon, 21 Jul 2014 03:48:20 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2F33B2E28 for ; Mon, 21 Jul 2014 03:48:19 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s6L3mHeZ020807; Sun, 20 Jul 2014 23:48:17 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id s6L3mHnF020806; Sun, 20 Jul 2014 23:48:17 -0400 (EDT) (envelope-from wollman) Date: Sun, 20 Jul 2014 23:48:17 -0400 (EDT) From: Garrett Wollman Message-Id: <201407210348.s6L3mHnF020806@hergotha.csail.mit.edu> To: jdc@koitsu.org Subject: Re: Consistently "high" CPU load on 10.0-STABLE X-Newsgroups: mit.lcs.mail.freebsd-stable In-Reply-To: <20140720235945.GA90603@icarus.home.lan> References: <20140720062413.GA56318@icarus.home.lan> Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Sun, 20 Jul 2014 23:48:17 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on hergotha.csail.mit.edu Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 03:48:20 -0000 In article <20140720235945.GA90603@icarus.home.lan> you write: >Yeah, I've given that a try. I think all that script does, in layman's >terms, is count the number of occurrences of a kernel function/symbol >being called. I've had good results in the past using pmcstat(8) in "top" mode. Of course you'll need a kernel with the PMC support compiled in to use that, and a CPU where hwpmc(4) supports a useful counter -- I'd start with something that counts unhalted cycles or retired instructions. -GAWollman From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 10:03:37 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EBBC0FB3 for ; Mon, 21 Jul 2014 10:03:37 +0000 (UTC) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B48FB2021 for ; Mon, 21 Jul 2014 10:03:37 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1X9ARR-000Jmq-Ur; Mon, 21 Jul 2014 10:03:34 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1X9ARR-00084i-SZ; Mon, 21 Jul 2014 11:03:33 +0100 To: freebsd-stable@freebsd.org, jean-sebastien.pedron@dumbbell.fr Subject: Re: Problems loading RV620 firmware In-Reply-To: <53C93633.5030707@dumbbell.fr> Message-Id: From: Pete French Date: Mon, 21 Jul 2014 11:03:33 +0100 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 10:03:38 -0000 Sorry for long delay - got a sick kid and had to leave early on Friday. > Great, thank you for the test! > > One last question: was it with syscons or vt(4)? vt(4) - with those ati drivers in it works as expected - just start X and it loads the drivers up, and will return to the console properly when X finished - albeit with a mught higher resolution thankj when I started - teeny tiny shell prompt ;) cheers, -pete. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 14:28:22 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD2FA786 for ; Mon, 21 Jul 2014 14:28:22 +0000 (UTC) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 91E452C04 for ; Mon, 21 Jul 2014 14:28:22 +0000 (UTC) Received: by mail-pd0-f171.google.com with SMTP id z10so9255603pdj.16 for ; Mon, 21 Jul 2014 07:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=AFPjvNv2eQzdxUMXlFyyAGjL34peEPFhzFDzPCW4V5Y=; b=ZZ8eQz9CRwjXkyWkQcqhrD2kcU5QuWDhz/5fSux0JmrGwXTHcyukm7lXu1IJTnzoW5 jMwhqyLiU6r0HLjj3pxduUsipZgnmFuTwiZ5VtaiJWONPEMPF6+RbBrQfsFRDdpD2Er3 FWIow7vLr68UVeyAd4pTJZNG5t9YO5yxdak4o27loYV2lxMyxwsDm+mvEkCi541C2Ose 7SaEY1W2d8IpDGkkkYdrax3Ol5Wtt5laPJxgqLPB2eeYkfwkPSb3tkaHM2JkaByxd7dr hvcraZt0NH49/Cr2Nw3TRU7s6mV9hMXV2DU2w/dyYhJf5nWcOUooIOk9q0AUD0EBNMb5 50xA== X-Received: by 10.66.227.73 with SMTP id ry9mr26001277pac.18.1405952901892; Mon, 21 Jul 2014 07:28:21 -0700 (PDT) Received: from robert-notebook ([144.24.19.5]) by mx.google.com with ESMTPSA id xk3sm14376519pbb.65.2014.07.21.07.28.19 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 21 Jul 2014 07:28:21 -0700 (PDT) Date: Mon, 21 Jul 2014 16:28:13 +0200 From: Robert David To: freebsd-stable@freebsd.org Subject: Re: Any chance for ThinkPad T440? Message-ID: <20140721162813.296c331d@robert-notebook> In-Reply-To: References: <20140709151936.ff5b09a906f576a63b532bbe@mimar.rs> <53BD5516.30101@gmail.com> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:28:22 -0000 This sounds interesting. On X240 the vesa performance seems to be ok in MATE desktop. But problem is the lack of display configuration (eg: not any external monitor). Linux acpi driver also handles some extra keys that FreeBSD does not, for example brightness. This seems to be portable. The last think is the wifi card intel 7260, but iwl driver development branch seems to handle this as well (did not test). So I think it will be possible to use these notebooks maybe even in 10.1 release (I hope). Robert. On Fri, 18 Jul 2014 13:15:36 -0400 Ed Maste wrote: > On 9 July 2014 10:43, Jan Kokem=C3=BCller > wrote: > > > > Currently a newer Intel driver is being ported > > (https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%20= Linux%203.8) > > that will support the Haswell chips. >=20 > Another option which should be available soon will be to use > xf86-video-scfb on top of vt_efifb, after UEFI booting. It won't have > acceleration but should be acceptable for basic use. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 14:29:04 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B50E8AF for ; Mon, 21 Jul 2014 14:29:04 +0000 (UTC) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 451F82C1B for ; Mon, 21 Jul 2014 14:29:04 +0000 (UTC) Received: by mail-qc0-f171.google.com with SMTP id i17so5554156qcy.2 for ; Mon, 21 Jul 2014 07:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:subject:date:to; bh=Yq7TtFT5hJgjKtLOSNUTAWqRWKJLhZ2SqVaJh/0Ej6c=; b=iNdJ/+kJkqJvWlsKqx5GeV6ipD6KIkcVL9qBWQGBZnNyq6JKj6hQAcoeBCn/Z/1A/2 qMKtqmpBHj1oICJTOF/PCs3LE0nCmzmh8laWFmRWpZFTHIZK9Zr4FLYbkr9bhWt31MI+ vQowz/XsKfXmRPmqjnwwaEZC/FB5WQW6hXENuCgUpOqK28w0k8LyNbqiP5GEG1EXLBzO EBhUBtAI4NOdifPqTnm5OJ8FqDwyQ0kYiIpSRktbDsGjRhCDgYvI7iMyYFKl5XoRUUfN 0OA3WOiR+GdQiOlbI6dVgnzPo/dUfHeaJjicjobcWSkmvJgFas84ult0lsZ/M8TmUk+6 aSMw== X-Received: by 10.229.212.68 with SMTP id gr4mr41848641qcb.25.1405952940954; Mon, 21 Jul 2014 07:29:00 -0700 (PDT) Received: from [192.168.1.2] (pool-173-48-147-104.bstnma.fios.verizon.net. [173.48.147.104]) by mx.google.com with ESMTPSA id l76sm16287971qga.8.2014.07.21.07.28.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 07:28:59 -0700 (PDT) From: Edwin Brown X-Google-Original-From: Edwin Brown References: <20140720062413.GA56318@icarus.home.lan> <201407210348.s6L3mHnF020806@hergotha.csail.mit.edu> Mime-Version: 1.0 (1.0) In-Reply-To: <201407210348.s6L3mHnF020806@hergotha.csail.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <72ABE5EB-9F5C-45E6-9FD2-8C3113398528@gmail.com> X-Mailer: iPhone Mail (11D257) Subject: Re: Consistently "high" CPU load on 10.0-STABLE Date: Mon, 21 Jul 2014 10:28:56 -0400 To: Garrett Wollman Cc: "jdc@koitsu.org" , "stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:29:04 -0000 I've also seen this behavior in 10.0 stable. Currently running r268853.=20 I've had the same behavior since 10.0 release and never thought much about i= t other than the fact that it didn't seem "normal".=20 This machine is a test machine and I'd be happy to run some tests for people= if that might help. My kernel debugging skills are limited. But I have som= e spare time and a computer I can destroy if need be=20 Thanks=20 Ed=20 > On Jul 20, 2014, at 11:48 PM, Garrett Wollman wrote: >=20 > In article <20140720235945.GA90603@icarus.home.lan> you write: >=20 >> Yeah, I've given that a try. I think all that script does, in layman's >> terms, is count the number of occurrences of a kernel function/symbol >> being called. >=20 > I've had good results in the past using pmcstat(8) in "top" mode. Of > course you'll need a kernel with the PMC support compiled in to use > that, and a CPU where hwpmc(4) supports a useful counter -- I'd start > with something that counts unhalted cycles or retired instructions. >=20 > -GAWollman >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 15:54:26 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9E31DCE0 for ; Mon, 21 Jul 2014 15:54:26 +0000 (UTC) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5DEC824C1 for ; Mon, 21 Jul 2014 15:54:26 +0000 (UTC) Received: by mail-qg0-f54.google.com with SMTP id z60so5559519qgd.27 for ; Mon, 21 Jul 2014 08:54:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=XQ7jx6AHPkQdaiZEqyha7H7iPXEG6yYejwQ5nVpDRKc=; b=0he70Jn1PcJ0q4zdjJQRUJQLY9Y+y6jnx/+nP1PIopagR/7iGLcvlYw4yGEdLCNrjz s5JORrbupgR9D8VuIVRetyjf/4ALpdxkd0wkBbi8gqB6dwnod4FTAMXryfPZ5dL3p3ut V4KNWGSADh123wloITJd0gjV+UFylvC4NJe0npDtby010gmNvFacJvEardkaETOEtT8m 4anMv7QG6nFKYWqEickHyT4FVw9ox8yzKYsOa2IeGTgDYgZtis/ddTxMg0nCmznDn6Hq fQqFhYMPiFejz6sSb1uxh2ZUA9Dw9JvlUi/ho9YaPb7PQkLd7efDmPzwwm396soNsdbo yWFw== MIME-Version: 1.0 X-Received: by 10.140.102.142 with SMTP id w14mr39526818qge.101.1405958065369; Mon, 21 Jul 2014 08:54:25 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.1.6 with HTTP; Mon, 21 Jul 2014 08:54:25 -0700 (PDT) In-Reply-To: <20140721162813.296c331d@robert-notebook> References: <20140709151936.ff5b09a906f576a63b532bbe@mimar.rs> <53BD5516.30101@gmail.com> <20140721162813.296c331d@robert-notebook> Date: Mon, 21 Jul 2014 08:54:25 -0700 X-Google-Sender-Auth: avQ71mjZi37zBmxvof_2Ob6qtx4 Message-ID: Subject: Re: Any chance for ThinkPad T440? From: Adrian Chadd To: Robert David Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 15:54:26 -0000 No, it's a totally different thing. They included the IDs for the devices but none of the code. So it's not going to have wifi by 10.1. Sorry. Noone has stepped up with a driver. -a On 21 July 2014 07:28, Robert David wrote: > This sounds interesting. On X240 the vesa performance seems to be ok in > MATE desktop. But problem is the lack of display configuration (eg: not > any external monitor). > > Linux acpi driver also handles some extra keys that FreeBSD does not, > for example brightness. This seems to be portable. > > The last think is the wifi card intel 7260, but iwl driver development > branch seems to handle this as well (did not test). So I think it will > be possible to use these notebooks maybe even in 10.1 release (I hope). > > Robert. > > On Fri, 18 Jul 2014 13:15:36 -0400 > Ed Maste wrote: > >> On 9 July 2014 10:43, Jan Kokem=C3=BCller >> wrote: >> > >> > Currently a newer Intel driver is being ported >> > (https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%2= 0Linux%203.8) >> > that will support the Haswell chips. >> >> Another option which should be available soon will be to use >> xf86-video-scfb on top of vt_efifb, after UEFI booting. It won't have >> acceleration but should be acceptable for basic use. >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to >> "freebsd-stable-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Mon Jul 21 20:52:48 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34B5FA6D for ; Mon, 21 Jul 2014 20:52:48 +0000 (UTC) Received: from mainframe.dafcorp.net (dafnet-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:dc3::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D94C722F4 for ; Mon, 21 Jul 2014 20:52:46 +0000 (UTC) Received: from [IPv6:2001:470:28:dc3:f66d:4ff:fecd:f230] (unknown [IPv6:2001:470:28:dc3:f66d:4ff:fecd:f230]) by mainframe.dafcorp.net (Postfix) with ESMTPSA id 24343B9 for ; Fri, 18 Jul 2014 01:06:56 +0200 (CEST) Message-ID: <53C8570E.6010309@dafnet.se> Date: Fri, 18 Jul 2014 01:06:54 +0200 From: David User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: stable/10 with WITHOUT_OPENSSL not compiling Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090301060301000400010503" X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 20:52:48 -0000 This is a cryptographically signed message in MIME format. --------------ms090301060301000400010503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Trying to compile stable/10 WITHOUT_OPENSSL I get multiple issues. Path: . Working Copy Root Path: /usr/src URL:https://svn0.eu.freebsd.org/base/stable/10=20 Relative URL: ^/stable/10 Repository Root:https://svn0.eu.freebsd.org/base=20 Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 268740 Node Kind: directory Schedule: normal Last Changed Author: hselasky Last Changed Rev: 268738 Last Changed Date: 2014-07-16 08:22:35 +0200 (Wed, 16 Jul 2014) openssl/ssl.h missing in multiple places in libldns In file included from /usr/src/lib/libldns/../../contrib/ldns/zone.c:11: In file included from=20 /usr/src/lib/libldns/../../contrib/ldns/ldns/ldns.h:98: /usr/src/lib/libldns/../../contrib/ldns/ldns/dane.h:30:10: fatal error:=20 'openssl/ssl.h' file not found so I add WITHOUT_LDNS /usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c:37= 0:1:=20 error: conflicting types for 'snmp_passwd_to_keys' snmp_passwd_to_keys(struct snmp_user *user, char *passwd __unused) ^ /usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.h:273:16: = note: previous declaration is here enum snmp_code snmp_passwd_to_keys(struct snmp_user *, char *); ^ /usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmpcrypto.c:38= 2:1:=20 error: conflicting types for 'snmp_get_local_keys' snmp_get_local_keys(struct snmp_user *user, uint8_t *eid __unused, ^ /usr/src/lib/libbsnmp/libbsnmp/../../../contrib/bsnmp/lib/snmp.h:274:16: = note: previous declaration is here enum snmp_code snmp_get_local_keys(struct snmp_user *, uint8_t *, uint32_= t); ^ 2 errors generated. *** [snmpcrypto.So] Error code 1 so I add WITHOUT_BSNMP --- all_subdir_libfetch --- --- common.So --- cc -fpic -DPIC -O2 -pipe -I. -DINET6 -DFTP_COMBINE_CWDS=20 -std=3Diso9899:1999 -Qunused-arguments -fstack-protector -Wsystem-header= s=20 -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter=20 -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type=20 -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter=20 -Wcast-align -Wchar-subscripts -Winline -Wnested-externs=20 -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations = -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int=20 -Wno-unused-const-variable -c /usr/src/lib/libfetch/common.c -o common.So= /usr/src/lib/libfetch/common.c:808:43: error: unused parameter 'URL'=20 [-Werror,-Wunused-parameter] fetch_ssl(conn_t *conn, const struct url *URL, int verbose) ^ 1 error generated. *** [common.So] Error code 1 make[5]: stopped in /usr/src/lib/libfetch This I don't know how to solve. LDNS should be able to compile without=20 openssl with reduced functionality. --------------ms090301060301000400010503 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMVzCC BhswggUDoAMCAQICAwkV1zANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTE0MDIyNDA5MzYxN1oXDTE1MDIyNTIxMDAxMFowOjEYMBYGA1UE AwwPZGF2aWRAZGFmbmV0LnNlMR4wHAYJKoZIhvcNAQkBFg9kYXZpZEBkYWZuZXQuc2UwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDt/5L1JETp/ssLexUqlkXabpD50j7rqs9v ZDcPzuCUR1io5OtMlUeoMCPQ8Qjd/bQ1l70uaGyVbjGaKyN2WeCBksGXXd3Zr9Sh88AjWcta PXbY6sFNCBp68hEOhNe/Za3L82xHtk/7imJx/U/2FMHb/Ob8ZBQshT+mMMKQfnrnYi01LQDQ 4r+1I69WjIeVf8t/whbsGn8ifiwS2xqKRjdOH+BiJZqSsvIiJK6iQ0qUT7JRZ7a9XAnogmfy fSvtwMcFnvgzGPuJNFI4Axm+8icpn5U6sXaJyWV2wClMntc6dZtwvYJmFJwxvZ9P1ENgzAgX kwizTG7W75ivCKXTHqhPAgMBAAGjggLVMIIC0TAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFH1HCk2lrVN9kpgEMDUm 0TZ87LIAMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMBoGA1UdEQQTMBGBD2Rh dmlkQGRhZm5ldC5zZTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4G CCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEF BQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhp cyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5j ZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSBy ZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3Js LnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUF BzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xp ZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZI hvcNAQELBQADggEBAKqU8ZYYALM19OuvF7Wz4rJD+uuoV98puEYUkUxjZ0GlSO37eU9nbYHV xq25vuoP75wAIIZKYFpidLXauXhhxz4b4+snX3MMjtOb9YzGFUofzNEq6E+g5P7kXYHZQSy1 tg7HuEVhA+lGI3CoIwL6HFKD0FI8XdXWZ6fdmsDz0vGWtBMcu1oXPfWUZA7Mn1MlhRyTuihh WfQYyMrIIf3mESy9iCuWTHGs9HYKGHBc/BpF1sejMc71j7+Xh6ZAvvkVngBsJk6F/mwE0HJy Ste6d44VY2P5IVn6cfFRWhRGu8GIiiIesIcIouwpnT+UzxF1x2viBtLg/2Uizix9ImOXRpcw ggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0w NzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEppC4T q5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9b+0U jM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54qzHDY eqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX9U8E g5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/4ebf eZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8EBTAD AQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHwYD VR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsGAQUF BzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29t L3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJo dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAK gwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnF sukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUT yMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8C nykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rz kc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7x PbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAo nrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076khXO 7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8J7GC UBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRXun0N beY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJ TDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2Vy dGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IElu dGVybWVkaWF0ZSBDbGllbnQgQ0ECAwkV1zAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA3MTcyMzA2NTRaMCMGCSqGSIb3DQEJ BDEWBBQpLvPrgDNp4nBGiwvQKy+hK9Ad+zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQB KjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCRXXMIGnBgsqhkiG9w0BCRACCzGBl6CB lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMJFdcwDQYJKoZIhvcNAQEB BQAEggEAOnSPbgOFcNLoAVZ5s0izH2qK5bsxXIKwJmzgCkv/G519gnoQO0VYFwjTwi23dojQ cMCk1joGN0rSUOlxP4u7vRHHkfTuZGOpg/4sNdSidoN0oMTR3vkuq6HukG1P9wuG1rHzOd3h zoNQPFaHnTvHL737MmQYq+xihsfSD4VsURdN/41DYBErnPGB9Lb3o9hg2bSMNhB2BTjGl81A GqBnm8IAA62X6lL66jlgnzXAJ5QMpnOob4T9ZI/UZ0wnkl96GcbmbFE6HNn20gs2Gah7zEoZ gQTfJdD2l3m59mjs7UdH3ArZiv0us1utrrxKgYBgmJA0pbqE1FkF11AKNOKe0wAAAAAAAA== --------------ms090301060301000400010503-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 14:33:58 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9410649F for ; Tue, 22 Jul 2014 14:33:58 +0000 (UTC) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4E5DE2C8B for ; Tue, 22 Jul 2014 14:33:58 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1X9b8c-0002HM-Pu for freebsd-stable@freebsd.org; Tue, 22 Jul 2014 14:33:54 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1X9b8c-0004ND-Nc for freebsd-stable@freebsd.org; Tue, 22 Jul 2014 15:33:54 +0100 To: freebsd-stable@freebsd.org Subject: Mouse does not work with new Xorg, works with old Xorg (9.3-STABLE) Message-Id: From: Pete French Date: Tue, 22 Jul 2014 15:33:54 +0100 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 14:33:58 -0000 Yup, me again with another new xorg issue I am afraid. In this case its a lot more simple though - everything works, except for the mouse. The mouse is fine in the conosle but as soon as I start X it moves the mouse to the centre of th screen and it stops moving. I have moused disabled, and hald and dbus enabled - the config which works on my other machine runnign new_xorg. The kernel has vt and kbdmux compiled into it, but is otherwise generic. This is using the nex_xorg pkg repository. If I just use the default pkg repository all works fine. Hopefully this is a quick fix, but it puzzles me as the config is the same as the machine I am typing this on. I didnt think new-xorg affected the mouse drivers actually. -pete. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 14:42:21 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BE0BF785 for ; Tue, 22 Jul 2014 14:42:21 +0000 (UTC) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 87DE42D8E for ; Tue, 22 Jul 2014 14:42:21 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id m1so9616393oag.7 for ; Tue, 22 Jul 2014 07:42:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M9aUpaNO18qLaxyd3I8+HU67ntSkVaAamZvyJEmbt/A=; b=UUXDQzkEffm39klp9H1NTOZ8Re1Q0iFvRitnaFLmAvehMyHm87mq2ouzOdjRv110qW bhBk0HwwQAIk1qalwtzS5VTngmwU8c+mjvEnnmtxQXO8PUqObpIH95fkSIjCOEuDBuMY M8zs4G9/BX9A/ipN83e/Ps9lgrlrMDQkuQROPRHYJwyErNa+ebzWfLiNkqepXiOPLcic yb9qKe2mUcV91i4AmW/sfO+50wNMXUxrolwuDkw6dQDUgezKAuoA5NChZTaMIBHe+wRs M8lJspPVrfBJ+MWE99/uPv97sMbkdJ1ErnFSgOjqo7d59ZA568sDQ4WGSqxBfskaudp5 qagQ== MIME-Version: 1.0 X-Received: by 10.182.116.161 with SMTP id jx1mr49448555obb.50.1406040140373; Tue, 22 Jul 2014 07:42:20 -0700 (PDT) Received: by 10.76.170.39 with HTTP; Tue, 22 Jul 2014 07:42:20 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Jul 2014 16:42:20 +0200 Message-ID: Subject: Re: Mouse does not work with new Xorg, works with old Xorg (9.3-STABLE) From: Andreas Nilsson To: Pete French Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 14:42:21 -0000 On Tue, Jul 22, 2014 at 4:33 PM, Pete French wrote: > Yup, me again with another new xorg issue I am afraid. In this case > its a lot more simple though - everything works, except for > the mouse. The mouse is fine in the conosle but as soon as I start X it > moves the mouse to the centre of th screen and it stops moving. > > I have moused disabled, and hald and dbus enabled - the config > which works on my other machine runnign new_xorg. The kernel > has vt and kbdmux compiled into it, but is otherwise generic. > > This is using the nex_xorg pkg repository. If I just > use the default pkg repository all works fine. > > Hopefully this is a quick fix, but it puzzles me as the config > is the same as the machine I am typing this on. I didnt think > new-xorg affected the mouse drivers actually. > > -pete. > I'm having similar problems. But I have option devd for autoconfig. Anyway, I solved it by having the slim-script in /usr/local/etc/rc.d kill moused ( as even if you have moused="NO" in rc.conf devd autoruns moused on usb-attach, which leads to umsX being busy when xorg tries to open them ). I also had to have usbconfig power_off and power_on my lenovo usb-keyboad with trackpoint mouse as the mouse is not recognised on boot. Best regards Andreas From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 14:43:17 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C802880 for ; Tue, 22 Jul 2014 14:43:17 +0000 (UTC) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CDF502DA5 for ; Tue, 22 Jul 2014 14:43:16 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id z11so6131118lbi.3 for ; Tue, 22 Jul 2014 07:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o6ALFyYiqj/wH9sTSd9GtKZGl5MWMj28L5IxiAz7F6I=; b=q/11QiitiYIiYi0Feroy+C8qFkg/wvdZzy+Xv/BGWBpIcDLFwo7+PThrOngD/SI0+A /TEbmQv12UW31DPJKi6qdkuODOD3C5CiKhIQ3GAzAscWi4iIsMP/mAv7tPNafbttR127 qcv3V3hla92YbuzAyQ2IWjvuptmsJ4ej+hfVzOVHAyP2p3WvSmBXUY1CLE4i1KxPFp9Z W5ait/C3/LSqgqZ4XWUBVWzEjZ6ECZfwx9vPVZ8QnPEIaBClK7o3HebYwhEAg4m8XUBm N6wTLOF/qKPNb4TFWMkNgo9A7l2oENZUonH4+EuytVMX40coXOSfLtxmr8PW2aUP47Cp SZDQ== MIME-Version: 1.0 X-Received: by 10.112.173.201 with SMTP id bm9mr33057376lbc.16.1406040194601; Tue, 22 Jul 2014 07:43:14 -0700 (PDT) Received: by 10.153.4.5 with HTTP; Tue, 22 Jul 2014 07:43:14 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Jul 2014 16:43:14 +0200 Message-ID: Subject: Re: Mouse does not work with new Xorg, works with old Xorg (9.3-STABLE) From: Alban Hertroys To: Pete French Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 14:43:17 -0000 On 22 July 2014 16:33, Pete French wrote: > I have moused disabled, and hald and dbus enabled - the config > which works on my other machine runnign new_xorg. The kernel > has vt and kbdmux compiled into it, but is otherwise generic. Did you rebuild/update hald? That did the trick for me. -- If you can't see the forest for the trees, Cut the trees and you'll see there is no forest. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 14:45:07 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C4599EB for ; Tue, 22 Jul 2014 14:45:07 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 486F12DC9 for ; Tue, 22 Jul 2014 14:45:05 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1X9bJI-0001AL-Qs for freebsd-stable@freebsd.org; Tue, 22 Jul 2014 16:44:56 +0200 Received: from 208.85.208.53 ([208.85.208.53]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Jul 2014 16:44:56 +0200 Received: from atkin901 by 208.85.208.53 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Jul 2014 16:44:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Mark Atkinson Subject: Re: Mouse does not work with new Xorg, works with old Xorg (9.3-STABLE) Date: Tue, 22 Jul 2014 07:44:46 -0700 Lines: 39 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 208.85.208.53 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: X-Enigmail-Version: 1.6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 14:45:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/22/2014 07:33, Pete French wrote: > Yup, me again with another new xorg issue I am afraid. In this > case its a lot more simple though - everything works, except for > the mouse. The mouse is fine in the conosle but as soon as I start > X it moves the mouse to the centre of th screen and it stops > moving. > > I have moused disabled, and hald and dbus enabled - the config > which works on my other machine runnign new_xorg. The kernel has vt > and kbdmux compiled into it, but is otherwise generic. > > This is using the nex_xorg pkg repository. If I just use the > default pkg repository all works fine. > > Hopefully this is a quick fix, but it puzzles me as the config is > the same as the machine I am typing this on. I didnt think new-xorg > affected the mouse drivers actually. Kill moused before starting X and your mouse will work. I'm not sure why that works, but I started investigating and I think it had something to do with what hald reports as the mouse device. Also moused_enable="NO" in /etc/rc.conf seems to do nothing since devd picks it up. That's probably a bug since quietstart seems to be ignoring the rc.conf entry. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlPOeN4ACgkQrDN5kXnx8yYL1ACglxiRzzIO4B2PPii1PhlKfDWA AbcAnRppTHUsarPKxHS0q8E6/sZdTtdV =FqBP -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 14:56:36 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 901A9DF1 for ; Tue, 22 Jul 2014 14:56:36 +0000 (UTC) Received: from mproxy19.sbb.rs (mproxy19.sbb.rs [89.216.2.104]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.sbb.rs", Issuer "PositiveSSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0506B2EFB for ; Tue, 22 Jul 2014 14:56:35 +0000 (UTC) Received: from faust.localdomain (cable-178-148-98-89.dynamic.sbb.rs [178.148.98.89]) by mproxy19.sbb.rs (8.14.4/8.14.4) with ESMTP id s6MEt5JB023680 for ; Tue, 22 Jul 2014 16:55:05 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.6 at SBB mail Received: by faust.localdomain (Postfix, from userid 1001) id 6A2FBA41D42; Tue, 22 Jul 2014 16:55:28 +0200 (CEST) Date: Tue, 22 Jul 2014 16:55:28 +0200 From: Zoran Kolic To: freebsd-stable@freebsd.org Subject: Re: Mouse does not work with new Xorg, works with old Xorg (9.3-STABLE) Message-ID: <20140722145528.GA1364@faust.sbb.rs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mproxy19.sbb.rs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 14:56:36 -0000 What if you add new section, like this one: Section "Server Flags" Option "DontZap" "off" Option "AutoAddDevices" "false" EndSection I recall having problem with a mouse, without. Best regards Zoran From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 15:18:46 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 63734497 for ; Tue, 22 Jul 2014 15:18:46 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 25ABC2120 for ; Tue, 22 Jul 2014 15:18:46 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1X9bpz-000FuU-Si for freebsd-stable@freebsd.org; Tue, 22 Jul 2014 17:18:44 +0200 Message-ID: <53CE80D3.7090803@dumbbell.fr> Date: Tue, 22 Jul 2014 17:18:43 +0200 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Mouse does not work with new Xorg, works with old Xorg (9.3-STABLE) References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4o52WO0E1aJMLQrmIX0QGTF7SUiv7pPfG" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 15:18:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4o52WO0E1aJMLQrmIX0QGTF7SUiv7pPfG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 22.07.2014 16:42, Andreas Nilsson wrote: > I'm having similar problems. But I have option devd for autoconfig. Any= way, > I solved it by having the slim-script in /usr/local/etc/rc.d kill mouse= d ( > as even if you have moused=3D"NO" in rc.conf devd autoruns moused on > usb-attach, which leads to umsX being busy when xorg tries to open them= ). USB mices automatically start moused(8) by default. Add the following line to your /etc/rc.conf: moused_nondefault_enable=3D"NO" The moused_enable knob has no effect in this case. This may fix your issues with new_xorg packages. --=20 Jean-S=E9bastien P=E9dron --4o52WO0E1aJMLQrmIX0QGTF7SUiv7pPfG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTzoDTAAoJEDnpl2Gl/ZTMlOgQAJaE14X4wC4Dlh3aUVp9MXw/ AGnPMGuyZOmr6nljqaghvJo60KZdu71FrdgOH/LF+jl2SAXdU48XgeQ9TsMHbOSB UndavqTJwGJxOnijR53mSD45wtBcdeBmW9o8ou6tTX+45PhICle7MCx9XCgdYfuQ D2CDWYsxy1HQc2kMfE0hB1K4Ym5wWPdVOM65OK3cTM/P/rGGVcG6hmWIQ6TIKZe0 sbGqM8XNWOQOY66kxDJcEewJVSGE9/DXgEbPRSuymVXUqIT8b6j8JOZtsP7E67DD eifqD0IOIPV+hSaqvjLEDYJfeSoz3o7pRkkddVKuCQz2X0hvkoLUlYOOvms5dsBf ncCjtxtC5tjbYg5GjFp2Up43e3YufKSsqjAC7IDckCSR7s/grMtrZpGxXKYbh89u h4WT2+EYZoRBUmIFtflbUfrYWtGqLBLWhqphq1EOb9M7oq34xXcQpFgn058Lex/m LfcyF7Nc/FIZXOMFSkGPRchWLxx3BSAGVKcnZP6FwMM75FiDD9nX5tudb8iQWfTH kTy7fiJISv8vrAictbOLkKmZ2ai7fvha4HCoq1XilM1S3A8RsWr3KJmDegupsIV6 UcI7x4pPASigLNGLcL8rU+BALG6moRr2fqJqj8OHLFPTxLRjiU5W16MXqg1otrRT 6iL7SlRr/hPaR9l+uHPt =yGt7 -----END PGP SIGNATURE----- --4o52WO0E1aJMLQrmIX0QGTF7SUiv7pPfG-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 16:29:34 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF754645 for ; Tue, 22 Jul 2014 16:29:34 +0000 (UTC) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B6BDD2939 for ; Tue, 22 Jul 2014 16:29:34 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1X9cwV-00089H-MN; Tue, 22 Jul 2014 16:29:31 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1X9cwV-0001vH-K4; Tue, 22 Jul 2014 17:29:31 +0100 To: freebsd-stable@freebsd.org, jean-sebastien.pedron@dumbbell.fr Subject: Re: Mouse does not work with new Xorg, works with old Xorg (9.3-STABLE) In-Reply-To: <53CE80D3.7090803@dumbbell.fr> Message-Id: From: Pete French Date: Tue, 22 Jul 2014 17:29:31 +0100 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 16:29:35 -0000 Thanks to all those who replied to this - making sure that moused is not running fixes it, sort of. First time after boot it works, stop X and sttart it again, it does not work, but unpligging the mouse and pluggin it back in seems to get it to work again. Havent experikmented much, have just got the machine up and doing that it is supposed to, and am very happy with it. I ended up using this in rc.conf as suggested to stop moused running. moused_nondefault_enable="NO" I didnt realise it would run even with moused-enable="NO' unless this is added. Despite thr rough edges in places I am really pleased with new_xorg - the actual driving of the graphics cards works really nicely. thanks, -pete. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 22 19:11:08 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 45E4FFE6 for ; Tue, 22 Jul 2014 19:11:08 +0000 (UTC) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B83629E4 for ; Tue, 22 Jul 2014 19:11:07 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id o6so158828oag.10 for ; Tue, 22 Jul 2014 12:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7Xsx9CF0rYb2pWBKLfZW1fFnCuSkXEuudBU4ndGu/Sk=; b=WoKUQ95xil2wYO7sRTw8BR/2GSHXWBCevGiWxrFRh8FWAsqMfH0tpKCL/+a9dORIJx N7gjEcRl5Uv8CPJtO8iWCslTbJtEVIVQIYwzAdFhAxuy8pakLlSDKG8UNG9nenyWczuu xM5Ym6auEbY8S7eerM+CwlRH7X8XMUf3IiVbq5V0h5QVpcqOrLfUsStZSjpnS4n6wF4M dtHnjiNImjKcFaBbCOWYJ2PccoYLj4ZRIP5K3SP3rW61eKxSQ/mLib3tC6S64Zo31Z1V 0rvzrbd4NKZmElydLTiPojoDpKrkvsmWv5fzLr/a7nLci02KZq/T7AH9Bd/oC9/sjoNg CWRQ== MIME-Version: 1.0 X-Received: by 10.60.125.103 with SMTP id mp7mr16541325oeb.53.1406056267311; Tue, 22 Jul 2014 12:11:07 -0700 (PDT) Received: by 10.76.170.39 with HTTP; Tue, 22 Jul 2014 12:11:07 -0700 (PDT) In-Reply-To: References: <53CE80D3.7090803@dumbbell.fr> Date: Tue, 22 Jul 2014 21:11:07 +0200 Message-ID: Subject: Re: Mouse does not work with new Xorg, works with old Xorg (9.3-STABLE) From: Andreas Nilsson To: Pete French Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= , FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 19:11:08 -0000 On Tue, Jul 22, 2014 at 6:29 PM, Pete French wrote: > Thanks to all those who replied to this - making sure that moused > is not running fixes it, sort of. First time after boot it works, > stop X and sttart it again, it does not work, but unpligging > the mouse and pluggin it back in seems to get it to work again. > Havent experikmented much, have just got the machine up and doing that > it is supposed to, and am very happy with it. > > I ended up using this in rc.conf as suggested to stop moused running. > > moused_nondefault_enable="NO" > Interesting that it works for you. If I set that I get no umsX devices at all :( Best regards Andreas > > I didnt realise it would run even with moused-enable="NO' unless this is > added. > Despite thr rough edges in places I am really pleased with new_xorg - the > actual driving of the graphics cards works really nicely. > > thanks, > > -pete. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 07:10:45 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44F8B7F4 for ; Wed, 23 Jul 2014 07:10:45 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0733028B7 for ; Wed, 23 Jul 2014 07:10:44 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1X9qhG-00097U-Ij for freebsd-stable@freebsd.org; Wed, 23 Jul 2014 09:10:42 +0200 Message-ID: <53CF5FED.1030002@dumbbell.fr> Date: Wed, 23 Jul 2014 09:10:37 +0200 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Mouse does not work with new Xorg, works with old Xorg (9.3-STABLE) References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3Lk96iUspW4nGeaNbGbcV4QhhcNcHlN1Q" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 07:10:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3Lk96iUspW4nGeaNbGbcV4QhhcNcHlN1Q Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 22.07.2014 18:29, Pete French wrote: > First time after boot it works, stop X and sttart it again, it does > not work, but unpligging the mouse and pluggin it back in seems to > get it to work again. Could you please post both /var/log/Xorg.0.log and /var/log/Xorg.0.log.old, after you started that second X session, but before unplugging/plugging your mouse in? > I ended up using this in rc.conf as suggested to stop moused running. >=20 > moused_nondefault_enable=3D"NO" >=20 > I didnt realise it would run even with moused-enable=3D"NO' unless this= is added. That puzzled me the first time too :) > Despite thr rough edges in places I am really pleased with new_xorg - t= he > actual driving of the graphics cards works really nicely. Great, thank you for the report! --=20 Jean-S=E9bastien P=E9dron --3Lk96iUspW4nGeaNbGbcV4QhhcNcHlN1Q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTz1/yAAoJEDnpl2Gl/ZTMDHAP/jnzuPSU4DZRhtKUxZrLAfRd +j+FvQCINMlth1oOUlu3Q7kssw6guzbDObI9s5pgoi7RkB3tl82qDbrVMGGtxm8g 0nb3zSMb5z+T4ksrNjv5cyCh9NzaxdcxVEgVs90rdYOdUO5cSIB5T9SGKWOrLZwu Yd6a0m+qUvHRL00HvIExdamjxh/0xF9CFcxGlcCY9w2nxgOmccQaRgARVXzRjclX DsbPOcLhe4gxh1w9LpY0rKA4Bk3BpH+1nh2YsA+XT5pQIgQlX2XTPto/5DbsyinN qF7E/BecwCgasiVZVCgqcfw5unJwiGLmeR6bsMDaIThoJpl6999WdBlv/eQ0fgkn P0QDG6RxoBFfmHiEpfPN3svqqeBwPN9qLMcp2yqNl3Nqt9IzxQewPsQjsKkaGl9w O/MW2g6BJL6COkBLG6zxwAfaSymrordvcTwzGZLd2ib1a5kT3byn9xsxvl0BbJ8X jXo41xcKBVvWgripY1/NjUGPt9YXuJkwyAH5LImsbKE7JEyf/1uEBOpXr+BknLdF D4bOivIH+8oH+imVbPENq2MMwaNTgz/5ZcneYo61o+J2lT++FHjiZJcMy7B1e1xD FwWP59pnxALS/ndL/Gpiak2NKt48HQvasot3zmg3J37oyVFn8MFGKIDLcSjGyC/z PgsPdNOa4JIEIfaZzuxw =ELZh -----END PGP SIGNATURE----- --3Lk96iUspW4nGeaNbGbcV4QhhcNcHlN1Q-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 07:11:05 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 628758E8 for ; Wed, 23 Jul 2014 07:11:05 +0000 (UTC) Received: from mail.made4.biz (mail.made4.biz [IPv6:2001:41d0:2:c018::1:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2392828C6 for ; Wed, 23 Jul 2014 07:11:05 +0000 (UTC) Received: from [2001:1b48:10b:cafe:225:64ff:febe:589f] (helo=viking.yzserv.com) by mail.made4.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1X9qhb-00098Z-Dk for freebsd-stable@freebsd.org; Wed, 23 Jul 2014 09:11:03 +0200 Message-ID: <53CF6007.4050406@dumbbell.fr> Date: Wed, 23 Jul 2014 09:11:03 +0200 From: =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Mouse does not work with new Xorg, works with old Xorg (9.3-STABLE) References: <53CE80D3.7090803@dumbbell.fr> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cH415j8asqX4dhcnW7MroVhfB0KxSGiBH" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 07:11:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cH415j8asqX4dhcnW7MroVhfB0KxSGiBH Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 22.07.2014 21:11, Andreas Nilsson wrote: > Interesting that it works for you. If I set that I get no umsX devices = at > all :( That's very strange, because moused(8) isn't involved in the creation of /dev entries. The ums(4) kernel module is responsible for that. It's automatically loaded by devd(8) when a USB mouse is plugged in (see /etc/devd/usb.conf, look for "ums"). Double-check that devd(8) is enabled (it is by default) and running. --=20 Jean-S=E9bastien P=E9dron --cH415j8asqX4dhcnW7MroVhfB0KxSGiBH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTz2AHAAoJEDnpl2Gl/ZTMO5AP/3WjULLWUEHmfPjwmkK5QcsI qxz11yOU/81S6pG3ulUzX1wd+aUMAZV8MgiHlGzfbyz0lOIKKCT+9CU2tbzsRp3T UVXs9aeBCBirfY9MY8ck/5Gd6hasz8OSAnTDSrVZwy20rnYgTD5jdodOT85mhxTK g2vjeUfR4POdgUoG5YfAoSVYRR5EadA4MWFyy2iDyqmUKGZdcuhq6TifkKLdE/AZ cQJ2E6ksRJS62ETOgeWN1Jpz4qvE8IkgBxVebBteLimwEcme8zCDoQ52HKTHlyLx km3pS+Q3NtQsUUI3pxcRa+05rpd7wdxcMZsPlD6SZUWw9k53nUOXKbk5nDiIp3LJ TiSBBbFXPwvuiuyTXD7Ef9ZDBt2JjkYPmngeTjDTjv105539hOHHgRYiMouqT4WW nN/FHpEcyn3z6ImnAe8E0JBv7BnRfgkmP42Utzkz6DFPxfwgbBxgQ/XcYZHlzGJS k3BA/HeVu2e+6HimgCkDKRsRYr041BAGIa/tk7IdYfPcXc1Yx3NIxhorj/ZVY03U EBwhu8tObySh6ne9CdZxY0qlMVfFYCV7y8ZF0tAeGuppldJ7mJ3nDB1QDTXi5OBD UxGnR/s3O1E6m5yX/RIGJ0fRBtra5/VQsRIAJZLTGtBgo3B3M2C3Xsgx0h0m6Ba/ KcbHbUoogBAuau/ahjkN =jGOH -----END PGP SIGNATURE----- --cH415j8asqX4dhcnW7MroVhfB0KxSGiBH-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 08:37:36 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A5FA81B for ; Wed, 23 Jul 2014 08:37:36 +0000 (UTC) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 11B1C2138 for ; Wed, 23 Jul 2014 08:37:36 +0000 (UTC) Received: by mail-oi0-f41.google.com with SMTP id a141so616825oig.14 for ; Wed, 23 Jul 2014 01:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lbJsv5j1EPx899wxIqhMxTP85Mvd4I9Iw3sBEdmqv9k=; b=oM34CIeqHDzbppxg4Boc/h0qa4cPe/t4pCkeF1EwqDozlNpQ2hCEELZyI2ij33A5mg 0/RSyoWJuA2CltDFnufMJ+uLedoazESqUtWOk2E8Qk0QH4Ipq/9pZ7tKAODICzVoSFx0 ChcMbXpcnWwx3iHzYQh51lcxWO3FI9uHl2nXwPmb/Rufuw392PJernhqwQkysSE4yVhg oa5O3FDsIc6oICa8FlQnkVdHVcW4ke2th3SqVi5+4XGTgg5Uog4z0PUVXODAg98cseu7 ND4y9iAgJqDwf3kemfKV+yh2xgvHBi9dE/9ejwGjqqYOAh/6CQbxmZaX3qdD2yCjgZLs akcQ== MIME-Version: 1.0 X-Received: by 10.182.236.225 with SMTP id ux1mr55934720obc.57.1406104653540; Wed, 23 Jul 2014 01:37:33 -0700 (PDT) Received: by 10.76.170.39 with HTTP; Wed, 23 Jul 2014 01:37:33 -0700 (PDT) In-Reply-To: <53CF6007.4050406@dumbbell.fr> References: <53CE80D3.7090803@dumbbell.fr> <53CF6007.4050406@dumbbell.fr> Date: Wed, 23 Jul 2014 10:37:33 +0200 Message-ID: Subject: Re: Mouse does not work with new Xorg, works with old Xorg (9.3-STABLE) From: Andreas Nilsson To: =?UTF-8?B?SmVhbi1Tw6liYXN0aWVuIFDDqWRyb24=?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 08:37:36 -0000 On Wed, Jul 23, 2014 at 9:11 AM, Jean-S=C3=A9bastien P=C3=A9dron < jean-sebastien.pedron@dumbbell.fr> wrote: > On 22.07.2014 21:11, Andreas Nilsson wrote: > > Interesting that it works for you. If I set that I get no umsX devices = at > > all :( > > That's very strange, because moused(8) isn't involved in the creation of > /dev entries. The ums(4) kernel module is responsible for that. It's > automatically loaded by devd(8) when a USB mouse is plugged in (see > /etc/devd/usb.conf, look for "ums"). > > Double-check that devd(8) is enabled (it is by default) and running. > > -- > Jean-S=C3=A9bastien P=C3=A9dron > > Devd is running, yes. If I load ums and reconnect the keyboard I get a umsX device. usbconfig dump_device_desc gives: ugen1.4: at usbus1, cfg=3D0 md=3DHOST spd=3DLOW (1.5Mbps) pwr=3DON (100mA) bLength =3D 0x0012 bDescriptorType =3D 0x0001 bcdUSB =3D 0x0110 bDeviceClass =3D 0x0000 bDeviceSubClass =3D 0x0000 bDeviceProtocol =3D 0x0000 bMaxPacketSize0 =3D 0x0008 idVendor =3D 0x17ef idProduct =3D 0x6009 bcdDevice =3D 0x0126 iManufacturer =3D 0x0001 iProduct =3D 0x0002 iSerialNumber =3D 0x0000 bNumConfigurations =3D 0x0001 So maybe some quirks are needed for this to trigger the devd-rule. Having ums in loader.conf and moused_nondefault_enable=3D"NO" seems to work just fine though. Thanks! Best regards Andreas From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 09:51:02 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A69B07D8 for ; Wed, 23 Jul 2014 09:51:02 +0000 (UTC) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 609CE2778 for ; Wed, 23 Jul 2014 09:51:02 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1X9tCD-000Ajo-3l; Wed, 23 Jul 2014 09:50:49 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1X9tCD-0007iB-1L; Wed, 23 Jul 2014 10:50:49 +0100 To: andrnils@gmail.com, petefrench@ingresso.co.uk Subject: Re: Mouse does not work with new Xorg, works with old Xorg (9.3-STABLE) In-Reply-To: Message-Id: From: Pete French Date: Wed, 23 Jul 2014 10:50:49 +0100 Cc: jean-sebastien.pedron@dumbbell.fr, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 09:51:02 -0000 > Interesting that it works for you. If I set that I get no umsX devices at > all :( I tried this on the desktop which was perviously working without it set, just for curiosity. The effect there is that I can run X once, but if I run it again it has no mouse. On that machine I do need to have moused running. All a bit odd - am sorry that none of the solutions work for you though. -pete. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 12:36:10 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8744B8A3 for ; Wed, 23 Jul 2014 12:36:10 +0000 (UTC) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id 5D1E62600 for ; Wed, 23 Jul 2014 12:36:10 +0000 (UTC) Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.41]) by be-well.ilk.org (Postfix) with ESMTP id C642133C18 for ; Wed, 23 Jul 2014 08:36:03 -0400 (EDT) Received: by lowell-desk.lan (Postfix, from userid 1147) id AF7DC3980E; Wed, 23 Jul 2014 08:36:01 -0400 (EDT) From: Lowell Gilbert To: stable@freebsd.org Subject: Re: Mouse does not work with new Xorg, works with old Xorg (9.3-STABLE) References: <53CF5FED.1030002@dumbbell.fr> Date: Wed, 23 Jul 2014 08:36:00 -0400 In-Reply-To: <53CF5FED.1030002@dumbbell.fr> (=?iso-8859-1?Q?=22Jean-S=E9ba?= =?iso-8859-1?Q?stien_P=E9dron=22's?= message of "Wed, 23 Jul 2014 09:10:37 +0200") Message-ID: <44y4vkckwf.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 12:36:10 -0000 Jean-S=E9bastien P=E9dron writes: > On 22.07.2014 18:29, Pete French wrote: >> First time after boot it works, stop X and sttart it again, it does >> not work, but unpligging the mouse and pluggin it back in seems to >> get it to work again. > > Could you please post both /var/log/Xorg.0.log and > /var/log/Xorg.0.log.old, after you started that second X session, but > before unplugging/plugging your mouse in? That sounds more like devfs than devd, no? From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 14:43:03 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B4DE86A; Wed, 23 Jul 2014 14:43:03 +0000 (UTC) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C022B242F; Wed, 23 Jul 2014 14:43:02 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id a1so1278743wgh.11 for ; Wed, 23 Jul 2014 07:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=hZ8bXliNls61+4eeVd2h49dA4PpNguga302kcxAoRmM=; b=ai7LElPPLqIEDcxv+1eBM2biK2ocLJtOqREfEZOm0+wTM5PDvDomhavBN9Zu21VAdr gw21XT1hgHmPoOf/iunRvrSplzwTHSna/o2Q9UoFkKo/oGaHNZpJGeMmdHELiS2dQfJx wPebuxmu8KmWlF0wtc2uDdjwqE3WnfNaBLe/6QkOCoK+lqu4l+r6OmIfRsWGNEJ4Dw90 QbJ+BgcIqYb2VhM+9Ck/y5JNqCLIiXvu5oiAB6RPdeYJ0X0YrRCW6diSQ3+uwr34vAuQ a098qXcoSwSRIozvh754X5qIaNF83DR5Pns5XmHNh1/luEX+awo+JQChjY774y6B3n4n ukmA== X-Received: by 10.180.21.235 with SMTP id y11mr3519771wie.75.1406126579303; Wed, 23 Jul 2014 07:42:59 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id fu7sm9993824wib.2.2014.07.23.07.42.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Jul 2014 07:42:53 -0700 (PDT) Sender: Baptiste Daroussin Date: Wed, 23 Jul 2014 16:42:51 +0200 From: Baptiste Daroussin To: ports@FreeBSD.org, stable@FreeBSD.org, current@FreeBSD.org Subject: [ANNOUNCEMENT] pkg 1.3.0 out! Message-ID: <20140723144249.GD69907@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vni90+aGYgRvsTuO" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 14:43:03 -0000 --vni90+aGYgRvsTuO Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, I'm very please to announce the release of pkg 1.3.0 This version is the result of almost 9 month of hard work Here are the statistics for the version: - 373 files changed, 66973 insertions(+), 38512 deletions(-) - 29 different contributors Please not that for the first time I'm not the main contributor, and I would like to particularly thanks Vsevold Stakhov for all the hard work he has do= ne to allow us to get this release out. I would like also to give a special thank= s to Andrej Zverev for the tons of hours spending on testing and cleaning the bug tracker! So much has happened that it is hard to summarize so I'll try to highlight = the major points: - New solver, now pkg has a real SAT solver able to automatically handle conflicts and dynamically discover them. (yes pkg set -o is deprecated no= w) - pkg install now able to install local files as well and resolve their dependencies from the remote repositories - Lots of parts of the code has been sandboxed - Lots of rework to improve portability - Package installation process has been reworked to be safer and handle pro= perly the schg flags - Important modification of the locking system for finer grain locks - Massive usage of libucl - Simplification of the API - Lots of improvements on the UI to provide a better user experience. - Lots of improvements in multi repository mode - pkg audit code has been moved into the library - pkg -o A=3DB that will overwrite configuration file from cli - The ui now support long options - The unicity of a package is not anymore origin - Tons of bug fixes - Tons of behaviours fixes - Way more! Thank you to all contributors: Alberto Villa, Alexandre Perrin, Andrej Zverev, Antoine Brodin, Brad Davis, Bryan Drewery, Dag-Erling Sm=F8rgrav, Dmitry Marakasov, Elvira Khabirova, J= amie Landeg Jones, Jilles Tjoelker, John Marino, Julien Laffaye, Mathieu Arnold, Matthew Seaman, Maximilian Ga=DF, Michael Gehring, Michael Gmelin, Nicolas = Szalay, Rodrigo Osorio, Roman Naumann, Rui Paulo, Sean Channel, Stanislav E. Putrya, Vsevolod Stakhov, Xin Li, coctic Regards, Bapt on behalf of the pkg@ --vni90+aGYgRvsTuO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPPyekACgkQ8kTtMUmk6ExikACfcdA+TEaFQ/jmst/Wr6Z4jIVZ AucAnim6B1X29+QrimPhsoGO3awMWT0T =ib/R -----END PGP SIGNATURE----- --vni90+aGYgRvsTuO-- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 15:53:06 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72D7DB12 for ; Wed, 23 Jul 2014 15:53:06 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2AC002C00 for ; Wed, 23 Jul 2014 15:53:05 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1X9yqd-0003XU-RP for freebsd-stable@freebsd.org; Wed, 23 Jul 2014 17:52:55 +0200 Received: from 208.85.208.53 ([208.85.208.53]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Jul 2014 17:52:55 +0200 Received: from atkin901 by 208.85.208.53 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Jul 2014 17:52:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Mark Atkinson Subject: Re: Mouse does not work with new Xorg, works with old Xorg (9.3-STABLE) Date: Wed, 23 Jul 2014 08:52:44 -0700 Lines: 24 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 208.85.208.53 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: X-Enigmail-Version: 1.6 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 15:53:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/23/2014 02:50, Pete French wrote: >> Interesting that it works for you. If I set that I get no umsX >> devices at all :( > > I tried this on the desktop which was perviously working without it > set, just for curiosity. The effect there is that I can run X once, > but if I run it again it has no mouse. On that machine I do need to > have moused running. > > All a bit odd - am sorry that none of the solutions work for you > though. Are you perhaps using a xorg.conf with a sysmouse device entry? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlPP2kwACgkQrDN5kXnx8yY7qACdGiTUZsJ+KJNW1C2DMl+E2e+O Oo4AniV1r4nSmJPks4hHScRGfdJ+vj+A =5HYg -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 18:38:55 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 457DAF97; Wed, 23 Jul 2014 18:38:55 +0000 (UTC) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B7792C37; Wed, 23 Jul 2014 18:38:55 +0000 (UTC) Received: by mail-pa0-f47.google.com with SMTP id kx10so2246239pab.34 for ; Wed, 23 Jul 2014 11:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=fdpQ5OYsr4wrOPctsXCSDcXxz9pOUiym2ftIlQ2ZQkg=; b=egTLJlkI4L+5pYG/jY4O+cSQaJUXnMVX0w1vzDWboFtRBDwotCPO/JcdTtfcbPi2sL eC8V9rm5rZQjOL/899fNE/iBbKfSiTFGFFn4vvaigtgATsGZSXUOy/JFk2OJq7rLnk6J hcgB7Uwy/oTswMMcdMC/jX/MMreuo/TonNdjUsgP60QfxdsmqYhhVCKg7WJJZaa8Z1pC qEXITandoaUKBVmY5psz1VgNYhZBZ4VpLsQvffm5HaRpK/YNCFK2wqtTDoF6QU9Z0fLE GNNPdIKTUcO3NcdMws/H47035g/TCbH0vpCbZtf8kBcTTOBX1uEvbMz64WTrAyx1+xOZ SBPA== MIME-Version: 1.0 X-Received: by 10.70.34.228 with SMTP id c4mr4401394pdj.76.1406140734553; Wed, 23 Jul 2014 11:38:54 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.66.88.227 with HTTP; Wed, 23 Jul 2014 11:38:54 -0700 (PDT) In-Reply-To: <20140723144249.GD69907@ivaldir.etoilebsd.net> References: <20140723144249.GD69907@ivaldir.etoilebsd.net> Date: Wed, 23 Jul 2014 11:38:54 -0700 X-Google-Sender-Auth: ptzte3N3-EyAPal4OTKO7I2n1us Message-ID: Subject: Re: [ANNOUNCEMENT] pkg 1.3.0 out! From: Kevin Oberman To: Baptiste Daroussin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "ports@FreeBSD.org" , FreeBSD Stable ML , "current@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 18:38:55 -0000 On Wed, Jul 23, 2014 at 7:42 AM, Baptiste Daroussin wrote: > Hi all, > > I'm very please to announce the release of pkg 1.3.0 > This version is the result of almost 9 month of hard work > > Here are the statistics for the version: > - 373 files changed, 66973 insertions(+), 38512 deletions(-) > - 29 different contributors > > Please not that for the first time I'm not the main contributor, and I > would > like to particularly thanks Vsevold Stakhov for all the hard work he has > done to > allow us to get this release out. I would like also to give a special > thanks to > Andrej Zverev for the tons of hours spending on testing and cleaning the > bug > tracker! > > So much has happened that it is hard to summarize so I'll try to highligh= t > the > major points: > - New solver, now pkg has a real SAT solver able to automatically handle > conflicts and dynamically discover them. (yes pkg set -o is deprecated > now) > - pkg install now able to install local files as well and resolve their > dependencies from the remote repositories > - Lots of parts of the code has been sandboxed > - Lots of rework to improve portability > - Package installation process has been reworked to be safer and handle > properly > the schg flags > - Important modification of the locking system for finer grain locks > - Massive usage of libucl > - Simplification of the API > - Lots of improvements on the UI to provide a better user experience. > - Lots of improvements in multi repository mode > - pkg audit code has been moved into the library > - pkg -o A=3DB that will overwrite configuration file from cli > - The ui now support long options > - The unicity of a package is not anymore origin > - Tons of bug fixes > - Tons of behaviours fixes > - Way more! > > Thank you to all contributors: > Alberto Villa, Alexandre Perrin, Andrej Zverev, Antoine Brodin, Brad Davi= s, > Bryan Drewery, Dag-Erling Sm=C3=B8rgrav, Dmitry Marakasov, Elvira Khabiro= va, > Jamie > Landeg Jones, Jilles Tjoelker, John Marino, Julien Laffaye, Mathieu Arnol= d, > Matthew Seaman, Maximilian Ga=C3=9F, Michael Gehring, Michael Gmelin, Nic= olas > Szalay, > Rodrigo Osorio, Roman Naumann, Rui Paulo, Sean Channel, Stanislav E. > Putrya, > Vsevolod Stakhov, Xin Li, coctic > > Regards, > Bapt on behalf of the pkg@ > Really, really great news! Congrats to Bapt and all of the contributors, large and small, for doing the work to make this happen. The real, live, provable solver is something that was desperately needed. Thaqt is followed closely with multi-repository mode. All of the rest is great, too. I think one bullet was a bit mangled in French->English translation, though. What does "The unicity of a package is not anymore origin" mean? I have a couple of guesses, but I am not really sure. Ithink the best translations would be "The unicity of a package is no longer the origin", but I am unsure of "unicity". "Uniqueness"? That would make sense, but I am not quite sure that is what was meant. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 19:22:17 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D654DC6 for ; Wed, 23 Jul 2014 19:22:17 +0000 (UTC) Received: from smtp.pobox.com (smtp.pobox.com [208.72.237.35]) by mx1.freebsd.org (Postfix) with ESMTP id A007720A7 for ; Wed, 23 Jul 2014 19:22:17 +0000 (UTC) Received: from smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp0.pobox.com (Postfix) with ESMTP id 7DA5F2AE08 for ; Wed, 23 Jul 2014 15:21:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from:to :subject:message-id:references:mime-version:content-type :in-reply-to; s=sasl; bh=DEpGFmaUcrtvMkMxGI90R5dwpJ8=; b=UAB4vnS bd3SZLVPXl8XIUZnQSfZ+Kt1qO/5c8Be/Rocf6EWVSU/fpyN8Tj6jLGhRSx+s+Yy mI+n1rZicfN5y8FmpUZbgTJ8URK6fY9jgoDPnDlctmAT5ytgmwGXFHUYi/UolX3U QRFSCG2311k/Bgush3Vr89BKYW9z6y+RseDs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from:to :subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=sasl; b=qdr7V1Nqi2v+S4qRK+YqS4WD4989N+yoQ O55GfwVVTkB4jYIwSG/YjqbLsXCyZOA0Z4ul4hpzmCWgLiGJbv7o8VbFHdoT17m7 Rn8EjuqUaldJI/K7NhOjHTMQ6fkJh0Qic3btaGpd3TMQbFYJ0zbqOrps+RS5ZQew i5954RjWVo= Received: from pb-smtp0.int.icgroup.com (unknown [127.0.0.1]) by pb-smtp0.pobox.com (Postfix) with ESMTP id 708522AE07 for ; Wed, 23 Jul 2014 15:21:40 -0400 (EDT) Received: from localhost (unknown [50.90.2.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-smtp0.pobox.com (Postfix) with ESMTPSA id 85FBC2AE02 for ; Wed, 23 Jul 2014 15:21:34 -0400 (EDT) Date: Wed, 23 Jul 2014 15:21:33 -0400 From: Chris Nehren To: FreeBSD Stable ML Subject: Re: [ANNOUNCEMENT] pkg 1.3.0 out! Message-ID: <20140723191949.GA1197@satori.lan> Mail-Followup-To: FreeBSD Stable ML References: <20140723144249.GD69907@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pAwQNkOnpTn9IO2O" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Pobox-Relay-ID: 8F42394A-129E-11E4-A913-9903E9FBB39C-49531120!pb-smtp0.pobox.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 19:22:17 -0000 --pAwQNkOnpTn9IO2O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 23, 2014 at 11:38:54 -0700, Kevin Oberman wrote: > On Wed, Jul 23, 2014 at 7:42 AM, Baptiste Daroussin > wrote: >=20 > > Hi all, > > > > I'm very please to announce the release of pkg 1.3.0 > > This version is the result of almost 9 month of hard work > > > > Here are the statistics for the version: > > - 373 files changed, 66973 insertions(+), 38512 deletions(-) > > - 29 different contributors > > > > Please not that for the first time I'm not the main contributor, and I > > would > > like to particularly thanks Vsevold Stakhov for all the hard work he has > > done to > > allow us to get this release out. I would like also to give a special > > thanks to > > Andrej Zverev for the tons of hours spending on testing and cleaning the > > bug > > tracker! Awesome work! I am very much looking forward to enjoying the new features. Many thanks to everyone involved! > I think one bullet was a bit mangled in French->English translation, > though. What does "The unicity of a package is not anymore origin" mean? I > have a couple of guesses, but I am not really sure. Ithink the best > translations would be "The unicity of a package is no longer the origin", > but I am unsure of "unicity". "Uniqueness"? That would make sense, but I = am > not quite sure that is what was meant. $ dict unicity 220 pan.alephnull.com dictd 1.12.1/rf on Linux 3.14-1-amd64 <62= 33175.24164.1406142610@pan.alephnull.com> 250 ok 150 1 definitions retrieved 151 "Unicity" gcide "The Collaborative International Dictionary of English = v.0.48" Unicity \U*nic"i*ty\, n. [L. unicus single. See {Unique}.] The condition of being united; quality of the unique; unification. [1913 Webster] Not unity, but what the schoolmen call unicity. --De Quincey. [1913 Webster] The unicity we strive not to express, for that is impossible, but to designate by the nearest analogy. --Coleridge. [1913 Webster] =2E 250 ok [d/m/c =3D 1/0/15; 0.000r 0.000u 0.000s] 221 bye [d/m/c =3D 0/0/0; 0.000r 0.000u 0.000s] $ I had to look it up, too, but it is a real (if uncommon) English word. I appreciate having learned it. --=20 Chris Nehren --pAwQNkOnpTn9IO2O Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJbBAABAgBFBQJT0As9PhSAAAAAABUAIHBrYS1hZGRyZXNzQGdudXBnLm9yZ2Nu ZWhyZW4rZnJlZWJzZC1zdGFibGVAcG9ib3guY29tAAoJEBHA+GJAM0vPhPAP/0wT 3uzLBx9NDqXgqmt0lDZO1eHFs9eHyCo4YMxD1ucdMJuA0blnPXh/YhIpgoStDTji t/FxwJMdjYIY7yVPSv9+ENJqiwkRhwqRFhMHSO25BY7LOX/i83bvsOkaFP7HcPyu yJUujl4HtvwXpM5XmyMsKPouk249kwrFE72S4//Fo44x56EveiB3u82QPKiCHCou Cx+HSTlshrWyEfTkfsLL+nUMDgarMjqYmwyyEt/dBNQpNVxcQJYfXeyeSpHMHOXK Ocz97LCPcGQjptRyRXfpEANNhI5K4mk0LdMFkqOdcXf2zl64ucccOc7Ah02xGgjw ckk61JoalneexCi1slOzkTfOPNRTsnnG0H+RDcZY3saDYZ5ezF7Eit1eQXgkRzey 5DPgbfohzURsiexCffGpQ2JMKTKMk1W/ir9zStehGZAfT1J29V8+2+3gb0oQaSFf 5beztRUrdTBMyDXwFO8wuCea+Qh2Jo+xL8AePimNwGt6NO2+eZ1MglkJ/gWM+ltz zwp+4k5E7xQnH/CJ+pyNm8DGc+Qz28MufPiMnSPKgXZLAKc0zxK8alTK/Y9Px5fu Bb9kA8lXWDlvCCWH7833cSjHvlcqn4WMbozJU3D1wXZXwNIZEweDUMSjUf6jCJi6 OVDSlE3LEUD44Wlz4mD9L6xfgCp4f6QlNiwUTxqW =0qCK -----END PGP SIGNATURE----- --pAwQNkOnpTn9IO2O-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 08:48:44 2014 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6CF38919; Thu, 24 Jul 2014 08:48:44 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cloud.theravensnest.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1BEB625D0; Thu, 24 Jul 2014 08:48:43 +0000 (UTC) Received: from [192.168.0.7] (cpc14-cmbg15-2-0-cust307.5-4.cable.virginm.net [82.26.1.52]) (authenticated bits=0) by theravensnest.org (8.14.7/8.14.7) with ESMTP id s6O8i2xu077662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Jul 2014 08:47:00 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [ANNOUNCEMENT] pkg 1.3.0 out! From: David Chisnall In-Reply-To: <20140723144249.GD69907@ivaldir.etoilebsd.net> Date: Thu, 24 Jul 2014 09:43:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140723144249.GD69907@ivaldir.etoilebsd.net> To: Baptiste Daroussin X-Mailer: Apple Mail (2.1878.6) Cc: ports@FreeBSD.org, stable@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 08:48:44 -0000 Great news! I've been running the 1.3 prereleases for a while, and aside from one = hiccup in the early alphas, it's been a very pleasant experience. Thanks to all involved, David On 23 Jul 2014, at 15:42, Baptiste Daroussin wrote: > Hi all, >=20 > I'm very please to announce the release of pkg 1.3.0 > This version is the result of almost 9 month of hard work >=20 > Here are the statistics for the version: > - 373 files changed, 66973 insertions(+), 38512 deletions(-) > - 29 different contributors >=20 > Please not that for the first time I'm not the main contributor, and I = would > like to particularly thanks Vsevold Stakhov for all the hard work he = has done to > allow us to get this release out. I would like also to give a special = thanks to > Andrej Zverev for the tons of hours spending on testing and cleaning = the bug > tracker! >=20 > So much has happened that it is hard to summarize so I'll try to = highlight the > major points: > - New solver, now pkg has a real SAT solver able to automatically = handle > conflicts and dynamically discover them. (yes pkg set -o is = deprecated now) > - pkg install now able to install local files as well and resolve = their > dependencies from the remote repositories > - Lots of parts of the code has been sandboxed > - Lots of rework to improve portability > - Package installation process has been reworked to be safer and = handle properly > the schg flags > - Important modification of the locking system for finer grain locks > - Massive usage of libucl > - Simplification of the API > - Lots of improvements on the UI to provide a better user experience. > - Lots of improvements in multi repository mode > - pkg audit code has been moved into the library > - pkg -o A=3DB that will overwrite configuration file from cli > - The ui now support long options > - The unicity of a package is not anymore origin > - Tons of bug fixes > - Tons of behaviours fixes > - Way more! >=20 > Thank you to all contributors: > Alberto Villa, Alexandre Perrin, Andrej Zverev, Antoine Brodin, Brad = Davis, > Bryan Drewery, Dag-Erling Sm=F8rgrav, Dmitry Marakasov, Elvira = Khabirova, Jamie > Landeg Jones, Jilles Tjoelker, John Marino, Julien Laffaye, Mathieu = Arnold, > Matthew Seaman, Maximilian Ga=DF, Michael Gehring, Michael Gmelin, = Nicolas Szalay, > Rodrigo Osorio, Roman Naumann, Rui Paulo, Sean Channel, Stanislav E. = Putrya, > Vsevolod Stakhov, Xin Li, coctic >=20 > Regards, > Bapt on behalf of the pkg@ From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 09:03:30 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 13FB2DFA for ; Thu, 24 Jul 2014 09:03:30 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8FE6C2766 for ; Thu, 24 Jul 2014 09:03:29 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s6O93PFA055631; Thu, 24 Jul 2014 11:03:25 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id E7258352A; Thu, 24 Jul 2014 11:03:24 +0200 (CEST) Message-ID: <53D0CBD6.1020708@omnilan.de> Date: Thu, 24 Jul 2014 11:03:18 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Rick Macklem Subject: Re: nfsd server cache flooded, try to increase nfsrc_floodlevel References: <1578548312.7148700.1375964458716.JavaMail.root@uoguelph.ca> In-Reply-To: <1578548312.7148700.1375964458716.JavaMail.root@uoguelph.ca> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD06AF3F8B028172AC0625C8B" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Thu, 24 Jul 2014 11:03:25 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 09:03:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD06AF3F8B028172AC0625C8B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bez=FCglich Rick Macklem's Nachricht vom 08.08.2013 14:20 (localtime): > Lars Eggert wrote: >> Hi, >> >> every few days or so, my -STABLE NFS server (v3 and v4) gets wedged >> with a ton of messages about "nfsd server cache flooded, try to >> increase nfsrc_floodlevel" in the log, and nfsstat shows TCPPeak at >> 16385. It requires a reboot to unwedge, restarting the server does >> not help. >> >> The clients are (mostly) six -CURRENT nfsv4 boxes that netboot from >> the server and mount all drives from there. >> >> I googled around and saw that others have hit this issue, but I >> haven't seen any resolution posted. I guess I can increase >> NFSRVCACHE_FLOODLEVEL in the source, but I wonder if I wouldn't >> simply hit the increase value after a little while longer... >> >> Lars >> > You can either try this patch (which dynamically adjusts nfsrc_floodlev= el > along with handling a variety of overhead issues for the DRC under heav= y load): > http://people.freebsd.org/~rmacklem/drc4.patch > > or just bump it up a bunch. The default value was safe for a server wit= h 256Mbytes > of ram and a default mbuf cluster limit. The only thing you might have = to do > along with bumping NFSRC_FLOODLEVEL up is increasing kern.ipc.mbcluster= s. > > The variant of the above patch will make it into head someday, once I m= erge > in changes from ivoras@'s similar patch and confer with him about it. Dear all, regarding the conversation from last year - quoted above, I think I found the mentioned patch (it's variants) MFCd in r255532 (from http://svnweb.freebsd.org/base?view=3Drevision&revision=3D25433= 7), so it's included in 9.3-RELEASE. Unfortunately I'm still having the nfsrc_floodlevel problem with OpenOwner=3D16385, CacheSize=3D16385 (in nfsstat -e -s) in my production environment under 9.3-RELEASE-amd64. Extremely light load on the server (2 (FreeBSD8/9) clients), but the building client (nfsv4) locks up frequently. It mounts 'home' and 'ports/ports' via NFSv4 (this time, 'make index' in nfs-mounted /usr/ports killed the nfsv4server). I found another interesting 3 years old patch/thread, which seems never beeing comitted: http://lists.freebsd.org/pipermail/freebsd-fs/2011-July/012016.html I don't really understand all these details of nfs(v4), but I observe problems with regular usage, so I wanted to ask if there are new findings regarding the "nfsd server cache flooded, try to increase nfsrc_floodlevel" messages (while 'nfsrc_floodlevel' doesn't seem to be tunable in 9.3). To my understanding, it's a problem on the server side, right? Is the fix from 3 years back still adequate (does apply with view offsets only to 9.3)? I'm currently testing 9.3-RELEASE+noopen.patch, but it usually took two or three days until the client locked up (hadn't looked for the reason before the last issue, nfs(v4) was brand new reintroduced here) Thanks, -Harry --------------enigD06AF3F8B028172AC0625C8B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlPQy9wACgkQLDqVQ9VXb8gMKgCgzU/4+e2vLZUR+G5uboU7wwxf B84An3tlgzhPO4yeVzWF/R3xSMdfsir5 =q94N -----END PGP SIGNATURE----- --------------enigD06AF3F8B028172AC0625C8B-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 11:46:28 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 942DC858 for ; Thu, 24 Jul 2014 11:46:28 +0000 (UTC) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6520F26B8 for ; Thu, 24 Jul 2014 11:46:28 +0000 (UTC) Received: by mail-ig0-f182.google.com with SMTP id c1so2556296igq.3 for ; Thu, 24 Jul 2014 04:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=7Uiww8vjki6XZh4XOvOLE4XcWMnkVqY4uaGtK16OvqM=; b=pbYn7c2ftBiaYF0uz0yLUcwFjErjqb4lvwtr2Tgr5ClYMcrBBJDdC1iXes2L/ZXWyF Uis6cKlnL8s9RRhCYtqe13kp0XiB8AnqpQcQirAZ4I2hM7WKmr8QDUKYvkYIv8AX8euL Bnz346/610aIBB/euB2bYNhawBI+jRArFgFgk0eLuVsb0Q6zd3zohHVPKhe40Okbm50a AQsG5E64OhKFetwfKA8sTx3xzze6bhwjBObHEG5J+9etPpuHDAN5kXbkaCEqCtJ+cCMU Z7gzM0QXHR++LGr3CXQGVekkYOkjIkmCE65nrkgu2MwrzFTNuKFEZ1iFBE8zX6NuwBtP a8KQ== MIME-Version: 1.0 X-Received: by 10.50.50.175 with SMTP id d15mr9236517igo.35.1406202387848; Thu, 24 Jul 2014 04:46:27 -0700 (PDT) Sender: vrwmiller@gmail.com Received: by 10.64.165.73 with HTTP; Thu, 24 Jul 2014 04:46:27 -0700 (PDT) Date: Thu, 24 Jul 2014 07:46:27 -0400 X-Google-Sender-Auth: cDvXpilfPLZrZOgUaKB4gzOLlm4 Message-ID: Subject: 8.x and virtio? From: Rick Miller To: "freebsd-stable@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 11:46:28 -0000 Hi all, Is there significant effort involved with merging the virtio code from a 9 or 10 branch into an 8 branch? Special considerations? -- Take care Rick Miller From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 12:25:08 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6952F349 for ; Thu, 24 Jul 2014 12:25:08 +0000 (UTC) Received: from ms7.sendsrv.com (ms7.sendsrv.com [198.143.175.227]) by mx1.freebsd.org (Postfix) with ESMTP id 275B92A5C for ; Thu, 24 Jul 2014 12:25:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=dkim.key; d=ss1.sendsrv.com; h=Date:To:From:Reply-to:Subject:Message-ID:List-Unsubscribe:MIME-Version:Content-Type; bh=MomuAZRgHS12XTveLuWlgcKwEjc=; b=VeBkHloxrklKZkkDDyhRUzjJuCN62FjOs/956y5mmAtDM58PCCj7w5EQduWLuMaFJ2r8uZuLzB3h oF0MgU/qh1t+e1QurryLaKmBurveYC4B7CzUlWPQvLgHwHZjtnNW6SO0+UOop4p7YStfKh76/J1l ybZwwQP0Qht/b3ckR/0= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=dkim.key; d=thecom.co.za; b=X+XaFWE9eLfU/zrZuPT/9NCq4mheB3alP2y1HpD7E0OWMVPct+ezmFu4j4aOEKxLRhpR+PtWslpH Wwr7EjDS5QUZXpwHbrrYjnY/6KKGr88nMaRNd6U9dFwW9gt3L20+ch0r/XW9QwP8F0ntXO3s3ILK El0zvJEIngGQk8Pql+Y=; Received: by ms7.sendsrv.com id hq3sf01g7g8l for ; Thu, 24 Jul 2014 12:05:36 +0000 (envelope-from ) Date: Thu, 24 Jul 2014 12:05:36 +0000 To: "freebsd-stable@freebsd.org" From: Merle Hull Reply-to: Merle Hull Subject: Get Your Message Across Confidently and Professionally Message-ID: <42378bbdc37530cb16e3c615e0e53d74@localhost.localdomain> X-Priority: 3 X-Mailer: Send Srv X-Complaints-To: complaints@ss1.sendsrv.com X-MessageID: 8oh-4757-ZnJlZWJzZC1zdGFibGVAZnJlZWJzZC5vcmc%3D-3vo-195-rs X-Report-Abuse: X-SMTPAPI: {"unique_args":{"abuse-id":"8oh-4757-ZnJlZWJzZC1zdGFibGVAZnJlZWJzZC5vcmc%3D-3vo-195-rs"}, "category":"campaign"} MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 12:25:08 -0000 Deliver a great presentation professionally! Confident Communications Workshop Professional Presentation skills, Public Speaking and Communication Workshop You will be presented with a before and after speech recording to watch your improvements. MIDRAND 27 & 28 AUGUST 2014 17 & 18 SEPTEMBER 2014 29 & 30 OCTOBER 2014 CAPE TOWN 6 & 7 AUGUST 2014 5 & 6 NOVEMBER 2014 PORT ELIZABETH 10 & 11 SEPTEMBER 2014 DURBAN 2 & 3 SEPTEMBER 2014 Year dates available on our website. BOOK NOW! REGISTER ONLINE NOW - [1]click here [cid:28b909011d5dad9e40a53fad55ea8cf8] HOW TO PRESENT - teaches the required skills to giving a successful presentation. [cid:c35180b61f46f658e3ed342b932a6ce8] CONFIDENT COMMUNICATION - teaches you to communicate amongst a group. [cid:7452cf1a5f1c8af98b0d733522019ebf] BODY LANGUAGE IN COMMUNICATION - teaches you tone, eye contact and language skills. [cid:14c3d706115ac716cf51b8b84c9449b5] Presenting with confidence and effective public speaking skills training: The purpose of this two-day training course is to teach the delegates the skills required for giving a confident and successful presentation. Focusing on how we present our thoughts, perceptions and ideas in retrospect to what we present. The course looks at the following aspects of speech training: * Making a good first impression. * How to appear professional and confident when speaking. * Using the voice correctly when speaking * Overcoming nerves when speaking * How to write a speech / Presentation. * The importance of eye contact and gestures when speaking * Thinking on your feet * Impromptu speeches; prepared speeches and sight-reading * How to prepare for a presentation. * Pronunciation problems will be pointed out, and corrective exercises given. Workshop Details: [cid:5c70d6dd0a59756f2aca7a1f93d47140] Time: 09h00 to 16h00 Venue: Midrand - Pheasant Hill House Cape Town - Best Western Cape suites Durban - to be advised Cost: R 5490.00 (Excluding VAT) * The delegates will also be presented with an audio training CD that is included in the workshop price. "What a wonderful workshop, and for a change a workshop has delivered on what it promised." - Multichoice Other clients include: [cid:08550893c6b2de6504dbc23fc04965e2] [cid:64004eedc834472c22f95592e6c99044] REGISTER ONLINE NOW - [2]click here VISIT OUR WEBPAGE - [3]click here The number one thing that stops a person listening is boredom. Hold your audience with your use of voice and body language. Group Discount: [cid:cd2ec77b5525559d602bf768ac12ab6d] Send 3 delegates and receive a 5% Discount Send 4 delegates and receive a 10 % Discount Send 5 or more and receive a 15 % Discount. All delegates must attend the same workshop. IN-HOUSE WORKSHOPS AVAILABLE FOR 10 OR MORE STAFF @ YOUR VENUE! ----------------------------------------------------------------------- ----------------------------------------------------------------------- --------------------------------- NEW!!! EXCITING NEW WORKSHOP !!!! Professional Conduct in the Workplace One Day Workshop Are your staff destroying your brand? If your company employees act unprofessionally don't expect to be seen as a professional organisation. Be it the result of the new world or new generation, professional business conduct just isn't what it used to be. Finally a workshop to teach your staff what professional business conduct entails and where they are going wrong. A One-Day Workshop Professional conduct in the workplace training. MIDRAND 29 August 2014 CAPE TOWN 8 August 2014 DURBAN 4 September 2014 BOOK NOW! REGISTER ONLINE NOW - [4]click here Workshop will address these issues: * How you conduct business calls * Business emails * How to present yourself * Facebook conduct * LinkedIn profile * Is it okay to SMS a client? * Keeping company and personal problems under wraps * Dealing professionally with colleagues and clients * Presenting a professional image * The negative impact of tardiness and arriving unprepared * Undelivered promises - a business killer * Accepting authority * Socialising with clients * Familiarity breeds contempt although rapport is essential - find the balance * Do's and Don'ts of professionalism Workshop Details: Time: 09h00 to 16h00 Venues: Midrand - Pheasant Hill House Cape Town - Best Western Cape suites Durban - to be advised Cost: R 2500.00 (Excluding VAT) per person * The delegates will also be presented with an audio training CD that is included in the workshop price. If you attend any of the Confident Communication Workshops advertised above and book for Professional Conduct Workshop, you will receive a 10 % discount for the Professional Conduct Workshop. ----------------------------------------------------------------------- ----------------------------------------------------------------------- --------------------------------- Contact Us: [cid:4f9a77f3f26a28a055e1d763ca216a43] Tel: 086 111 6121 Cell:083 651 8855 [5]www.thecommunicationacademy.co.za [6]merle@thecommunicationacademy.co.za [7]sales@thecommunicationaca demy.co.za IF YOU WISH TO UNSUBSCRIBE, CLICK [8]HERE [cid:f6db30f29895f62ca3cac5870bc16c54] We also offer training on: Professional Conduct In The Workplace; Call Centre Training; Customer Service and Individual Voice Training. Visit our website more details, published articles; radio and television interviews. ----------------------------------------------------------------------- ----------------------------------------------------------------------- --------------------------------- . References 1. http://cp.sendsrv.com/tl.php?p=8oh/7cr/rs/4757/3vo/rs//http%3A%2F%2Fwww.thecommunicationacademy.co.za%2Fonline-communication-registration.html 2. http://cp.sendsrv.com/tl.php?p=8oh/7cr/rs/4757/3vo/rs//http%3A%2F%2Fwww.thecommunicationacademy.co.za%2Fonline-communication-registration.html 3. http://cp.sendsrv.com/tl.php?p=8oh/7cr/rs/4757/3vo/rs//http%3A%2F%2Fwww.thecommunicationacademy.co.za%2Findex.html 4. http://cp.sendsrv.com/tl.php?p=8oh/7cr/rs/4757/3vo/rs//http%3A%2F%2Fwww.thecommunicationacademy.co.za%2FProfessional-Conduct-in-the-Workplace.html 5. http://cp.sendsrv.com/tl.php?p=8oh/7cr/rs/4757/3vo/rs//http%3A%2F%2Fwww.thecommunicationacademy.co.za%2F 6. mailto:merle@thecommunicationacademy.co.za 7. mailto:sales@thecommunicationacademy.co.za 8. http://cp.sendsrv.com/u.php?p=8oh/rs/4757/3vo/7cr/rs From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 12:28:59 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 91941573 for ; Thu, 24 Jul 2014 12:28:59 +0000 (UTC) Received: from smtp.unix-experience.fr (unix-experience.fr [88.191.192.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 57D772A9D for ; Thu, 24 Jul 2014 12:28:59 +0000 (UTC) Received: from iMac-LBlot (unknown [129.175.196.159]) by smtp.unix-experience.fr (Postfix) with ESMTPSA id 493F939F00 for ; Thu, 24 Jul 2014 14:17:14 +0200 (CEST) Message-ID: <1406204364.28678.2.camel@unix-experience.fr> Subject: Re: [ANNOUNCEMENT] pkg 1.3.0 out! From: =?ISO-8859-1?Q?Lo=EFc?= Blot Reply-To: loic.blot@unix-experience.fr To: freebsd-stable@freebsd.org Date: Thu, 24 Jul 2014 14:19:24 +0200 In-Reply-To: <20140723144249.GD69907@ivaldir.etoilebsd.net> References: <20140723144249.GD69907@ivaldir.etoilebsd.net> Organization: UNIX Experience FR Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.4 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 12:28:59 -0000 Hi, Great work @pkg-devs ! Tested on ~30 servers with different roles (mail, web, services...) and different FreeBSD versions (9.1,9.2,9.3,10.0) and no warning problem noticed (each servers needed ~30 package updates). Only a little problem with roundcube (pkg wants to remove it, but i upgraded all other packages before and the problem disappear). -- Best regards, Loïc BLOT, Engineering UNIX Systems, Security and Network Engineer http://www.unix-experience.fr Le mercredi 23 juillet 2014 à 16:42 +0200, Baptiste Daroussin a écrit : > Hi all, > > I'm very please to announce the release of pkg 1.3.0 > This version is the result of almost 9 month of hard work > > Here are the statistics for the version: > - 373 files changed, 66973 insertions(+), 38512 deletions(-) > - 29 different contributors > > Please not that for the first time I'm not the main contributor, and I would > like to particularly thanks Vsevold Stakhov for all the hard work he has done to > allow us to get this release out. I would like also to give a special thanks to > Andrej Zverev for the tons of hours spending on testing and cleaning the bug > tracker! > > So much has happened that it is hard to summarize so I'll try to highlight the > major points: > - New solver, now pkg has a real SAT solver able to automatically handle > conflicts and dynamically discover them. (yes pkg set -o is deprecated now) > - pkg install now able to install local files as well and resolve their > dependencies from the remote repositories > - Lots of parts of the code has been sandboxed > - Lots of rework to improve portability > - Package installation process has been reworked to be safer and handle properly > the schg flags > - Important modification of the locking system for finer grain locks > - Massive usage of libucl > - Simplification of the API > - Lots of improvements on the UI to provide a better user experience. > - Lots of improvements in multi repository mode > - pkg audit code has been moved into the library > - pkg -o A=B that will overwrite configuration file from cli > - The ui now support long options > - The unicity of a package is not anymore origin > - Tons of bug fixes > - Tons of behaviours fixes > - Way more! > > Thank you to all contributors: > Alberto Villa, Alexandre Perrin, Andrej Zverev, Antoine Brodin, Brad Davis, > Bryan Drewery, Dag-Erling Smørgrav, Dmitry Marakasov, Elvira Khabirova, Jamie > Landeg Jones, Jilles Tjoelker, John Marino, Julien Laffaye, Mathieu Arnold, > Matthew Seaman, Maximilian Gaß, Michael Gehring, Michael Gmelin, Nicolas Szalay, > Rodrigo Osorio, Roman Naumann, Rui Paulo, Sean Channel, Stanislav E. Putrya, > Vsevolod Stakhov, Xin Li, coctic > > Regards, > Bapt on behalf of the pkg@ From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 14:34:44 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32A83973 for ; Thu, 24 Jul 2014 14:34:44 +0000 (UTC) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0068C263C for ; Thu, 24 Jul 2014 14:34:43 +0000 (UTC) Received: by mail-ig0-f172.google.com with SMTP id h15so6520379igd.17 for ; Thu, 24 Jul 2014 07:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=GztWXEgBUWQ5+v6dCuvHZ8RtTe6qdqLHI5+c6pLivQI=; b=vbbn2xxFM1mqEW0Ka9nTNWAXiGM/dAZkgeycRfzr+28yVY1RLxhIY7OHPlBdiDf6qu HUyGfpXU5tOEF7Xe2qWQM5ymCUfg6a1eMZx3RbIee+7Q+OMzig0k1SlIi6leNSLhKqZW 3x/z96lBV6rTLRKF8+FOj9mYUY7iP+P60/lI8C86LLwOvwDZTPF7L8+PyhXnAC1SKjAn EP8giNPadCJGtWGOa+TyneXBA7WmJoQiYKpaVgWCDEAxPH3AflPN71hotY1j+mtUB4hy 7h0J+dSm5HhTTnes4QbAyhoGeu8xfe9WBwy6MecEV4dXoc2N5Mcz+EiikiL4J/bigX7d WRoA== MIME-Version: 1.0 X-Received: by 10.42.80.7 with SMTP id t7mr13239525ick.9.1406212482940; Thu, 24 Jul 2014 07:34:42 -0700 (PDT) Sender: vrwmiller@gmail.com Received: by 10.64.165.73 with HTTP; Thu, 24 Jul 2014 07:34:42 -0700 (PDT) In-Reply-To: <000C2F50-A6F8-48A6-973C-68C4C28F1C71@inoc.net> References: <000C2F50-A6F8-48A6-973C-68C4C28F1C71@inoc.net> Date: Thu, 24 Jul 2014 10:34:42 -0400 X-Google-Sender-Auth: sU0b1R2Svyre9AwwJfmjd1zIUHY Message-ID: Subject: Re: 8.x and virtio? From: Rick Miller To: Robert Blayzor Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 14:34:44 -0000 On Thu, Jul 24, 2014 at 10:18 AM, Robert Blayzor wrote: > On Jul 24, 2014, at 7:46 AM, Rick Miller wrote: > > > > Is there significant effort involved with merging the virtio code from a > 9 > > or 10 branch into an 8 branch? Special considerations? > > > Unless you're hoping for an 8.5 release, which is unlikely, I'd expect not. > > The path of least resistance is to upgrade. > I don't expect the community to take this up. I'm most interested in the level of effort to do so internally if we were so inclined. Would it be a simple merge of the code from any 9 or 10 branch into a private, internal 8 branch or is it a more complicated process requiring a multitude of considerations? -- Take care Rick Miller From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 14:35:18 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89005A69 for ; Thu, 24 Jul 2014 14:35:18 +0000 (UTC) Received: from mail3.albyny.inoc.net (mail3.albyny.inoc.net [64.22.32.73]) by mx1.freebsd.org (Postfix) with ESMTP id 1C79C2650 for ; Thu, 24 Jul 2014 14:35:17 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=inoc.net; h=Received:Subject:From:Date:To; b=YiOQXux/08Ugpqgewv3lFWV6a9zYGq8XH0msVX8LT8/WeJpTFXxlZq459VBL4gdHkNHAhMPh4S+OjCJg1TmysIHiXmCetb8yC4qhyFdyzJ/8O+DFzHdSUce0etren1piq/Y/KhNC+cjKbVLG8v2EqOQ+k5YQ03sI8U7C5SJLwv4=; X-Default-Received-SPF: pass (skip=loggedin (res=PASS)); Received: from void.ops.inoc.net (catbox.noc.albyny.inoc.net [64.246.135.7]) by mail3.albyny.inoc.net (build v14.0.10) with ESMTP id 11324721-1941382 for multiple; Thu, 24 Jul 2014 14:18:49 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: 8.x and virtio? From: Robert Blayzor In-Reply-To: Date: Thu, 24 Jul 2014 10:18:56 -0400 Content-Transfer-Encoding: 7bit Message-Id: <000C2F50-A6F8-48A6-973C-68C4C28F1C71@inoc.net> References: To: Rick Miller X-Mailer: Apple Mail (2.1878.6) X-Authenticated-User: rblayzor@inoc.net Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 14:35:18 -0000 On Jul 24, 2014, at 7:46 AM, Rick Miller wrote: > > Is there significant effort involved with merging the virtio code from a 9 > or 10 branch into an 8 branch? Special considerations? Unless you're hoping for an 8.5 release, which is unlikely, I'd expect not. The path of least resistance is to upgrade. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 15:42:53 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25875907 for ; Thu, 24 Jul 2014 15:42:53 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A50EC2D25 for ; Thu, 24 Jul 2014 15:42:52 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s6OFgnGG059178 for ; Thu, 24 Jul 2014 17:42:49 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id D625735AB; Thu, 24 Jul 2014 17:42:48 +0200 (CEST) Message-ID: <53D12973.3010805@omnilan.de> Date: Thu, 24 Jul 2014 17:42:43 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: FreeBSD Stable Subject: panic/lock on 9.3-RELEASE with nullfs/nfs/zfs combination X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF04409624E2E22C51E3A1683" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Thu, 24 Jul 2014 17:42:49 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 15:42:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF04409624E2E22C51E3A1683 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I'm running 9.3-amd64 with some zfilesystems and a jail. One zfilesystem is nullfs_mounted into jail. Now I can export (nfsv4) that nullfs_mounted filesystem and rw-opening a file inside the jail from the nullfs_mounted fs works, until a client walks into nfs_mounted filesystem (just listing directory contents e.g.).= So mount shows like this: tank/my/fs15 mounted on /zfs/netshares/fs15 (zfs, NFS exported, local, noatime, noexec, nosuid, nfsv4acls) /zfs/netshares/fs15 on /.JAIL/usr/ports (nullfs, local) When I the try to open a file (rw) inside the jail from the nullfs_mounted filesystem, 9.3-RELEASE blocks any IO completely on that filesystem (local or remote), with debug-kernel I get the following panic on the nfs/jail server: panic: LK_RETRY set with incompatible flags (0x200400) or an error occured (11) cpuid =3D 3 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xffffff82e54bcc70 kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff82e54bcd30 panic() at panic+0x1cd/frame 0xffffff82e54bce30 _vn_lock() at _vn_lock+0x67/frame 0xffffff82e54bce90 zfs_lookup() at zfs_lookup+0x420/frame 0xffffff82e54bcf20 zfs_freebsd_lookup() at zfs_freebsd_lookup+0xa6/frame 0xffffff82e54bd070 VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xd8/frame 0xffffff82e54bd= 0a0 vfs_cache_lookup() at vfs_cache_lookup+0xff/frame 0xffffff82e54bd110 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xd8/frame 0xffffff82e54bd140 null_lookup() at null_lookup+0x92/frame 0xffffff82e54bd1c0 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xd8/frame 0xffffff82e54bd1f0 lookup() at lookup+0x389/frame 0xffffff82e54bd290 namei() at namei+0x3df/frame 0xffffff82e54bd340 vn_open_cred() at vn_open_cred+0x1e2/frame 0xffffff82e54bd4b0 vop_stdvptocnp() at vop_stdvptocnp+0x1af/frame 0xffffff82e54bd7e0 null_vptocnp() at null_vptocnp+0xf5/frame 0xffffff82e54bd850 VOP_VPTOCNP_APV() at VOP_VPTOCNP_APV+0xdb/frame 0xffffff82e54bd880 vn_vptocnp_locked() at vn_vptocnp_locked+0x15b/frame 0xffffff82e54bd910 vn_fullpath1() at vn_fullpath1+0x100/frame 0xffffff82e54bd970 kern___getcwd() at kern___getcwd+0xd4/frame 0xffffff82e54bd9d0 amd64_syscall() at amd64_syscall+0x318/frame 0xffffff82e54bdaf0 Xfast_syscall() at Xfast_syscall+0xf7/frame 0xffffff82e54bdaf0 --- syscall (326, FreeBSD ELF64, sys___getcwd), rip =3D 0x8011a191c, rsp = =3D 0x7fffffffe658, rbp =3D 0x801873400 --- KDB: enter: panic [ thread pid 1905 tid 100856 ] Stopped at kdb_enter+0x3b: movq $0,0x642172(%rip) Like mentioned, this panic happens only if a nfs(v4) client visits fs15 (the exported and nullfs_mounted fs) and I try to rw-open any file on the nullfs afterwards!!! How can I provide useful info with KDB? I don't have a dumpdev available in that machine=E2=80=A6 http://www.es.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gd= b.html seems not applicaple, no /var/crash/?*=E2=80=A6 Thanks for help, -Harry --------------enigF04409624E2E22C51E3A1683 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlPRKXgACgkQLDqVQ9VXb8ghsQCfRskOwW788OhLnP8yyb7WcAdJ +E0AoL0nAb8Y2gEZychEPV32xlNyAn4s =MUMJ -----END PGP SIGNATURE----- --------------enigF04409624E2E22C51E3A1683-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 15:45:54 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 202ACA4B for ; Thu, 24 Jul 2014 15:45:54 +0000 (UTC) Received: from olgeni.olgeni.com (host-156-246-171-31.cloudsigma.com [31.171.246.156]) by mx1.freebsd.org (Postfix) with ESMTP id D95562D7A for ; Thu, 24 Jul 2014 15:45:53 +0000 (UTC) Received: from [10.0.2.15] (unknown [5.8.101.242]) by olgeni.olgeni.com (Postfix) with ESMTPSA id B0E2E1745E4 for ; Thu, 24 Jul 2014 17:45:45 +0200 (CEST) Date: Thu, 24 Jul 2014 17:45:44 +0200 (CEST) From: Jimmy Olgeni X-X-Sender: olgeni@backoffice To: freebsd-stable@FreeBSD.org Subject: link_elf_obj: symbol icl_pdu_new_bhs undefined Message-ID: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) X-OpenPGP-KeyID: 0x90B7A98E6450AE47 X-OpenPGP-Fingerprint: 7133 AB4D DFC8 0A0D F891 B0D2 90B7 A98E 6450 AE47 X-OpenPGP-URL: http://olgeni.olgeni.com/~olgeni/pgp/olgeni@olgeni.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 15:45:54 -0000 Hi, Is anybody seeing anything like this on recent stable/10? $ sudo service ctld restart ctld not running? (check /var/run/ctld.pid). kldload: an error occurred while loading the module. Please check dmesg(8) for more details. /etc/rc.d/ctld: WARNING: Unable to load kernel module ctl /etc/rc.d/ctld: WARNING: failed precmd routine for ctld $ dmesg [...] link_elf_obj: symbol icl_pdu_new_bhs undefined linker_load_file: Unsupported file type -- jimmy From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 15:55:40 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7519F3B1 for ; Thu, 24 Jul 2014 15:55:40 +0000 (UTC) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "asuka.mahoroba.org", Issuer "ca.mahoroba.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F7CB2EA3 for ; Thu, 24 Jul 2014 15:55:39 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:7258:12ff:fe22:d94b]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.9/8.14.9) with ESMTP/inet6 id s6OFtQpq050832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 25 Jul 2014 00:55:32 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Fri, 25 Jul 2014 00:54:56 +0900 Message-ID: From: Hajimu UMEMOTO To: Rick Miller Subject: Re: 8.x and virtio? In-Reply-To: References: User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) Emacs/24.3 Mule/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 9.3-STABLE X-PGP-Key: http://www.mahoroba.org/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Fri, 25 Jul 2014 00:55:33 +0900 (JST) X-Virus-Scanned: clamav-milter 0.98.4 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on asuka.mahoroba.org Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 15:55:40 -0000 Hi, >>>>> On Thu, 24 Jul 2014 07:46:27 -0400 >>>>> Rick Miller said: vmiller> Is there significant effort involved with merging the virtio code from a 9 vmiller> or 10 branch into an 8 branch? Special considerations? How about using ports/emulators/virtio-kmod? Sincerely, -- Hajimu UMEMOTO ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.mahoroba.org/~ume/ From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 16:06:48 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C86D8C6 for ; Thu, 24 Jul 2014 16:06:48 +0000 (UTC) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 45C002FBC for ; Thu, 24 Jul 2014 16:06:47 +0000 (UTC) Received: by mail-vc0-f169.google.com with SMTP id hu12so5364610vcb.14 for ; Thu, 24 Jul 2014 09:06:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ywvz2xkn9cpTxDeFWi2rgratX7wAeRw/H2oHUihD6zA=; b=lDzrBmSPjg55pnN62yo5XQVK6PZrgfaHxjcAO2PARj7T40XhSp7PxZazyIDA4dPmLw COEHY0nusrmzvg1mkaKjbhyGLY9SXtlELALo4ukd0g1EnOrx9yghvoJySa4mBoYs5W8/ CCChVPHQ3bh+R1Tw0zp4mF8OH5eNklKqWkn+AaozseJ40Rc8ITZKG+eMLjrnoavzh7GB S4GBx/F1k5fLW/V7DNYgLnDH5hQ4tIYFA3N9Tjb7btN1lPjCMK8886rplVzkfrAH862+ KAUiWrN6pjOjQJ+ellZM/cfXuL6Wa/TeZS4vyuctxekAtzxV7XT3ANDMiNTDtKGtnxWm JeBA== X-Gm-Message-State: ALoCoQkCFF40YrHo1+WMR6DqZZHu8b/dlc9SZVLlFHa5G2LkGMlzpxkZn606+nFthIu8D9oHu4aU X-Received: by 10.220.133.13 with SMTP id d13mr13782809vct.66.1406218006404; Thu, 24 Jul 2014 09:06:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.33.131 with HTTP; Thu, 24 Jul 2014 09:06:26 -0700 (PDT) X-Originating-IP: [216.240.30.23] In-Reply-To: References: <000C2F50-A6F8-48A6-973C-68C4C28F1C71@inoc.net> From: Bryan Venteicher Date: Thu, 24 Jul 2014 11:06:26 -0500 Message-ID: Subject: Re: 8.x and virtio? To: Rick Miller Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-stable@freebsd.org" , Robert Blayzor X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 16:06:48 -0000 On Thu, Jul 24, 2014 at 9:34 AM, Rick Miller wrote: > On Thu, Jul 24, 2014 at 10:18 AM, Robert Blayzor > wrote: > > > On Jul 24, 2014, at 7:46 AM, Rick Miller > wrote: > > > > > > Is there significant effort involved with merging the virtio code fro= m > a > > 9 > > > or 10 branch into an 8 branch? Special considerations? > > > > > > Unless you're hoping for an 8.5 release, which is unlikely, I'd expect > not. > > > > The path of least resistance is to upgrade. > > > > I don't expect the community to take this up. I'm most interested in the > level of effort to do so internally if we were so inclined. Would it be = a > simple merge of the code from any 9 or 10 branch into a private, internal= 8 > branch or is it a more complicated process requiring a multitude of > considerations? > > =E2=80=8BAssuming you're close to 8-STABLE, I'd expect it not to be too muc= h to work to run newer VirtIO code. There's several changes that I still need to MFC to 9, since it was in a freeze for the 9.3 release when I was MFC'ing to 10. I should get that done in the next few weeks. Due to pending EOL and my limited time, I've stopped MFC'ing new features to 8. I'm not aware of any bugs=E2=80=8B in the 8-STABLE code though. > -- > Take care > Rick Miller > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 16:59:23 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3009B3A3 for ; Thu, 24 Jul 2014 16:59:23 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C477324DF for ; Thu, 24 Jul 2014 16:59:22 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s6OGxHvf098999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2014 19:59:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s6OGxHvf098999 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s6OGxHiO098998; Thu, 24 Jul 2014 19:59:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 24 Jul 2014 19:59:17 +0300 From: Konstantin Belousov To: Harald Schmalzbauer Subject: Re: panic/lock on 9.3-RELEASE with nullfs/nfs/zfs combination Message-ID: <20140724165917.GT93733@kib.kiev.ua> References: <53D12973.3010805@omnilan.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5uA32zzA1LfAcUy7" Content-Disposition: inline In-Reply-To: <53D12973.3010805@omnilan.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 16:59:23 -0000 --5uA32zzA1LfAcUy7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 24, 2014 at 05:42:43PM +0200, Harald Schmalzbauer wrote: > Hello, >=20 > I'm running 9.3-amd64 with some zfilesystems and a jail. >=20 > One zfilesystem is nullfs_mounted into jail. >=20 > Now I can export (nfsv4) that nullfs_mounted filesystem and rw-opening a > file inside the jail from the nullfs_mounted fs works, until a client > walks into nfs_mounted filesystem (just listing directory contents e.g.). > So mount shows like this: >=20 > tank/my/fs15 mounted on /zfs/netshares/fs15 (zfs, NFS exported, local, > noatime, noexec, nosuid, nfsv4acls) > /zfs/netshares/fs15 on /.JAIL/usr/ports (nullfs, local) >=20 >=20 > When I the try to open a file (rw) inside the jail from the > nullfs_mounted filesystem, 9.3-RELEASE blocks any IO completely on that > filesystem (local or remote), > with debug-kernel I get the following panic on the nfs/jail server: >=20 > panic: LK_RETRY set with incompatible flags (0x200400) or an error > occured (11) > cpuid =3D 3 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame > 0xffffff82e54bcc70 > kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff82e54bcd30 > panic() at panic+0x1cd/frame 0xffffff82e54bce30 > _vn_lock() at _vn_lock+0x67/frame 0xffffff82e54bce90 > zfs_lookup() at zfs_lookup+0x420/frame 0xffffff82e54bcf20 > zfs_freebsd_lookup() at zfs_freebsd_lookup+0xa6/frame 0xffffff82e54bd070 > VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xd8/frame 0xffffff82e54bd= 0a0 > vfs_cache_lookup() at vfs_cache_lookup+0xff/frame 0xffffff82e54bd110 > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xd8/frame 0xffffff82e54bd140 > null_lookup() at null_lookup+0x92/frame 0xffffff82e54bd1c0 > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xd8/frame 0xffffff82e54bd1f0 > lookup() at lookup+0x389/frame 0xffffff82e54bd290 > namei() at namei+0x3df/frame 0xffffff82e54bd340 > vn_open_cred() at vn_open_cred+0x1e2/frame 0xffffff82e54bd4b0 > vop_stdvptocnp() at vop_stdvptocnp+0x1af/frame 0xffffff82e54bd7e0 > null_vptocnp() at null_vptocnp+0xf5/frame 0xffffff82e54bd850 > VOP_VPTOCNP_APV() at VOP_VPTOCNP_APV+0xdb/frame 0xffffff82e54bd880 > vn_vptocnp_locked() at vn_vptocnp_locked+0x15b/frame 0xffffff82e54bd910 > vn_fullpath1() at vn_fullpath1+0x100/frame 0xffffff82e54bd970 > kern___getcwd() at kern___getcwd+0xd4/frame 0xffffff82e54bd9d0 > amd64_syscall() at amd64_syscall+0x318/frame 0xffffff82e54bdaf0 > Xfast_syscall() at Xfast_syscall+0xf7/frame 0xffffff82e54bdaf0 > --- syscall (326, FreeBSD ELF64, sys___getcwd), rip =3D 0x8011a191c, rsp = =3D > 0x7fffffffe658, rbp =3D 0x801873400 --- > KDB: enter: panic > [ thread pid 1905 tid 100856 ] > Stopped at kdb_enter+0x3b: movq $0,0x642172(%rip) >=20 > Like mentioned, this panic happens only if a nfs(v4) client visits fs15 > (the exported and nullfs_mounted fs) and I try to rw-open any file on > the nullfs afterwards!!! >=20 > How can I provide useful info with KDB? I don't have a dumpdev available > in that machine??? > http://www.es.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gd= b.html > seems not applicaple, no /var/crash/?*??? >=20 The lockmgr flags are LK_SHARE | LK_RETRY, and error 11 =3D=3D EDEADLK indicates that the lock is already taken by the curthread in the exclusive mode. I am interested in what line of code did the locking. Add ddb, INVARIANTS, WITNESS and DEBUG_VFS_LOCKS options to the kernel config, reproduce the issue and, after the panic occured and you get at the ddb prompt, issue command 'show alllocks'. Also, do 'show mount', after which do 'show mount ', where is the address of your nullfs mount point, printed by 'show mount'. I need all console output starting from the panic message. --5uA32zzA1LfAcUy7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT0TtkAAoJEJDCuSvBvK1BPGwQAJR3iPL2kEuPZzojmUwI4Hem xuULE5t+LhdfiueSrkn4t9Pxh67umQA2CKffyPOeWrdWoUjgINFxWuccwfFBVuoz mWDVrLlrxQFLPZeIKRhYKEhNGueZWkVych0YzRF/yQu4Yl9KBkfpt/FeHB8g/Sfy ZHkV93dLKIRoIaPOEXla79S9f/xUrLakXsjNa/HxfDunQqO2bZbCbSBX3oQr1NgL VcBOXyMaJtPRSKhYNAtPvDNfLnHK4wyVHZsEApCv/IprNvH8eBVcKrgHr0hnZrwT RXT4g1kdOJi+n8NPQhNMb9hv6mz8X3GFmeGFbalhRdWuCX2r5UgXYq0NpkXCSOG1 h+zdfdDvwnk4BEUUEhQv2lqvZyRQjv99c3Rl1K66AVMMY+G32QQewzZctug8AYnD +w5I3OFspO2V/i4VulAL0wB7BA2E2hw/Is6qc+pBIM5w1c3W9RtHGdZulVTsBRAU oLq8llSv86zIboXOf1QH5pJz/aJb+aPVI3MjLNJmMk98mEdq4SSgfXeQsbWZ5pO9 AG+jYL5BM9inLhSviA7FIAi85suO85dOIM8FVv5rxy/0IIj9/Ig9vaZQ3oEmr6RE aB7WCZbnQHz3Sbv+26rMUvNbcE8S1e7F5exZzbWTlE+uBkly/M9dFBzWKaPZTnJX Vi/G9gYs0csBEn9OygPb =K3KI -----END PGP SIGNATURE----- --5uA32zzA1LfAcUy7-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 17:15:40 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 92898915 for ; Thu, 24 Jul 2014 17:15:40 +0000 (UTC) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 14E582680 for ; Thu, 24 Jul 2014 17:15:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id s6OHFUBi017946 for ; Thu, 24 Jul 2014 21:15:30 +0400 (MSK) (envelope-from marck@rinet.ru) Date: Thu, 24 Jul 2014 21:15:30 +0400 (MSK) From: Dmitry Morozovsky To: freebsd-stable@FreeBSD.org Subject: restore: bad block size 5632 between different major versions Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Thu, 24 Jul 2014 21:15:30 +0400 (MSK) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 17:15:40 -0000 Colleagues, I'm a bit stumbled. prerequisites: - backup server, stable/9 (a bit obsoleted, but this is unrelated to the problem) - bunch of servers of different branches, using UFS, backing 'em up with /sbin/dump over ssh for at least one pair, I have misterious situation: restore can work on the own base, but not on backup server, even (!) USING their own /rescue/restore: ** on backup server: backup@whale:/B/dump/lion> uname -r 9.1-STABLE backup@whale:/B/dump/lion> cat 5-var.dgz.?? | zcat | ./restore -t -v -f - Verify tape and initialize maps Dump date: Thu Jul 24 06:57:04 2014 Dumped from: Wed Jul 23 06:57:04 2014 Level 5 dump of /var on lion.rinet.ru:/dev/da0e Label: none bad block size 5632 ** on original machine, copied backup file there: root@lion:~backup# uname -r 7.2-RELEASE-p3 root@lion:~backup# cat 5-var.dgz.?? | zcat | restore -t -v -f - | head Level 5 dump of /var on lion.rinet.ru:/dev/da0e Label: none Verify tape and initialize maps Dump date: Thu Jul 24 06:57:04 2014 Dumped from: Wed Jul 23 06:57:04 2014 Extract directories from tape Initialize symbol table. dir 2 . dir 3 ./.snap dir 1860608 ./backups dir 1860613 ./backups/mysql dir 1978368 ./backups/mysql/trf ** copied /rescue/restore from lion to whale, placing it at rescue7: backup@whale:/B/dump/lion> cat 5-var.dgz.?? | zcat | /rescue7/restore -t -v -f - Verify tape and initialize maps Dump date: Thu Jul 24 06:57:04 2014 Dumped from: Wed Jul 23 06:57:04 2014 Level 5 dump of /var on lion.rinet.ru:/dev/da0e Label: none bad block size 5632 WHAT?! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 18:28:17 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E8A435F for ; Thu, 24 Jul 2014 18:28:17 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 829C3274F for ; Thu, 24 Jul 2014 18:28:15 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s6OISDY0060449; Thu, 24 Jul 2014 20:28:13 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 72EF335E8; Thu, 24 Jul 2014 20:28:12 +0200 (CEST) Message-ID: <53D1503B.2030200@omnilan.de> Date: Thu, 24 Jul 2014 20:28:11 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: panic/lock on 9.3-RELEASE with nullfs/nfs/zfs combination References: <53D12973.3010805@omnilan.de> <20140724165917.GT93733@kib.kiev.ua> In-Reply-To: <20140724165917.GT93733@kib.kiev.ua> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3847833F22ECB7596420720E" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Thu, 24 Jul 2014 20:28:13 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:28:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3847833F22ECB7596420720E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Konstantin Belousov's Nachricht vom 24.07.2014 18:59 (localtime): > =E2=80=A6 > The lockmgr flags are LK_SHARE | LK_RETRY, and error 11 =3D=3D EDEADLK > indicates that the lock is already taken by the curthread in the > exclusive mode. I am interested in what line of code did the locking. > > Add ddb, INVARIANTS, WITNESS and DEBUG_VFS_LOCKS options to the kernel > config, reproduce the issue and, after the panic occured and you > get at the ddb prompt, issue command 'show alllocks'. > > Also, do 'show mount', after which do 'show mount ', where = > is the address of your nullfs mount point, printed by 'show mount'. > > I need all console output starting from the panic message. FreeBSD/amd64 (mira.inop.mo1.omnilan.net) (ttyu0) login: panic: LK_RETRY set with incompatible flags (0x200400) or an error occured (11) cpuid =3D 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xffffff82e565fc70 kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff82e565fd30 panic() at panic+0x1cd/frame 0xffffff82e565fe30 _vn_lock() at _vn_lock+0x77/frame 0xffffff82e565fe90 zfs_lookup() at zfs_lookup+0x420/frame 0xffffff82e565ff20 zfs_freebsd_lookup() at zfs_freebsd_lookup+0xa6/frame 0xffffff82e5660070 VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0x102/frame 0xffffff82e56600a0 vfs_cache_lookup() at vfs_cache_lookup+0xff/frame 0xffffff82e5660110 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x102/frame 0xffffff82e5660140 null_lookup() at null_lookup+0x92/frame 0xffffff82e56601c0 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x102/frame 0xffffff82e56601f0 lookup() at lookup+0x32f/frame 0xffffff82e5660290 namei() at namei+0x3df/frame 0xffffff82e5660340 vn_open_cred() at vn_open_cred+0x1e2/frame 0xffffff82e56604b0 vop_stdvptocnp() at vop_stdvptocnp+0x1af/frame 0xffffff82e56607e0 null_vptocnp() at null_vptocnp+0xf5/frame 0xffffff82e5660850 VOP_VPTOCNP_APV() at VOP_VPTOCNP_APV+0x105/frame 0xffffff82e5660880 vn_vptocnp_locked() at vn_vptocnp_locked+0x15b/frame 0xffffff82e5660910 vn_fullpath1() at vn_fullpath1+0x100/frame 0xffffff82e5660970 kern___getcwd() at kern___getcwd+0xd4/frame 0xffffff82e56609d0 amd64_syscall() at amd64_syscall+0x318/frame 0xffffff82e5660af0 Xfast_syscall() at Xfast_syscall+0xf7/frame 0xffffff82e5660af0 --- syscall (326, FreeBSD ELF64, sys___getcwd), rip =3D 0x8011a191c, rsp = =3D 0x7fffffffe658, rbp =3D 0x801873400 --- KDB: enter: panic [ thread pid 1918 tid 100919 ] Stopped at kdb_enter+0x3b: movq $0,0x645622(%rip) db> show alllocks db> <=E2=80=93nothing db> show mount 0xfffffe0007ab29a8 /dev/gpt/miraROOT on / (ufs) 0xfffffe0007ab3000 devfs on /dev (devfs) 0xfffffe0007bf3670 /dev/gpt/miraSAFE on /.safe (ufs) 0xfffffe0007bf3338 /dev/gpt/miraVAR on /var (ufs) 0xfffffe0007bf3000 /dev/gpt/miraLOCAL on /usr/local (ufs) 0xfffffe0007ab39a8 /dev/gpt/miraTMP on /tmp (ufs) 0xfffffe0007ab3670 /dev/gpt/miraDATA on /data (ufs) 0xfffffe0007ab3338 :/.safe/etc on /etc (unionfs) 0xfffffe0007c1a338 :/.safe/home on /usr/home (unionfs) 0xfffffe0007ab2670 :/.safe/root on /root (unionfs) 0xfffffe002db6d338 miraP0.2xSATA10k-1 on /zfs/P0.2xSATA10k-1 (zfs) 0xfffffe002db6d000 miraP1.3xSATA5k9-z1 on /zfs/P1.3xSATA5k9-z1 (zfs) 0xfffffe002db6c9a8 miraP1.3xSATA5k9-z1/.backups on /zfs/P1.3xSATA5k9-z1/.backups (zfs) 0xfffffe002db6c670 miraP1.3xSATA5k9-z1/netshares on /zfs/P1.3xSATA5k9-z1/extrashares (zfs) 0xfffffe002db6c338 miraP1.3xSATA5k9-z1/netshares/OmniTOOLS4win on /zfs/P1.3xSATA5k9-z1/extrashares/OmniTOOLS4win (zfs) 0xfffffe002db6c000 miraP1.3xSATA5k9-z1/netshares/egroupware on /zfs/P1.3xSATA5k9-z1/extrashares/egroupware (zfs) 0xfffffe0007c1a9a8 miraP1.3xSATA5k9-z1/netshares/tftproot on /zfs/P1.3xSATA5k9-z1/extrashares/tftproot (zfs) 0xfffffe0007c1a670 miraP0.2xSATA10k-1/netshares on /zfs/netshares (zfs) 0xfffffe0007ab2338 miraP1.3xSATA5k9-z1/netshares/Literatur on /zfs/netshares/Literatur (zfs) 0xfffffe0007ab2000 miraP0.2xSATA10k-1/netshares/OmniLAN on /zfs/netshares/OmniLAN (zfs) 0xfffffe002dbc3670 miraP1.3xSATA5k9-z1/netshares/deployment on /zfs/netshares/deployment (zfs) 0xfffffe002dbc3338 miraP1.3xSATA5k9-z1/netshares/deployment/Kundenablage on /zfs/netshares/deployment/Kundenablage (zfs) 0xfffffe002dbc3000 miraP1.3xSATA5k9-z1/netshares/deployment/Kundenablage-ncmp on /zfs/netshares/deployment/Kundenablage/ncmp (zfs) 0xfffffe002dbc29a8 miraP1.3xSATA5k9-z1/netshares/deployment/SW-Archive on /zfs/netshares/deployment/SW-Archive (zfs) 0xfffffe002dbc2670 miraP1.3xSATA5k9-z1/netshares/deployment/pub on /zfs/netshares/deployment/pub (zfs) 0xfffffe002dbc2338 miraP1.3xSATA5k9-z1/netshares/deployment/FreeBSD-pub on /zfs/netshares/deployment/pub/FreeBSD (zfs) 0xfffffe002dbc2000 miraP1.3xSATA5k9-z1/netshares/deployment/FreeBSD-OmniLAN on /zfs/netshares/deployment/pub/FreeBSD/OmniLAN (zfs) 0xfffffe002db6d9a8 miraP1.3xSATA5k9-z1/netshares/deployment/FreeBSD-portstree on /zfs/netshares/deployment/pub/FreeBSD/OmniLAN/ports/ports (zfs) 0xfffffe002db6d670 miraP0.2xSATA10k-1/netshares/home on /zfs/netshares/home (zfs) 0xfffffe002dc36000 miraP0.2xSATA10k-1/netshares/home/dh7r on /zfs/netshares/home/dh7r (zfs) 0xfffffe0007c1a000 miraP0.2xSATA10k-1/netshares/home/hs10r on /zfs/netshares/home/hs10r (zfs) 0xfffffe002dc429a8 miraP1.3xSATA5k9-z1/netshares/multimedia on /zfs/netshares/multimedia (zfs) 0xfffffe002dc359a8 miraP1.3xSATA5k9-z1/netshares/multimedia/Audio on /zfs/netshares/multimedia/Audio (zfs) 0xfffffe0007c199a8 miraP1.3xSATA5k9-z1/netshares/multimedia/Fotos on /zfs/netshares/multimedia/Fotos (zfs) 0xfffffe0007c19670 miraP1.3xSATA5k9-z1/netshares/multimedia/Spiele on /zfs/netshares/multimedia/Spiele (zfs) 0xfffffe002dc35670 miraP1.3xSATA5k9-z1/netshares/multimedia/Video on /zfs/netshares/multimedia/Video (zfs) 0xfffffe002dc35338 miraP1.3xSATA5k9-z1/netshares/tmp on /zfs/netshares/tmp (zfs) 0xfffffe002dc35000 /dev/gpt/JAILbaosROOT on /.JAILbaos (ufs) 0xfffffe002dc349a8 /dev/gpt/JAILfbsmROOT on /.JAILfbsm (ufs) 0xfffffe002dc34670 /dev/gpt/JAILbaosVAR on /.JAILbaos/var (ufs) 0xfffffe002dc34338 /dev/gpt/JAILfbsmVAR on /.JAILfbsm/var (ufs) 0xfffffe002dc42670 miraP0.2xSATA10k-1/JAILfbsmDATA on /.JAILfbsm/data (zf= s) 0xfffffe002dc34000 /zfs/netshares/deployment/pub/FreeBSD/OmniLAN/ports/ports on /.JAILfbsm/usr/ports (nullfs) 0xfffffe002dbc39a8 /zfs/netshares/deployment/pub/FreeBSD/OmniLAN/ports/distfiles on /.JAILfbsm/usr/ports/distfiles (nullfs) 0xfffffe002dc42338 devfs on /.JAILfbsm/dev (devfs) More info: show mount db> show mount 0xfffffe002dc34000 <=E2=80=93 /.JAILfbsm/usr/ports, 3rd la= st 0xfffffe002dc34000 /zfs/netshares/deployment/pub/FreeBSD/OmniLAN/ports/ports on /.JAILfbsm/usr/ports (nullfs) mnt_flag =3D LOCAL mnt_kern_flag =3D EXTENDED_SHARED, SHARED_WRITES, LOOKUP_EXCL_DOTDOT, MPSAFE, LOOKUP_SHARED mnt_opt =3D rw, fstype, fspath, target, errmsg mnt_stat =3D { version=3D537068824 type=3D222 flags=3D0x000000001000111c bsize=3D512 iosize=3D131072 blocks=3D6314393894 bfree=3D6310195364 bavail=3D6310195364 files=3D6310490744 ffree=3D6310195364 syncwrites=3D0 asyncwrites=3D0 syncreads=3D0 asyncreads=3D0 namemax=3D255 owner=3D0 fsid=3D[687931140, 41] } mnt_cred =3D { uid=3D0 ruid=3D0 } mnt_ref =3D 122 mnt_gen =3D 1 mnt_nvnodelistsize =3D 122 mnt_activevnodelistsize =3D 5 mnt_writeopcount =3D 0 mnt_maxsymlinklen =3D 0 mnt_iosize_max =3D 65536 mnt_hashseed =3D 1849308420 mnt_secondary_writes =3D 0 mnt_secondary_accwrites =3D 0 mnt_gjprovider =3D NULL List of active vnodes vnode vnode 0xfffffe01611063f0: 0xfffffe01611063f0: tag null, type VDIR tag null, type VDIR usecount 2, writecount 0, refcount 2 mountedhere 0 usecount 2, writecount 0, refcount 2 mountedhere 0 flags (VI_ACTIVE) v_object 0xfffffe0007b011d0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: EXCL by thread 0xfffffe00ba802920 (pid 1918) lock type zfs: EXCL by thread 0xfffffe00ba802920 (pid 1918) vp=3D0xfffffe01611063f0, lowervp=3D0xfffffe002dc119d8 vp=3D0xfffffe01611063f0, lowervp=3D0xfffffe002dc119d8 vnode vnode 0xfffffe01611535e8: 0xfffffe01611535e8: tag null, type VDIR tag null, type VDIR usecount 3, writecount 0, refcount 3 mountedhere 0 usecount 3, writecount 0, refcount 3 mountedhere 0 flags (VI_ACTIVE) flags (VI_ACTIVE) v_object 0xfffffe01610c0740 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe01610c0740 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01611535e8, lowervp=3D0xfffffe01611a2bd0 vp=3D0xfffffe01611535e8, lowervp=3D0xfffffe01611a2bd0 vnode vnode 0xfffffe00babae9d8: 0xfffffe00babae9d8: tag null, type VDIR tag null, type VDIR usecount 1, writecount 0, refcount 1 mountedhere 0xfffffe002dbc39a8 usecount 1, writecount 0, refcount 1 mountedhere 0xfffffe002dbc39a8 flags (VI_ACTIVE) flags (VI_ACTIVE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe00babae9d8, lowervp=3D0xfffffe00ba9051f8 vp=3D0xfffffe00babae9d8, lowervp=3D0xfffffe00ba9051f8 vnode vnode 0xfffffe00babae7e0: 0xfffffe00babae7e0: tag syncer, type VNON= tag syncer, type VNON usecount 1, writecount 0, refcount 1 mountedhere 0 usecount 1, writecount 0, refcount 1 mountedhere 0 flags (VI_ACTIVE) flags (VI_ACTIVE) lock type syncer: UNLOCKED lock type syncer: UNLOCKED vnode vnode 0xfffffe00bac2cdc8: 0xfffffe00bac2cdc8: tag null, type VDIR tag null, type VDIR usecount 1, writecount 0, refcount 1 mountedhere 0 usecount 1, writecount 0, refcount 1 mountedhere 0 flags (VV_ROOT|VI_ACTIVE) flags (VV_ROOT|VI_ACTIVE) v_object 0xfffffe0007b011d0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe0007b011d0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: EXCL by thread 0xfffffe00ba802920 (pid 1918) lock type zfs: EXCL by thread 0xfffffe00ba802920 (pid 1918) vp=3D0xfffffe00bac2cdc8, lowervp=3D0xfffffe002dc119d8 vp=3D0xfffffe00bac2cdc8, lowervp=3D0xfffffe002dc119d8 List of inactive vnodes vnode vnode 0xfffffe01610689d8: 0xfffffe01610689d8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01610689d8, lowervp=3D0xfffffe0161068bd0 vp=3D0xfffffe01610689d8, lowervp=3D0xfffffe0161068bd0 vnode vnode 0xfffffe01610685e8: 0xfffffe01610685e8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01610685e8, lowervp=3D0xfffffe01610687e0 vp=3D0xfffffe01610685e8, lowervp=3D0xfffffe01610687e0 vnode vnode 0xfffffe01610681f8: 0xfffffe01610681f8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01610681f8, lowervp=3D0xfffffe01610683f0 vp=3D0xfffffe01610681f8, lowervp=3D0xfffffe01610683f0 vnode vnode 0xfffffe01610a7dc8: 0xfffffe01610a7dc8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01610a7dc8, lowervp=3D0xfffffe0161068000 vp=3D0xfffffe01610a7dc8, lowervp=3D0xfffffe0161068000 vnode vnode 0xfffffe01610a79d8: 0xfffffe01610a79d8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01610a79d8, lowervp=3D0xfffffe01610a7bd0 vp=3D0xfffffe01610a79d8, lowervp=3D0xfffffe01610a7bd0 vnode vnode 0xfffffe01610a75e8: 0xfffffe01610a75e8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01610a75e8, lowervp=3D0xfffffe01610a77e0 vp=3D0xfffffe01610a75e8, lowervp=3D0xfffffe01610a77e0 vnode vnode 0xfffffe01610a71f8: 0xfffffe01610a71f8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01610a71f8, lowervp=3D0xfffffe01610a73f0 vp=3D0xfffffe01610a71f8, lowervp=3D0xfffffe01610a73f0 vnode vnode 0xfffffe0161061dc8: 0xfffffe0161061dc8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) vp=3D0xfffffe0161061dc8, lowervp=3D0xfffffe01610a7000 vnode vnode 0xfffffe01610619d8: 0xfffffe01610619d8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01610619d8, lowervp=3D0xfffffe0161061bd0 vp=3D0xfffffe01610619d8, lowervp=3D0xfffffe0161061bd0 vnode vnode 0xfffffe01610615e8: 0xfffffe01610615e8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01610615e8, lowervp=3D0xfffffe01610617e0 vp=3D0xfffffe01610615e8, lowervp=3D0xfffffe01610617e0 vnode vnode 0xfffffe01610611f8: 0xfffffe01610611f8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01610611f8, lowervp=3D0xfffffe01610613f0 vp=3D0xfffffe01610611f8, lowervp=3D0xfffffe01610613f0 vnode vnode 0xfffffe01610931f8: 0xfffffe01610931f8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01610931f8, lowervp=3D0xfffffe0161093000 vp=3D0xfffffe01610931f8, lowervp=3D0xfffffe0161093000 vnode vnode 0xfffffe0161011dc8: 0xfffffe0161011dc8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe0161011dc8, lowervp=3D0xfffffe01610933f0 vp=3D0xfffffe0161011dc8, lowervp=3D0xfffffe01610933f0 vnode vnode 0xfffffe00babaebd0: 0xfffffe00babaebd0: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe00babaebd0, lowervp=3D0xfffffe00ba9043f0 vp=3D0xfffffe00babaebd0, lowervp=3D0xfffffe00ba9043f0 vnode vnode 0xfffffe00bac2d9d8: 0xfffffe00bac2d9d8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe00bac2d9d8, lowervp=3D0xfffffe00ba934bd0 vp=3D0xfffffe00bac2d9d8, lowervp=3D0xfffffe00ba934bd0 vnode vnode 0xfffffe00baf989d8: 0xfffffe00baf989d8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe00baf989d8, lowervp=3D0xfffffe005ffc93f0 vp=3D0xfffffe00baf989d8, lowervp=3D0xfffffe005ffc93f0 vnode vnode 0xfffffe00baf985e8: 0xfffffe00baf985e8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe00baf985e8, lowervp=3D0xfffffe00baf987e0 vp=3D0xfffffe00baf985e8, lowervp=3D0xfffffe00baf987e0 vnode vnode 0xfffffe005ffc91f8: 0xfffffe005ffc91f8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe005ffc91f8, lowervp=3D0xfffffe00baf983f0 vp=3D0xfffffe005ffc91f8, lowervp=3D0xfffffe00baf983f0 vnode vnode 0xfffffe01610935e8: 0xfffffe01610935e8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01610935e8, lowervp=3D0xfffffe00baf9a000 vp=3D0xfffffe01610935e8, lowervp=3D0xfffffe00baf9a000 vnode vnode 0xfffffe00ba9141f8: 0xfffffe00ba9141f8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe00ba9141f8, lowervp=3D0xfffffe01610937e0 vp=3D0xfffffe00ba9141f8, lowervp=3D0xfffffe01610937e0 vnode vnode 0xfffffe016110d9d8: 0xfffffe016110d9d8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 vp=3D0xfffffe016110d9d8, lowervp=3D0xfffffe016110dbd0 vnode vnode 0xfffffe016110d5e8: 0xfffffe016110d5e8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016110d5e8, lowervp=3D0xfffffe016110d7e0 vp=3D0xfffffe016110d5e8, lowervp=3D0xfffffe016110d7e0 vnode vnode 0xfffffe016110d1f8: 0xfffffe016110d1f8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016110d1f8, lowervp=3D0xfffffe016110d3f0 vp=3D0xfffffe016110d1f8, lowervp=3D0xfffffe016110d3f0 vnode vnode 0xfffffe016110cdc8: 0xfffffe016110cdc8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016110cdc8, lowervp=3D0xfffffe016110d000 vp=3D0xfffffe016110cdc8, lowervp=3D0xfffffe016110d000 vnode vnode 0xfffffe016110c9d8: 0xfffffe016110c9d8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016110c9d8, lowervp=3D0xfffffe016110cbd0 vp=3D0xfffffe016110c9d8, lowervp=3D0xfffffe016110cbd0 vnode vnode 0xfffffe016110c5e8: 0xfffffe016110c5e8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016110c5e8, lowervp=3D0xfffffe016110c7e0 vp=3D0xfffffe016110c5e8, lowervp=3D0xfffffe016110c7e0 vnode vnode 0xfffffe016110c1f8: 0xfffffe016110c1f8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016110c1f8, lowervp=3D0xfffffe016110c3f0 vp=3D0xfffffe016110c1f8, lowervp=3D0xfffffe016110c3f0 vnode vnode 0xfffffe016110adc8: 0xfffffe016110adc8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016110adc8, lowervp=3D0xfffffe016110c000 vp=3D0xfffffe016110adc8, lowervp=3D0xfffffe016110c000 vnode vnode 0xfffffe016100e9d8: 0xfffffe016100e9d8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016100e9d8, lowervp=3D0xfffffe016100ebd0 vp=3D0xfffffe016100e9d8, lowervp=3D0xfffffe016100ebd0 vnode vnode 0xfffffe01610111f8: 0xfffffe01610111f8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01610111f8, lowervp=3D0xfffffe01610113f0 vp=3D0xfffffe01610111f8, lowervp=3D0xfffffe01610113f0 vnode vnode 0xfffffe016100cdc8: 0xfffffe016100cdc8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016100cdc8, lowervp=3D0xfffffe0161011000 vp=3D0xfffffe016100cdc8, lowervp=3D0xfffffe0161011000 vnode vnode 0xfffffe016100c9d8: 0xfffffe016100c9d8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016100c9d8, lowervp=3D0xfffffe016100cbd0 vp=3D0xfffffe016100c9d8, lowervp=3D0xfffffe016100cbd0 vnode vnode 0xfffffe016100c5e8: 0xfffffe016100c5e8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016100c5e8, lowervp=3D0xfffffe016100c7e0 vp=3D0xfffffe016100c5e8, lowervp=3D0xfffffe016100c7e0 vnode vnode 0xfffffe016100c1f8: 0xfffffe016100c1f8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 vp=3D0xfffffe016100c1f8, lowervp=3D0xfffffe016100c3f0 vnode vnode 0xfffffe00babae000: 0xfffffe00babae000: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe00babae000, lowervp=3D0xfffffe01610115e8 vp=3D0xfffffe00babae000, lowervp=3D0xfffffe01610115e8 vnode vnode 0xfffffe016111dbd0: 0xfffffe016111dbd0: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016111dbd0, lowervp=3D0xfffffe0161013dc8 vp=3D0xfffffe016111dbd0, lowervp=3D0xfffffe0161013dc8 vnode vnode 0xfffffe016100e5e8: 0xfffffe016100e5e8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016100e5e8, lowervp=3D0xfffffe016100e7e0 vp=3D0xfffffe016100e5e8, lowervp=3D0xfffffe016100e7e0 vnode vnode 0xfffffe016100e1f8: 0xfffffe016100e1f8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016100e1f8, lowervp=3D0xfffffe016100e3f0 vp=3D0xfffffe016100e1f8, lowervp=3D0xfffffe016100e3f0 vnode vnode 0xfffffe016111d7e0: 0xfffffe016111d7e0: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016111d7e0, lowervp=3D0xfffffe016111d9d8 vp=3D0xfffffe016111d7e0, lowervp=3D0xfffffe016111d9d8 vnode vnode 0xfffffe016111d3f0: 0xfffffe016111d3f0: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016111d3f0, lowervp=3D0xfffffe016111d5e8 vp=3D0xfffffe016111d3f0, lowervp=3D0xfffffe016111d5e8 vnode vnode 0xfffffe016111d000: 0xfffffe016111d000: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016111d000, lowervp=3D0xfffffe016111d1f8 vp=3D0xfffffe016111d000, lowervp=3D0xfffffe016111d1f8 vnode vnode 0xfffffe016111bbd0: 0xfffffe016111bbd0: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016111bbd0, lowervp=3D0xfffffe016111bdc8 vp=3D0xfffffe016111bbd0, lowervp=3D0xfffffe016111bdc8 vnode vnode 0xfffffe016111b7e0: 0xfffffe016111b7e0: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016111b7e0, lowervp=3D0xfffffe016111b9d8 vp=3D0xfffffe016111b7e0, lowervp=3D0xfffffe016111b9d8 vnode vnode 0xfffffe016111b3f0: 0xfffffe016111b3f0: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016111b3f0, lowervp=3D0xfffffe016111b5e8 vp=3D0xfffffe016111b3f0, lowervp=3D0xfffffe016111b5e8 vnode vnode 0xfffffe016111b000: 0xfffffe016111b000: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe00baff4570 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe00baff4570 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016111b000, lowervp=3D0xfffffe016111b1f8 vp=3D0xfffffe016111b000, lowervp=3D0xfffffe016111b1f8 vnode vnode 0xfffffe0161128bd0: 0xfffffe0161128bd0: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe0161128bd0, lowervp=3D0xfffffe016110ddc8 vp=3D0xfffffe0161128bd0, lowervp=3D0xfffffe016110ddc8 vnode vnode 0xfffffe0161015bd0: 0xfffffe0161015bd0: tag null, type VDIR tag null, type VDIR flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe0161015bd0, lowervp=3D0xfffffe01610151f8 vp=3D0xfffffe0161015bd0, lowervp=3D0xfffffe01610151f8 vnode vnode 0xfffffe016112d9d8: 0xfffffe016112d9d8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016112d9d8, lowervp=3D0xfffffe016112dbd0 vp=3D0xfffffe016112d9d8, lowervp=3D0xfffffe016112dbd0 vnode vnode 0xfffffe016112d5e8: 0xfffffe016112d5e8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016112d5e8, lowervp=3D0xfffffe016112d7e0 vp=3D0xfffffe016112d5e8, lowervp=3D0xfffffe016112d7e0 vnode vnode 0xfffffe016112d1f8: 0xfffffe016112d1f8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016112d1f8, lowervp=3D0xfffffe016112d3f0 vp=3D0xfffffe016112d1f8, lowervp=3D0xfffffe016112d3f0 vnode vnode 0xfffffe016112cdc8: 0xfffffe016112cdc8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016112cdc8, lowervp=3D0xfffffe016112d000 vp=3D0xfffffe016112cdc8, lowervp=3D0xfffffe016112d000 vnode vnode 0xfffffe016112c9d8: 0xfffffe016112c9d8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016112c9d8, lowervp=3D0xfffffe016112cbd0 vp=3D0xfffffe016112c9d8, lowervp=3D0xfffffe016112cbd0 vnode vnode 0xfffffe016112c5e8: 0xfffffe016112c5e8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016112c5e8, lowervp=3D0xfffffe016112c7e0 vp=3D0xfffffe016112c5e8, lowervp=3D0xfffffe016112c7e0 vnode vnode 0xfffffe016112c1f8: 0xfffffe016112c1f8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016112c1f8, lowervp=3D0xfffffe016112c3f0 vp=3D0xfffffe016112c1f8, lowervp=3D0xfffffe016112c3f0 vnode vnode 0xfffffe0161128dc8: 0xfffffe0161128dc8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe0161128dc8, lowervp=3D0xfffffe016112c000 vp=3D0xfffffe0161128dc8, lowervp=3D0xfffffe016112c000 vnode vnode 0xfffffe01611389d8: 0xfffffe01611389d8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01611389d8, lowervp=3D0xfffffe0161138bd0 vp=3D0xfffffe01611389d8, lowervp=3D0xfffffe0161138bd0 vnode vnode 0xfffffe01611385e8: 0xfffffe01611385e8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01611385e8, lowervp=3D0xfffffe01611387e0 vp=3D0xfffffe01611385e8, lowervp=3D0xfffffe01611387e0 vnode vnode 0xfffffe01611381f8: 0xfffffe01611381f8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01611381f8, lowervp=3D0xfffffe01611383f0 vp=3D0xfffffe01611381f8, lowervp=3D0xfffffe01611383f0 vnode vnode 0xfffffe0161137dc8: 0xfffffe0161137dc8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe0161137dc8, lowervp=3D0xfffffe0161138000 usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01611379d8, lowervp=3D0xfffffe0161137bd0 vp=3D0xfffffe01611379d8, lowervp=3D0xfffffe0161137bd0 vnode vnode 0xfffffe01611375e8: 0xfffffe01611375e8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01611375e8, lowervp=3D0xfffffe01611377e0 vp=3D0xfffffe01611375e8, lowervp=3D0xfffffe01611377e0 vnode vnode 0xfffffe01611371f8: 0xfffffe01611371f8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01611371f8, lowervp=3D0xfffffe01611373f0 vp=3D0xfffffe01611371f8, lowervp=3D0xfffffe01611373f0 vnode vnode 0xfffffe016112ddc8: 0xfffffe016112ddc8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016112ddc8, lowervp=3D0xfffffe0161137000 vp=3D0xfffffe016112ddc8, lowervp=3D0xfffffe0161137000 vnode vnode 0xfffffe01611489d8: 0xfffffe01611489d8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01611489d8, lowervp=3D0xfffffe0161148bd0 vp=3D0xfffffe01611489d8, lowervp=3D0xfffffe0161148bd0 vnode vnode 0xfffffe01611485e8: 0xfffffe01611485e8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01611485e8, lowervp=3D0xfffffe01611487e0 vp=3D0xfffffe01611485e8, lowervp=3D0xfffffe01611487e0 vnode vnode 0xfffffe01611481f8: 0xfffffe01611481f8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01611481f8, lowervp=3D0xfffffe01611483f0 vp=3D0xfffffe01611481f8, lowervp=3D0xfffffe01611483f0 vnode vnode 0xfffffe0161146dc8: 0xfffffe0161146dc8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe0161146dc8, lowervp=3D0xfffffe0161148000 vp=3D0xfffffe0161146dc8, lowervp=3D0xfffffe0161148000 vnode vnode 0xfffffe01611469d8: 0xfffffe01611469d8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01611469d8, lowervp=3D0xfffffe0161146bd0 vp=3D0xfffffe01611469d8, lowervp=3D0xfffffe0161146bd0 vnode vnode 0xfffffe016110a9d8: 0xfffffe016110a9d8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016110a9d8, lowervp=3D0xfffffe016110abd0 vp=3D0xfffffe016110a9d8, lowervp=3D0xfffffe016110abd0 vnode vnode 0xfffffe016110a5e8: 0xfffffe016110a5e8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016110a5e8, lowervp=3D0xfffffe016110a7e0 vp=3D0xfffffe016110a5e8, lowervp=3D0xfffffe016110a7e0 vnode vnode 0xfffffe016110a1f8: 0xfffffe016110a1f8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016110a1f8, lowervp=3D0xfffffe016110a3f0 vp=3D0xfffffe016110a1f8, lowervp=3D0xfffffe016110a3f0 vnode vnode 0xfffffe0161109dc8: 0xfffffe0161109dc8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED vnode vnode 0xfffffe01611099d8: 0xfffffe01611099d8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01611099d8, lowervp=3D0xfffffe0161109bd0 vp=3D0xfffffe01611099d8, lowervp=3D0xfffffe0161109bd0 vnode vnode 0xfffffe01611095e8: 0xfffffe01611095e8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01611095e8, lowervp=3D0xfffffe01611097e0 vp=3D0xfffffe01611095e8, lowervp=3D0xfffffe01611097e0 vnode vnode 0xfffffe01610603f0: 0xfffffe01610603f0: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01610603f0, lowervp=3D0xfffffe01610601f8 vp=3D0xfffffe01610603f0, lowervp=3D0xfffffe01610601f8 vnode vnode 0xfffffe01611559d8: 0xfffffe01611559d8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01611559d8, lowervp=3D0xfffffe0161155bd0 vp=3D0xfffffe01611559d8, lowervp=3D0xfffffe0161155bd0 vnode vnode 0xfffffe01611465e8: 0xfffffe01611465e8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01611465e8, lowervp=3D0xfffffe01611467e0 vp=3D0xfffffe01611465e8, lowervp=3D0xfffffe01611467e0 vnode vnode 0xfffffe01611461f8: 0xfffffe01611461f8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01611461f8, lowervp=3D0xfffffe01611463f0 vp=3D0xfffffe01611461f8, lowervp=3D0xfffffe01611463f0 vnode vnode 0xfffffe0161138dc8: 0xfffffe0161138dc8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe0161138dc8, lowervp=3D0xfffffe0161146000 vp=3D0xfffffe0161138dc8, lowervp=3D0xfffffe0161146000 vnode vnode 0xfffffe01611589d8: 0xfffffe01611589d8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01611589d8, lowervp=3D0xfffffe0161158bd0 vp=3D0xfffffe01611589d8, lowervp=3D0xfffffe0161158bd0 vnode vnode 0xfffffe016117c000: 0xfffffe016117c000: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016117c000, lowervp=3D0xfffffe016117c1f8 vp=3D0xfffffe016117c000, lowervp=3D0xfffffe016117c1f8 vnode vnode 0xfffffe016117bbd0: 0xfffffe016117bbd0: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016117bbd0, lowervp=3D0xfffffe016117bdc8 vp=3D0xfffffe016117bbd0, lowervp=3D0xfffffe016117bdc8 vnode vnode 0xfffffe016117b7e0: 0xfffffe016117b7e0: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016117b7e0, lowervp=3D0xfffffe016117b9d8 vp=3D0xfffffe016117b7e0, lowervp=3D0xfffffe016117b9d8 vnode vnode 0xfffffe016117b3f0: 0xfffffe016117b3f0: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016117b3f0, lowervp=3D0xfffffe016117b5e8 vp=3D0xfffffe016117b3f0, lowervp=3D0xfffffe016117b5e8 vnode vnode 0xfffffe016117b000: 0xfffffe016117b000: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) vp=3D0xfffffe016117b000, lowervp=3D0xfffffe016117b1f8 vnode vnode 0xfffffe016117c5e8: 0xfffffe016117c5e8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016117c5e8, lowervp=3D0xfffffe0161158dc8 vp=3D0xfffffe016117c5e8, lowervp=3D0xfffffe0161158dc8 vnode vnode 0xfffffe01611969d8: 0xfffffe01611969d8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01611969d8, lowervp=3D0xfffffe0161196bd0 vp=3D0xfffffe01611969d8, lowervp=3D0xfffffe0161196bd0 vnode vnode 0xfffffe01611965e8: 0xfffffe01611965e8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01611965e8, lowervp=3D0xfffffe01611967e0 vp=3D0xfffffe01611965e8, lowervp=3D0xfffffe01611967e0 vnode vnode 0xfffffe01611961f8: 0xfffffe01611961f8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01611961f8, lowervp=3D0xfffffe01611963f0 vp=3D0xfffffe01611961f8, lowervp=3D0xfffffe01611963f0 vnode vnode 0xfffffe0161195dc8: 0xfffffe0161195dc8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe0161195dc8, lowervp=3D0xfffffe0161196000 vp=3D0xfffffe0161195dc8, lowervp=3D0xfffffe0161196000 vnode vnode 0xfffffe01611959d8: 0xfffffe01611959d8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01611959d8, lowervp=3D0xfffffe0161195bd0 vp=3D0xfffffe01611959d8, lowervp=3D0xfffffe0161195bd0 vnode vnode 0xfffffe01611955e8: 0xfffffe01611955e8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01611955e8, lowervp=3D0xfffffe01611957e0 vp=3D0xfffffe01611955e8, lowervp=3D0xfffffe01611957e0 vnode vnode 0xfffffe01611951f8: 0xfffffe01611951f8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01611951f8, lowervp=3D0xfffffe01611953f0 vp=3D0xfffffe01611951f8, lowervp=3D0xfffffe01611953f0 vnode vnode 0xfffffe016117cdc8: 0xfffffe016117cdc8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016117cdc8, lowervp=3D0xfffffe0161195000 vp=3D0xfffffe016117cdc8, lowervp=3D0xfffffe0161195000 vnode vnode 0xfffffe016119f9d8: 0xfffffe016119f9d8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016119f9d8, lowervp=3D0xfffffe016119fbd0 vp=3D0xfffffe016119f9d8, lowervp=3D0xfffffe016119fbd0 vnode vnode 0xfffffe016119f5e8: 0xfffffe016119f5e8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016119f5e8, lowervp=3D0xfffffe016119f7e0 vp=3D0xfffffe016119f5e8, lowervp=3D0xfffffe016119f7e0 vnode vnode 0xfffffe016119f1f8: 0xfffffe016119f1f8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016119f1f8, lowervp=3D0xfffffe016119f3f0 vp=3D0xfffffe016119f1f8, lowervp=3D0xfffffe016119f3f0 vnode vnode 0xfffffe016119edc8: 0xfffffe016119edc8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 lock type zfs: UNLOCKED vp=3D0xfffffe016119edc8, lowervp=3D0xfffffe016119f000 vp=3D0xfffffe016119edc8, lowervp=3D0xfffffe016119f000 vnode vnode 0xfffffe016119e9d8: 0xfffffe016119e9d8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016119e9d8, lowervp=3D0xfffffe016119ebd0 vp=3D0xfffffe016119e9d8, lowervp=3D0xfffffe016119ebd0 vnode vnode 0xfffffe016119e5e8: 0xfffffe016119e5e8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016119e5e8, lowervp=3D0xfffffe016119e7e0 vp=3D0xfffffe016119e5e8, lowervp=3D0xfffffe016119e7e0 vnode vnode 0xfffffe016119e1f8: 0xfffffe016119e1f8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe01610c22b8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe01610c22b8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe016119e1f8, lowervp=3D0xfffffe016119e3f0 vp=3D0xfffffe016119e1f8, lowervp=3D0xfffffe016119e3f0 vnode vnode 0xfffffe0161196dc8: 0xfffffe0161196dc8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe0161196dc8, lowervp=3D0xfffffe016119e000 vp=3D0xfffffe0161196dc8, lowervp=3D0xfffffe016119e000 vnode vnode 0xfffffe01611a39d8: 0xfffffe01611a39d8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01611a39d8, lowervp=3D0xfffffe01611a3bd0 vp=3D0xfffffe01611a39d8, lowervp=3D0xfffffe01611a3bd0 vnode vnode 0xfffffe0161128000: 0xfffffe0161128000: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe01610c2bc8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe01610c2bc8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe0161128000, lowervp=3D0xfffffe01611281f8 vp=3D0xfffffe0161128000, lowervp=3D0xfffffe01611281f8 vnode vnode 0xfffffe0161374bd0: 0xfffffe0161374bd0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe01612f1ae0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe01612f1ae0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe0161374bd0, lowervp=3D0xfffffe0161374dc8 vp=3D0xfffffe0161374bd0, lowervp=3D0xfffffe0161374dc8 vnode vnode 0xfffffe01613747e0: 0xfffffe01613747e0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01613747e0, lowervp=3D0xfffffe01613749d8 vp=3D0xfffffe01613747e0, lowervp=3D0xfffffe01613749d8 vnode vnode 0xfffffe01613743f0: 0xfffffe01613743f0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01613743f0, lowervp=3D0xfffffe01613745e8 vp=3D0xfffffe01613743f0, lowervp=3D0xfffffe01613745e8 vnode vnode 0xfffffe0161374000: 0xfffffe0161374000: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe0161374000, lowervp=3D0xfffffe01613741f8 vp=3D0xfffffe0161374000, lowervp=3D0xfffffe01613741f8 vnode vnode 0xfffffe01613253f0: 0xfffffe01613253f0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01613253f0, lowervp=3D0xfffffe0161326dc8 vp=3D0xfffffe01613253f0, lowervp=3D0xfffffe0161326dc8 vnode vnode 0xfffffe01613de9d8: 0xfffffe01613de9d8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01613de9d8, lowervp=3D0xfffffe01613debd0 vp=3D0xfffffe01613de9d8, lowervp=3D0xfffffe01613debd0 vnode vnode 0xfffffe01613de5e8: 0xfffffe01613de5e8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01613de5e8, lowervp=3D0xfffffe01613de7e0 vp=3D0xfffffe01613de5e8, lowervp=3D0xfffffe01613de7e0 vnode vnode 0xfffffe01613de1f8: 0xfffffe01613de1f8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01613de1f8, lowervp=3D0xfffffe01613de3f0 vp=3D0xfffffe01613de1f8, lowervp=3D0xfffffe01613de3f0 vnode vnode 0xfffffe01613dddc8: 0xfffffe01613dddc8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01613dddc8, lowervp=3D0xfffffe01613de000 vp=3D0xfffffe01613dddc8, lowervp=3D0xfffffe01613de000 vnode vnode 0xfffffe01613dd9d8: 0xfffffe01613dd9d8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01613dd9d8, lowervp=3D0xfffffe01613ddbd0 vp=3D0xfffffe01613dd9d8, lowervp=3D0xfffffe01613ddbd0 vnode vnode 0xfffffe01613dd5e8: 0xfffffe01613dd5e8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01613dd5e8, lowervp=3D0xfffffe01613dd7e0 vp=3D0xfffffe01613dd5e8, lowervp=3D0xfffffe01613dd7e0 vnode vnode 0xfffffe01613dd1f8: 0xfffffe01613dd1f8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01613dd1f8, lowervp=3D0xfffffe01613dd3f0 vp=3D0xfffffe01613dd1f8, lowervp=3D0xfffffe01613dd3f0 vnode vnode 0xfffffe01611011f8: 0xfffffe01611011f8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe00baff4570 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe00baff4570 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01611011f8, lowervp=3D0xfffffe016111b1f8 vp=3D0xfffffe01611011f8, lowervp=3D0xfffffe016111b1f8 db> Thanks, -Harry --------------enig3847833F22ECB7596420720E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlPRUDsACgkQLDqVQ9VXb8ghOgCgzqRxmE63Ir5LLi0kmIwVGohs XYEAnAnfssXpt7HXG9mFVT+COhXKn8cn =1NSx -----END PGP SIGNATURE----- --------------enig3847833F22ECB7596420720E-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 18:33:59 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A84534D6; Thu, 24 Jul 2014 18:33:57 +0000 (UTC) Date: Thu, 24 Jul 2014 14:33:53 -0400 From: Glen Barber To: freebsd-hackers@FreeBSD.org Subject: FreeBSD Quarterly Status Report - Second Quarter 2014 Message-ID: <20140724183353.GL1065@hub.FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; x-action=pgp-signed Content-Transfer-Encoding: quoted-printable X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:33:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 FreeBSD Project Quarterly Status Report: April - June 2014 This report covers FreeBSD-related projects between April and June 2014. This is the second of four reports planned for 2014. The second quarter of 2014 was a very busy and productive time for the FreeBSD Project. A new FreeBSD Core Team was elected, the FreeBSD Ports Management Team branched the second quarterly "stable" branch, the FreeBSD Release Engineering Team was in the process of finalizing the FreeBSD 9.3-RELEASE cycle, and many exciting new features have been added to FreeBSD. Thanks to all the reporters for the excellent work! This report contains 24 entries and we hope you enjoy reading it. The deadline for submissions covering the period from July to September 2014 is October 7th, 2014. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Core Team * FreeBSD Port Management Team * FreeBSD Release Engineering Team Projects * Chelsio iSCSI Offload Support * CUSE4BSD * FreeBSD and Summer of Code 2014 * New Automounter * pkg(8) * QEMU bsd-user-Enabled Ports Building * RPC/NFS and CTL/iSCSI Performance Optimizations * ZFSguru Kernel * PostgreSQL Performance Improvements * Running FreeBSD as an Application on Top of the Fiasco.OC Microkernel * SDIO Driver * TMPFS Stability * UEFI Boot * Updated vt(4) System Console Architectures * FreeBSD/arm64 Ports * FreeBSD Python Ports * KDE/FreeBSD * The Graphics Stack on FreeBSD Documentation * Quarterly Status Reports Miscellaneous * FreeBSD Host Support for OpenStack and OpenContrail * The FreeBSD Foundation __________________________________________________________________ FreeBSD Core Team Contact: FreeBSD Core Team The FreeBSD Core Team constitutes the project's "Board of Directors", responsible for deciding the project's overall goals and direction as well as managing specific areas of the FreeBSD project landscape. Topics for core this quarter have included some far-reaching policy reviews and some significant changes to the project development methodology. In May, a new release policy was published and presented at the BSDCan developer conference by John Baldwin. The idea is that each major release branch (for example, 10.X) is guaranteed to be supported for at least five years, but individual point releases on each branch, like 10.0-RELEASE, will be issued at regular intervals and only the latest point release will be supported. Another significant change did not receive approval. When the change to the Bylaws reforming the core team election process was put to the vote of all FreeBSD developers, it failed to reach a quorum. June saw the culmination of a long running project to replace the project's bug tracking system. As of June 3, the FreeBSD project has switched to Bugzilla as its bug tracking system. All of the history of GNATS PRs has been preserved, so there is no need to re-open old tickets. Work is still going on to replicate some of the integration tweaks that had been applied to GNATS, but all necessary functionality has been implemented and the project is already seeing the benefits of the new capabilities brought by Bugzilla. An election to select core members for the next two year term of office took place during this period. We would like to thank retiring members of core for their years of service. The new core team provides continuity with previous core teams: about half are incumbents from the previous team, and several former core team members have returned after a hiatus. Core now includes two members of the FreeBSD Foundation board and one other Foundation staff member, aiding greater coordination at the top level of the project. At the same time the core-secretary role was passed on to a new volunteer. Other activities included providing consultation on licensing terms for software within the FreeBSD source tree, and oversight of changes to the membership of postmaster and clusteradm. Three new src commit bits were issued during this quarter, and one was taken into safekeeping. __________________________________________________________________ FreeBSD Port Management Team URL: http://www.FreeBSD.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-po= rts/ URL: http://portsmon.freebsd.org/index.html URL: http://www.freebsd.org/portmgr/index.html URL: http://blogs.freebsdish.org/portmgr/ URL: http://www.twitter.com/freebsd_portmgr/ URL: http://www.facebook.com/portmgr URL: http://plus.google.com/communities/108335846196454338383 Contact: Frederic Culot Contact: FreeBSD Port Management Team The ports tree slowly approaches the 25,000 ports threshold, while the PR count is slightly below 1800. In Q2 we added three new committers, took in one commit bit for safekeeping, and reinstated one commit bit. In May, Thomas Abthorpe was replaced by Frederic Culot as portmgr secretary, and Steve Wills became a member of the portmgr team. Commencing July 1, the third intake of portmgr-lurkers started active duty on portmgr for a four month duration. The next two candidates are William Grzybowski and Nicola Vitale. This quarter also saw the release of the second quarterly branch, namely 2014Q2. This branch was not only built for 10 (as 2014Q1) but for 9 as well (both i386 and amd64). Open tasks: 1. As previously noted, many PRs continue to languish, we would like to see committers dedicate themselves to closing as many as possible. __________________________________________________________________ FreeBSD Release Engineering Team URL: http://www.freebsd.org/releases/9.3R/schedule.html URL: http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ Contact: FreeBSD Release Engineering Team The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, and announcing code freezes and maintaining the respective branches, among other things. In early May, the FreeBSD 9.3-RELEASE cycle entered the code slush phase. The FreeBSD 9.3-RELEASE cycle is nearing the final phases, and 9.3-RC3 builds will be starting soon. 9.3-RC3 is planned to be the final release candidate for this release cycle, and at the time of this writing, 9.3-RELEASE should be available on schedule. Work is ongoing to integrate support for embedded architectures into the release build process. At this time, support exists for a number of ARM kernels, in particular the Raspberry Pi, BeagleBone, and WandBoard. Additionally, work is in progress to produce virtual machine images as part of the release cycle, supporting various cloud services such as Microsoft Azure, Amazon EC2, and Google Compute Engine. This project is sponsored by The FreeBSD Foundation . __________________________________________________________________ Chelsio iSCSI Offload Support Contact: Sreenivasa Honnur Building on the new in-kernel iSCSI target and initiator stack released in FreeBSD 10.0, Chelsio Communications has begun developing an offload interface to take advantage of the hardware offload capabilities of Chelsio T4 and T5 10 and 40 gigabit Ethernet adapters. The code currently implements a working prototype of offload for the initiator side, and target side offload should begin shortly. The code will be released under the BSD license and is expected to be completed later in the year and be committed to FreeBSD-HEAD, and will likely ship in a FreeBSD release in early 2015. Open tasks: 1. Complete testing and debugging of the initiator offload. 2. Start development of target offload. 3. Create hardware-independent offload APIs, based on experiences with target and initiator proof-of-concept implementations. __________________________________________________________________ CUSE4BSD URL: http://svnweb.freebsd.org/changeset/base/266581 Contact: Hans Petter Selasky The so-called CUSE4BSD has been imported into the base system of FreeBSD-11. CUSE is short for character device in userspace. The CUSE library is a wrapper for the devfs(8) kernel functionality which is exposed through /dev/cuse. In order to function, the CUSE kernel code must either be enabled in the kernel configuration file or loaded separately as a module. Follow the commit message link to get more information. __________________________________________________________________ FreeBSD and Summer of Code 2014 URL: http://gsoc.FreeBSD.org URL: https://wiki.freebsd.org/SummerOfCode2014 Contact: Gavin Atkinson Contact: Glen Barber Contact: Wojciech Koszek FreeBSD received 39 project proposals this year, many of which were of a very high standard. After a difficult selection process narrowing these down into the slots we had been allocated, a total of 16 projects were selected to participate in Google Summer of Code 2014 with FreeBSD. The projects selected span a wide range of areas within FreeBSD, covering both the base system and ports infrastructure, userland and kernel. We have students working on firewall optimisation, ports packaging tools, embedded systems, debugging infrastructure, improved Unicode support, enhancements to the loader and to the installer, and several other areas of work. We are just over halfway through the allocated time this year, and are very much looking forward to integrating code produced by these projects into FreeBSD. This is the tenth time FreeBSD has taken part in Google's Summer of Code, and we are grateful to Google to have accepted us as a participating organisation. __________________________________________________________________ New Automounter Contact: Edward Tomasz Napieral/a Deficiencies in the current automounter, amd(8), are a recurring problem reported by many FreeBSD users. A new automounter is being developed to address these concerns. The automounter is a cleanroom implementation of functionality available in most other Unix systems, using proper kernel support implemented via an autofs filesystem. The automounter supports a standard map format, and will integrate with the Lightweight Directory Access Protocol (LDAP) service. The project is at the early testing stage. A patch will be released as part of a broader call for testing after additional review on some critical components (in particular, the autofs filesystem). After fixing reported problems, the code will be committed to FreeBSD 11-CURRENT. It is expected to ship in the FreeBSD 10.2 release. This project is sponsored by The FreeBSD Foundation . Open tasks: 1. Fix bad interaction with fts(3). 2. Debug a problem with Kerberos NFS mounts. __________________________________________________________________ pkg(8) URL: https://github.com/freebsd/pkg URL: https://github.com/freebsd/pkg/issues Contact: Baptiste Daroussin Contact: Bryan Drewery Contact: Matthew Seaman Contact: Vsevolod Stakhov Contact: The pkg mailing list pkg(8) is the new package management tool for FreeBSD. It is now the only supported package management tool for FreeBSD releases from 10.0-RELEASE, including the upcoming 9.3-RELEASE. pkg(8) is available on all currently supported releases. Support for the legacy pkg_tools is due to be discontinued at the beginning of September 2014. The release of pkg(8) 1.3 is imminent. This includes major improvements in the dependency solver. Now we can: * Switch versions of, for example, Perl or PHP and resolve all the conflicts with packages that depend on them automatically. No more need to manually switch package origins. * Deal more gracefully with complex upgrade or install scenarios. * Sandbox operations dealing with freshly downloaded data until it can be verified as trustworthy by checking the package signature. * Deal with provides-and-requires style of dependencies, so for example we can say "this package needs to use a web server" and allow that dependency to be fulfilled by apache or nginx or any other alternative that provides web-server functionality. Beyond the next release, we have work in progress on allowing ranges of versions in dependency rules and handling a selection of "foreign" package repositories, such as CPAN or CTAN or PyPi. There are plans to use pkg(8) to package up the base system. Along with other benefits, this will allow writing a universal installer: download one installer image and from there install any available version of FreeBSD, including snapshots. We are also intending to use pkg(8) within the ports tree at package-build time to handle fulfilling build dependencies. This opens the possibility of installing build-dependencies by downloading binary packages, which means you can install a package with customized options with the minimum amount of time spent compiling anything else. Open tasks: 1. We are sorely lacking a comprehensive testing setup. Integrating automated regression testing into the development cycle is becoming an imperative. 2. We need testers who can run development versions of pkg in as many distinct types of use-cases as possible, and report feedback from their experiences to the freebsd-pkg@freebsd.org mailing list or our issues list on github. __________________________________________________________________ QEMU bsd-user-Enabled Ports Building URL: https://wiki.freebsd.org/QemuUserModeHowTo URL: http://dirty.ysv.freebsd.org/ URL: https://github.com/seanbruno/qemu-bsd-user Contact: Stacey Son Contact: Juergen Lock Contact: Sean Bruno The ports-mgmt/poudriere-devel port is capable of building ports via an emulator. Configuration of the miscellaneous binary image activator is required prior to a poudriere-devel run. ARMV6, MIPS32 and MIPS64 packages can be produced via full emulation. There are several packages that block a full run of builds. They can be viewed on the "Status of ports building" link. To build packages via emulation, on current or latest stable/10: Clone the github repository, and switch to the bsd-user branch. Then run: ./configure --static \ --target-list=3D"arm-bsd-user i386-bsd-user \ mips-bsd-user mips64-bsd-user mips64el-bsd-user \ mipsel-bsd-user ppc-bsd-user ppc64-bsd-user sparc-bsd-user \ sparc64-bsd-user x86_64-bsd-user" gmake; gmake install Then set up the binmiscctl tools to do some evil hackery to redirect execution of armv6 binaries to qemu: binmiscctl add armv6 --interpreter \ "/usr/local/bin/qemu-arm" --magic \ "\x7f\x45\x4c\x46\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02 \ \x00\x28\x00" --mask "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff \ \xff\xff\xff\xff\xfe\xff\xff\xff" --size 20 --set-enabled Install poudriere-devel from ports. It knows how to set up things. Create a poudriere jail to do all the magic: poudriere jail -c -j 11armv632 -m svn -a armv6 \ -v head Now run poudriere against that jail to build all the ports: poudriere bulk -j 11armv632 -a Nullfs mount the ports tree into the jail: mkdir /usr/local/poudriere/jails/11armv632/usr/ports mount -t nullfs /usr/ports /usr/local/poudriere/jails/11armv632/usr/ports To chroot into the jail: mount -t devfs devfs /usr/local/poudriere/jails/11armv632/dev chroot /usr/local/poudriere/jails/11armv632/ Open tasks: 1. PPC on AMD64 emulation. This is a work in progress as there appear to be some serious issues running the bsd-user binary on big-endian hardware. Justin Hibbits is working on this. 2. SPARC64 on AMD64 emulation is non-functional and instantly segfaults. We are looking for someone to poke at the bits here. 3. External Toolchain, XDEV support. There is partial support for using an AMD64 toolchain that can output binaries for other architecture (e.g., using an AMD64 toolchain to build MIPS64 packages). We are currently tracking a linking issue with ports-mgmt/pkg. Thanks to Warner Losh, Baptiste Daroussin, Dimitry Andric for poking at bits in here to make the XDEV target useful. 4. Signal handling. The MIPS/ARMV6 target stills display a failure that manifests itself when building devel/p5-Sys-SigAction. 5. Massive documentation update needed. These modifications actually allow chrooting into a MIPS or ARMv6 environment and using native toolchains and libraries to prototype software for a target platform. __________________________________________________________________ RPC/NFS and CTL/iSCSI Performance Optimizations Contact: Alexander Motin The FreeBSD RPC stack, used as a base for its NFS server, received multiple optimizations to improve performance and SMP scalability. Algorithmic optimizations reduced processing overhead, while improved locking allowed it to scale up to at least 40 processor cores without significant lock congestion. Combined with some other kernel optimizations, the peak NFS request rate increased by many times, reaching up to 600K requests per second on modern hardware. The CAM Target Layer (CTL), used as the base for the new kernel iSCSI server, also received a series of locking optimizations which allowed its peak request rate to increase from ~200K to ~600K IOPS with the potential of reaching a rate of 1M requests per second. That rate is sufficient to completely saturate 2x10Gbit Ethernet links with 4KB requests. For comparison, the port of net/istgt (user-level iSCSI server) on the same hardware with an equivalent configuration showed only 100K IOPS. There is also ongoing work on improving CTL functionality. It was already made to support three of four VMware VAAI storage acceleration primitives (net/istgt supports 2), while the goal is to reach full VAAI support during next months. With all these improvements, and earlier improvements in CAM, GEOM, ZFS, and a number of other kernel areas coming soon, FreeBSD 10.1 may become the fastest storage release ever. ;) These projects are sponsored by iXsystems, Inc. __________________________________________________________________ ZFSguru URL: http://zfsguru.com URL: http://zfsguru.com/news/stateoftheproject/2014 Contact: Jason Edwards ZFSguru is a multifunctional server appliance with a strong emphasis on storage. ZFSguru began as simple web-interface frontend to ZFS, but has since grown into a FreeBSD derivative with its own infrastructure. The scope of the project has also grown with the inclusion of add-on packages that add functionality beyond the traditional NAS functionality found in similar product like FreeNAS and NAS4Free. ZFSguru aims to be a true multifunctional server appliance that is extremely easy to setup and can unite both novice and more experienced users in a single user interface. The modular nature of the project combats the danger of bloat, whilst still allowing extended functionality to be easily deployed. Where development in the first quarter of this year brought drag-and-drop permissions for Samba and NFS, development in the second quarter focused on strengthening the infrastructure of the project. A new library and toolkit solution dubbed 'Mesa' is in the works, providing a cleaner foundation to the project. A new master server providing secure remote services is being setup, to be located in a high-speed datacenter. But most importantly, a new system build infrastructure has shown great progress and will soon be able to provide automated system builds to our users. This not only improves the frequency of system releases but also frees much developer time to be spent on different areas of the project. Furthermore, a new website and forum is being worked on, replacing the old-fashioned website that offers only limited functionality. The new website will be linked to the server database, providing real-time updates about the project. In addition, a new platform for collaborative development is in the works. A service addon has been created for the GitLab project, which is a drop-in replacement of the popular GitHub website. The choice was made to host our own solution and not rely on GitHub itself. In retrospect this appears to be a good decision. The recent development where GitHub removed projects after DCMA takedowns being sent is incompatible with the philosophy of free-flow-of-information, which the ZFSguru project is a strong proponent of. By hosting our own solution, we have avoided any dependency on third party projects. It is expected that after the infrastructure of the project has been revamped, work on the web-interface itself can continue. New functionality such as GuruDB and Service Bulletins provide a tighter connection between the server infrastructure and the web-interface. The Migration Manager is one of the last remaining features still missing in the web-interface. This functionality provides an easy way to upgrade the current system by performing a new clean installation, but migrate all relevant configuration to the new installation. It also allows to backup all system configuration in a single file to be stored on a different machine should things go awry. A longer version of this status report giving a wider perspective on the project can be found at the stateoftheproject link. __________________________________________________________________ PostgreSQL Performance Improvements URL: https://www.kib.kiev.ua/kib/pgsql_perf_v2.0.pdf Contact: Konstantin Belousov Analysis of the performance of the latest 9.3 version of PostgreSQL on FreeBSD-CURRENT has been performed. The issues which prevented good scalability on a 40-core machine were determined, and changes prototyped which solve the bottlenecks. The URL above provides a paper which contains a detailed explanation of the issues and solutions, together with a graph demonstrating the effects on scalability. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ Running FreeBSD as an Application on Top of the Fiasco.OC Microkernel URL: http://en.wikipedia.org/wiki/L4_microkernel_family URL: https://wiki.freebsd.org/201407DevSummit/BSDUserspace Contact: Ilya Bakulin Fiasco.OC belongs to the L4 microkernel family. A microkernel provides a bare minimum of services to the applications running on top of it, unlike traditional kernels that incorporate complex code like IP stacks and device drivers. This allows a dramatic decrease in the amount of code running in the privileged mode of the CPU, achieving higher security while still providing an acceptable level of performance. Running an operating system kernel on top of the microkernel allows leveraging any software that was developed for that operating system. The OS kernel runs in user-mode side-by-side with other microkernel applications such as real-time components. Multiple OSes, each with their userland applications, can even be run in parallel, thus allowing construction of products where processing of corporate data is strictly separated from the processing of private data. The project aims to create a port of FreeBSD to the Fiasco.OC microkernel, a high performance L4 microkernel developed by TU Dresden. Existing ports of OpenBSD and Linux are used as a reference. This will allow the use of unique FreeBSD features like ZFS in L4-based projects. Open tasks: 1. Finish opensourcing the port of L4OpenBSD/amd64 made by genua mbh. This is a work in progress. 2. Publish the sources of the L4FreeBSD port that is largely based on the L4OpenBSD code. 3. Improve the port, the first task being adopting the pmap(9) module to work with L4 microkernel memory allocation services. __________________________________________________________________ SDIO Driver URL: https://wiki.freebsd.org/SDIO URL: https://github.com/kibab/freebsd/tree/mmccam Contact: Ilya Bakulin SDIO is an interface designed as an extension of the existing SD card standard, which allows the connecting of different peripherals to a host with a standard SD controller. Peripherals currently sold on the general market include WLAN/BT modules, cameras, fingerprint readers, and barcode scanners. Additionally, SDIO is used to connect some peripherals in products like Chromebooks and Wandboards. A prototype of the driver for the Marvell SDIO WLAN/BT (Avastar 88W8787) module is also being developed, using the existing Linux driver as the reference. SDIO card detection and initialization already work. Most necessary bus methods are implemented and tested. The WiFi driver is able to load firmware onto the card and initialize it. A rewrite of the MMC stack as a transport layer for the CAM framework is in progress. This will allow utilization of the well-tested CAM locking model and debug features. Open tasks: 1. SDIO stack: finish CAM migration. The initialization of the MMC/SD card is implemented in the XPT layer, but cannot be tested with real hardware because of the lack of any device drivers that implement peripheral drivers and SIMs for CAM MMC. The plan is to use a modified version of the BeagleBone Black SDHCI controller driver for the SIM and a modified version of mmcsd(4) as a peripheral driver. 2. Marvell SDIO WiFi: connect to the FreeBSD network stack, write the code to implement required functions (such as sending/receiving data, network scanning and so on). __________________________________________________________________ TMPFS Stability Contact: Konstantin Belousov Contact: Peter Holm Extensive testing of tmpfs(5) using the stress2 kernel test suite was done. The issues found were debugged and fixed. Most of the problems are related to bugs in the interaction of the vnode and node lifetime, culminating in e.g., unmount races and dotdot lookup bugs. This project is sponsored by The FreeBSD Foundation. __________________________________________________________________ UEFI Boot URL: https://wiki.freebsd.org/UEFI URL: http://www.freebsd.org/snapshots/ Contact: Ed Maste Contact: Nathan Whitehorn The Unified Extensible Firmware Interface (UEFI) provides boot- and run-time services for x86 and other computers. For the x86 architecture it replaces the legacy BIOS. This project will adapt the FreeBSD loader and kernel boot process for compatibility with UEFI firmware, found on contemporary servers, desktops, and laptops. Ed and Nathan completed a number of integration tasks over the past three months. Nathan added a first-stage loader, boot1.efi, to support chain-loading the rest of the system from a UFS filesystem. This allows the UEFI boot process to proceed in a similar fashion as with BIOS boot. Nathan also added UEFI support to the FreeBSD installer and release image creation script. The EFI framebuffer requires the vt(4) system console -- a framebuffer driver is not implemented for the legacy syscons(4) console. Ed added automatic vt(4) selection to the UEFI boot path. Snapshots are now built as dual-mode images, and should boot via both BIOS and UEFI. Our plan is to merge the UEFI and vt(4) work to stable/10 to appear in FreeBSD 10.1-RELEASE. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Document manual installation, including dual-boot configurations. 2. Implement boot1.efi for ZFS file systems. 3. Add support for UEFI variables stored in non-volatile memory (NVRAM). 4. Debug boot failures with certain UEFI firmware implementations. 5. Support secure boot. __________________________________________________________________ Updated vt(4) System Console URL: https://wiki.freebsd.org/Newcons Contact: Aleksandr Rybalko Contact: Ed Maste Contact: Ed Schouten Contact: Warren Block The vt(4) (aka Newcons) project provides a replacement for the legacy syscons system console. It brings a number of improvements, including better integration with graphics modes and broader character set support. Since the last report, vt(4) gained the ability to make early driver selection. vt(4) selects the best successfully-probed driver before most other kernel subsystems are initialized. Also, to facilitate migration from syscons(4) to vt(4), multiple virtual terminal subsystems in the kernel are now supported. It is controlled by a small module with just one kernel environment variable. Users can select the virtual terminal system to use by setting kern.vty=3Dsc or kern.vty=3Dvt. The GENERIC kernel configuration for the amd64 and i386 platforms now includes both syscons(4) and vt(4) by default. This configuration is also planned to be in FreeBSD 10.1-RELEASE. The project finally received a man page, so now vt(4) is not only the project name, but also a link to its documentation. Great thanks to Warren Block for that. Major highlights: * Unicode support. * Double-width character support for CJK characters. * xterm(1)-like terminal emulation. * Support for Kernel Mode Setting (KMS) drivers (i915kms, radeonkms). * Support for different fonts per terminal window. * Simplified drivers. Brief status of supported architectures and hardware: * amd64 (VGA/i915kms/radeonkms) -- works. * ARM framebuffer -- works. * i386 (VGA/i915kms/radeonkms) -- works. * IA64 -- untested. * MIPS -- untested. * PPC and PPC64 -- work, but without X.Org yet. * SPARC -- works on certain hardware (e.g., Ultra 5). * vesa(4) -- in progress. * i386/amd64 nVidia driver -- not supported. VGA should be used (VESA planned). * Xbox framebuffer driver -- will be deleted as unused. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Implement the remaining features supported by vidcontrol(1). 2. Write manual pages for vt(4) drivers and kernel interfaces. 3. Support direct handling of keyboard by the kbd device (without kbdmux(4)). 4. CJK fonts. (This is in progress). 5. Address performance issues on some architectures. 6. Switch to vt(4) by default. 7. Convert keyboard maps for use with vt(4). 8. Implement compatibility mode to be able to use single-byte charsets/key-codes in vt(4). __________________________________________________________________ FreeBSD/arm64 URL: http://svnweb.freebsd.org/base/projects/arm64/ Contact: Andrew Turner Arm64 is the name of the in-progress port of FreeBSD to the ARMv8 CPU when it is in AArch64 mode. Until recently, all ARM CPU designs were 32-bit only. With the introduction of the ARMv8 architecture, ARM has added a new 64-bit mode. This new mode has been named AArch64. Booting FreeBSD on the ARM Foundation Model has made a lot of progress since the last status report. An initial pmap implementation has been written. With this, FreeBSD is able to enter the Machine Independent boot code. The required autoconf functions have been added allowing FreeBSD to start scheduling tasks. Finally the cpu_switch and copystr functions were added. With these two, FreeBSD will boot to the mountroot prompt. Work has started on supporting exceptions, including interrupts. This will allow more developers to start working on device drivers. Open tasks: 1. Finish exception and interrupt handling 2. Read the Device Tree or ACPI tables from UEFI 3. Test on real hardware __________________________________________________________________ FreeBSD Python Ports URL: https://wiki.FreeBSD.org/Python URL: irc://freebsd-python@irc.freenode.net Contact: FreeBSD Python Team We are pleased to announce the availability of conflict-free Python package support across different Python versions based on the USES=3Duniquefiles feature recently introduced to the Ports framework. A Python package can be marked as buildable and installable in parallel for different Python versions at the same time on the same host. The package building tools, however, do not support this feature yet and the Python team will work closely with portmgr and the pkg developers to enable support on a global ports and packages scale. In May and June a huge clean-up operation took place to remove the last bits and pieces targeting easy_install. In the beginning of July we committed the final changes to remove easy_install support completely from the ports framework. This greatly simplifies the infrastructure and allows us to modernize and maintain it with less effort. We added Python 3.4, removed Python 3.1 after its end of life, updated the setuptools ports to version 5.1 and PyPy's development version to 2.3.1. The latest Python 2.7.8 and an updated setuptools will hit the tree shortly. Our upstreaming effort continues to produce good outcomes for simplifying maintenance and reducing complexity. Looking forward, one of the top priorities is to comply with the USES framework in the foreseeable future and to roll out a consistent maintainer policy for integrating new Python-related ports into the tree. Open tasks: 1. Migrate bsd.python.mk to the Uses framework. 2. Develop a high-level and lightweight Python Ports Policy. 3. Add support for granular dependencies (for example >=3D1.0,<2.0). 4. See what adding pip (Python Package Index) support will require. 5. Add default QA targets and functions for Python ports (TEST_DEPENDS, regression-test, etc.) 6. More tasks can be found on the team's wiki page (see links). 7. To get involved, come and say "hi" on IRC and let us know what you are interested in! __________________________________________________________________ KDE/FreeBSD URL: http://FreeBSD.kde.org URL: http://FreeBSD.kde.org/area51.php Contact: KDE/FreeBSD Team The KDE/FreeBSD team has continued to improve the experience of KDE software and Qt under FreeBSD. During this quarter, the team has kept most of the KDE and Qt ports up-to-date, working on the following releases: * KDE SC: 4.12.5; Workspace: 4.11.9 As a result -- according to PortScout -- kde@ has 526 ports (up from 526), of which 84.63% are up-to-date (down from 98.86%). iXsystems Inc. continues to provide a machine for the team to build packages and to test updates. iXsystems Inc. has been providing the KDE/FreeBSD team with support for quite a long time and we are very grateful for that. As usual, the team is always looking for more testers and porters so please contact us at kde@FreeBSD.org and visit our home page at http://FreeBSD.kde.org. It would be especially useful to have more helping hands on tasks such as getting rid of the dependency on the defunct HAL project and providing integration with KDE's Bluedevil Bluetooth interface. Open tasks: 1. Updating out-of-date ports, see PortScout for a list 2. Removing the dependency on HAL __________________________________________________________________ The Graphics Stack on FreeBSD URL: https://wiki.freebsd.org/Graphics URL: http://lists.freebsd.org/pipermail/freebsd-announce/2014-July/00157= 0.ht ml URL: http://trillian.chruetertee.ch/ports/browser/trunk Contact: FreeBSD Graphics team We were generally short on time this quarter. We made less progress than expected on all fronts. The alternate pkg(8) repository, built with WITH_NEW_XORG, is now available. This alleviates the need for users to rebuild their ports with WITH_NEW_XORG. See the announcement, linked above for further information. Thanks to a contribution from Jan Kokem=C3=BCller, Radeon 32bit ioctls a= re now working on 64bit hosts. This was tested successfully with Wine and StarCraft II on FreeBSD 9.x and 11. This required modifications to emulators/i386-wine-devel so that it works with WITH_NEW_XORG, and the creation of a new port, libtxc_dxtn, to support the texture compression used by StarCraft II. We have not yet had the time to polish everything, so this still requires manual steps. The DRM generic code update is ready, but it breaks the current i915 driver. Therefore, the i915 driver must be updated before anything is committed. Compared to the previous status report, OpenCL test programs are running fine now, thanks to upgrades and fixes to libc++ and Clang. The relevant ports are still not ready to hit the ports tree, unfortunately. Open tasks: 1. See the "Graphics" wiki page for up-to-date information. __________________________________________________________________ Quarterly Status Reports Contact: Quarterly Status Report Team These quarterly status reports help the FreeBSD community stay up-to-date with the happenings in and around the project. Updates from FreeBSD teams, new features being developed in- or out-of-tree, products derived from FreeBSD, and FreeBSD events are all welcome additions to the status reports. The Monthly team has been busy since the last report, with longtime organizer G=C3=A1bor P=C3=A1li having stepped down from the team -- than= k you G=C3=A1bor for all your hard work! This has left something of a void in = the preparation of this report, for which the call for items was issued quite late. To help fill the void, Warren Block and Benjamin Kaduk have been added to the monthly@ team, joining Glen Barber, Gavin Atkinson, Ed Maste, and the rest of the team in preparing this report. Special thanks to Glen for doing most of the work while simultaneously getting 9.3-RELEASE out the door! The next cycle is sooner than you think! The deadline for submitting entries for the Q3 report is October 7th, 2014. This project is sponsored by The FreeBSD Foundation. Open tasks: 1. Submit reports for Q42014 to monthly@FreeBSD.org! __________________________________________________________________ FreeBSD Host Support for OpenStack and OpenContrail URL: http://www.openstack.org URL: http://www.opencontrail.org URL: https://github.com/Semihalf/openstack-devstack URL: https://github.com/Semihalf/openstack-nova URL: https://github.com/Semihalf/contrail-vrouter URL: https://blueprints.launchpad.net/nova/+spec/freebsd-compute-node Contact: Grzegorz Bernacki Contact: Michal Dubiel Contact: Dominik Ermel Contact: Rafal Jaworowski OpenStack is a cloud operating system that controls large pools of compute, storage, and networking resources in a datacenter. OpenContrail is a network virtualization (SDN) solution comprising network controller, virtual router, and analytics engine, which can be integrated with cloud orchestration systems like OpenStack or CloudStack. The goal of this work is to enable FreeBSD as a fully supported compute host for OpenStack using OpenContrail virtualized networking. The main areas of development are: * Libvirt hypervisor driver for bhyve. * Support for bhyve (via libvirt compute driver) and the overall FreeBSD platform in nova-compute. * OpenContrail vRouter (forwarding plane kernel module) port to FreeBSD. * OpenContrail Agent (network controller node) port to FreeBSD. * Integration and performance optimizations. Since the last report the following items have been completed, which allow for a working demo of an OpenStack compute node on a FreeBSD host using OpenContrail for network virtualization: * Port of the OpenContrail vRouter kernel module for FreeBSD (MPLS over GRE mode only) * Port of the OpenContrail Agent for FreeBSD * FreeBSD version of a Devstack installation/configuration script with support for the OpenContrail solution (Compute node components only) A demo was presented at the DevSummit during BSDCan2014 in Ottawa. Also, a meetup regarding the subject was organized in Krakow, Poland. Work on this project is sponsored by Juniper Networks. __________________________________________________________________ The FreeBSD Foundation URL: http://www.FreeBSDFoundation.org/ URL: http://freebsdjournal.com/ Contact: Deb Goodkin The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Most of the funding is used to support FreeBSD development projects, conferences and developer summits, purchase equipment to grow and improve the FreeBSD infrastructure, and provide legal support for the Project. We published our third issue of the FreeBSD Journal. We have over 2700 subscriptions so far. We continued working on the digital edition, which will allow subscribers to read the magazine in different web browsers, including those than run on FreeBSD. This will be available for the July/August issue of the Journal. We hired Anne Dickison, on a freelance basis, as our new marketing director, to help us promote the Foundation and Project. The annual board meeting was held in Ottawa, Canada, in May. Directors and officers were elected, and we did some long-term planning. We worked on our vision, core values, project road mapping, and our near-term goals. We also met with the core team to discuss roles and responsibilities, project roadmapping, and what we can do to help the Project more. We were a Gold+ sponsor for BSDCan, May 16-17 and provided 7 travel grants for developers to attend the conference. We also were the sponsor for both the developer and vendor summits. Justin Gibbs gave a FreeBSD presentation at a FreeBSD user's internal technology summit. Company visits like this help users understand the Project structure better and gives us a chance to communicate what FreeBSD people are working on as well as learn what different companies are doing with FreeBSD, as well as what they'd like to see supported. We can then help facilitate collaboration between the companies and FreeBSD developers. We were represented at Great Wide Open, April 2-3 (greatwideopen.org), Texas LinuxFest, June 13-14 (texaslinuxfest.org), and SouthEast LinuxFest, June 20-22 (southeastlinuxfest.org). Hardware was purchased to support an upgrade at Sentex. A new high-capacity 1Gbps switch was deployed to allow for more systems to be added to the test lab. The main file server and development box was upgraded to allow more users in the lab simultaneously. We purchased hardware, including package builders, and a larger server to allow NYI to be a full replica of all Project systems, comparable to what is in place at Yahoo Inc. and ISC. We worked with our lawyer to create an NDA between the Foundation and individuals for third party NDAs. This allows developers who need access to proprietary documents, to go through the Foundation, via an NDA for access. FreeBSD Foundation Systems Administrator and Release Engineer, Glen Barber, continued work on producing regularly-updated FreeBSD/arm snapshots for embedded devices, such as the Raspberry Pi, ZedBoard, and BeagleBone. In addition to producing weekly development snapshots from the head/ and stable/ branches, with feedback and help from Ed Maste, Glen finished work to produce release images that will, by default, provide debugging files for userland and kernel available on the FreeBSD Project FTP mirrors. Note that the debugging files will not be included on the bootonly.iso, disc1.iso, or dvd1.iso images due to the size of the resulting images. Foundation staff member Konstantin Belousov completed an investigation into poor performance of PostgreSQL on FreeBSD. This uncovered scalability problems in the FreeBSD kernel, and changes to address these issues are in progress. Some previously completed Foundation-sponsored projects received enhancements or additional work. The ARM superpages project was completed last year, but is now enabled by default in FreeBSD-CURRENT. Many stability fixes and enhancements have been committed to the in-kernel iSCSI stack. The iSCSI project was released in FreeBSD 10.0. Many stability fixes and enhancements have been committed and will be included in FreeBSD 10.1. Work continues on the Foundation-sponsored autofs automount daemon, UEFI boot support, the updated vt(4) system video console, virtual machine images, and the Intel graphics driver update. Foundation-sponsored work resulted in 226 commits to FreeBSD over the April to June period. __________________________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJT0VGRAAoJELls3eqvi17QF0UP/iPhYcVNJ2WUJS3rZ9MPCPHj EfN3DLsOMCO54YWEIUnQqZTR0ist9HjUaSbyLfTIM9j4xmwvz2Z6JWiMvg8Ui8QC 6EuLjLOKvlwaj4F9/OMu5mrOpYeXtwZOS5KgeYN+yq9sBXV3mzMe8yhzIT6zTGNM akRhbVqJiQRKnwF4T15PML/AJ9ihrfYqz3j3veocelWDyuEG2LOpJQj1zfUXX2f8 YdCDSi/6bNmNoh95Nf7+F7Uj+R7EvYHZ5SdvO9eUk/ET/J4x/JAXcxwms/ars2wX LsJjVZS9vLVCvb82HADb6tWAUCi02hHy0vUxxKj2E9u113Nq2Ecws2kSdnaIEfJp jFUE3y5/VWnCKOGXgF3T4iB20M+i/nqOQStnY33fq5Dr36LlHvVpLNCF9XjRs+IN p6O8aDOnl8etil+Z2w6IWeth/D6la8a2+4xEP3/l/d9VHParchoKUcA44RFM/k8D MNz/+fQurkaLZXEQUlr9oB/QRuZ6t54pT/rD1Nu40/kvnoS+Ss8JdN1VzcdBe5b1 hehkxxZ1/GmxSp2YcdeQVfK86YE+323izsa4fBjvx/6z+Zo3C2dIV2mgBuoz1mQd U5G/a1DOcVHGqBO7xUVlgwEr1c2pTARmRBEU5rkehibqkznG5QFfj83k3j3Mvx0N P9kkcHSgEgy40srydzLq =3D3eLh -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 18:37:23 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11409DDC for ; Thu, 24 Jul 2014 18:37:23 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8E7E72918 for ; Thu, 24 Jul 2014 18:37:22 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s6OIbKhl060521; Thu, 24 Jul 2014 20:37:20 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 4569635EE; Thu, 24 Jul 2014 20:37:20 +0200 (CEST) Message-ID: <53D1525F.8090902@omnilan.de> Date: Thu, 24 Jul 2014 20:37:19 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: panic/lock on 9.3-RELEASE with nullfs/nfs/zfs combination References: <53D12973.3010805@omnilan.de> <20140724165917.GT93733@kib.kiev.ua> In-Reply-To: <20140724165917.GT93733@kib.kiev.ua> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig73A5EC3D8AB91333AA3DB067" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Thu, 24 Jul 2014 20:37:20 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:37:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig73A5EC3D8AB91333AA3DB067 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Konstantin Belousov's Nachricht vom 24.07.2014 18:59 (localtime): > =E2=80=A6 >> panic: LK_RETRY set with incompatible flags (0x200400) or an error >> occured (11) >> cpuid =3D 3 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame >> 0xffffff82e54bcc70 >> kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff82e54bcd30 >> panic() at panic+0x1cd/frame 0xffffff82e54bce30 >> _vn_lock() at _vn_lock+0x67/frame 0xffffff82e54bce90 >> zfs_lookup() at zfs_lookup+0x420/frame 0xffffff82e54bcf20 >> zfs_freebsd_lookup() at zfs_freebsd_lookup+0xa6/frame 0xffffff82e54bd0= 70 >> VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xd8/frame 0xffffff82e5= 4bd0a0 >> vfs_cache_lookup() at vfs_cache_lookup+0xff/frame 0xffffff82e54bd110 >> VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xd8/frame 0xffffff82e54bd140 >> null_lookup() at null_lookup+0x92/frame 0xffffff82e54bd1c0 >> VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xd8/frame 0xffffff82e54bd1f0 >> lookup() at lookup+0x389/frame 0xffffff82e54bd290 >> namei() at namei+0x3df/frame 0xffffff82e54bd340 >> vn_open_cred() at vn_open_cred+0x1e2/frame 0xffffff82e54bd4b0 >> vop_stdvptocnp() at vop_stdvptocnp+0x1af/frame 0xffffff82e54bd7e0 >> null_vptocnp() at null_vptocnp+0xf5/frame 0xffffff82e54bd850 >> VOP_VPTOCNP_APV() at VOP_VPTOCNP_APV+0xdb/frame 0xffffff82e54bd880 >> vn_vptocnp_locked() at vn_vptocnp_locked+0x15b/frame 0xffffff82e54bd91= 0 >> vn_fullpath1() at vn_fullpath1+0x100/frame 0xffffff82e54bd970 >> kern___getcwd() at kern___getcwd+0xd4/frame 0xffffff82e54bd9d0 >> amd64_syscall() at amd64_syscall+0x318/frame 0xffffff82e54bdaf0 >> Xfast_syscall() at Xfast_syscall+0xf7/frame 0xffffff82e54bdaf0 >> --- syscall (326, FreeBSD ELF64, sys___getcwd), rip =3D 0x8011a191c, r= sp =3D >> 0x7fffffffe658, rbp =3D 0x801873400 --- >> KDB: enter: panic >> [ thread pid 1905 tid 100856 ] >> Stopped at kdb_enter+0x3b: movq $0,0x642172(%rip) >> >> Like mentioned, this panic happens only if a nfs(v4) client visits fs1= 5 >> (the exported and nullfs_mounted fs) and I try to rw-open any file on >> the nullfs afterwards!!! >> >> How can I provide useful info with KDB? I don't have a dumpdev availab= le >> in that machine??? >> http://www.es.freebsd.org/doc/en/books/developers-handbook/kerneldebug= -gdb.html >> seems not applicaple, no /var/crash/?*??? >> > The lockmgr flags are LK_SHARE | LK_RETRY, and error 11 =3D=3D EDEADLK > indicates that the lock is already taken by the curthread in the > exclusive mode. I am interested in what line of code did the locking. > > Add ddb, INVARIANTS, WITNESS and DEBUG_VFS_LOCKS options to the kernel > config, reproduce the issue and, after the panic occured and you > get at the ddb prompt, issue command 'show alllocks'. > > Also, do 'show mount', after which do 'show mount ', where = > is the address of your nullfs mount point, printed by 'show mount'. > > I need all console output starting from the panic message. Maybe it's of any use for you: (kgdb) backtrace #0 doadump (textdump=3D1) at /usr/local/share/deploy-tools/RELENG_9_3/src/sys/kern/kern_shutdown.c:271= #1 0xffffffff804aa198 in kern_reboot (howto=3D260) at /usr/local/share/deploy-tools/RELENG_9_3/src/sys/kern/kern_shutdown.c:454= #2 0xffffffff804a9bd5 in panic (fmt=3D0x104
= ) at /usr/local/share/deploy-tools/RELENG_9_3/src/sys/kern/kern_shutdown.c:= 642 #3 0xffffffff8055dcd7 in _vn_lock (vp=3D0xfffffe002dc119d8, flags=3D20981= 76, file=3D, line=3D) at /usr/local/share/deploy-tools/RELENG_9_3/src/sys/kern/vfs_vnops.c:1402= #4 0xffffffff80fb8c90 in u8_decomp_b4_tbl () from /boot/kernel/zfs.ko #5 0xfffffe0007ac0b00 in ?? () #6 0x0000000081051480 in ?? () #7 0xffffff82e5660598 in ?? () #8 0xffffff82e5660180 in ?? () #9 0x0000000081050c88 in ?? () #10 0xfffffe002d37c0e8 in ?? () #11 0xffffffff80a8f940 in sdt_vfs_vop_vop_unlock_return () #12 0xfffffe002dc119d8 in ?? () #13 0x0000000900000000 in ?? () #14 0x000000002dcaa0c0 in ?? () #15 0x000001e8e565ff20 in ?? () #16 0xffffff82e565ff40 in ?? () #17 0xffffff82e5660598 in ?? () #18 0xffffff82e56600b0 in ?? () #19 0xffffff82e5660180 in ?? () #20 0xffffff82e56600b0 in ?? () #21 0xffffff82e5660070 in ?? () #22 0xffffffff80fb8e36 in u8_decomp_b4_tbl () from /boot/kernel/zfs.ko #23 0xfffffe00ba802920 in ?? () #24 0xfffffe0000000000 in ?? () #25 0x0000000000002e2e in ?? () #26 0x0000000000000000 in ?? () (kgdb) up 10 #10 0xfffffe002d37c0e8 in ?? () (kgdb) list 1402 KASSERT((flags & LK_RETRY) =3D=3D 0 || error =3D=3D 0, 1403 ("LK_RETRY set with incompatible flags (0x%x) or an error occured (%d)", 1404 flags, error)); 1405 /* 1406 * Callers specify LK_RETRY if they wish to get dead vnodes. 1407 * If RETRY is not set, we return ENOENT instead. 1408 */ 1409 if (error =3D=3D 0 && vp->v_iflag & VI_DOOMED && 1410 (flags & LK_RETRY) =3D=3D 0) { 1411 VOP_UNLOCK(vp, 0); Just tellme if you need anything else, hav vmcore in kgdb available! Thanks, -Harry --------------enig73A5EC3D8AB91333AA3DB067 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlPRUl8ACgkQLDqVQ9VXb8h8xwCgipONw2/yv8Oc6+3lTTCv+m7O 16EAn2oFyUuqjbpzJKYQC5gkRk5AsR8v =LY9M -----END PGP SIGNATURE----- --------------enig73A5EC3D8AB91333AA3DB067-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 19:15:32 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1877D92 for ; Thu, 24 Jul 2014 19:15:32 +0000 (UTC) Received: from mail.egr.msu.edu (gribble.egr.msu.edu [35.9.37.169]) by mx1.freebsd.org (Postfix) with ESMTP id 7A9162E1D for ; Thu, 24 Jul 2014 19:15:31 +0000 (UTC) Received: from gribble (localhost [127.0.0.1]) by mail.egr.msu.edu (Postfix) with ESMTP id 1B7474B78C for ; Thu, 24 Jul 2014 15:15:25 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mail.egr.msu.edu ([127.0.0.1]) by gribble (gribble.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQ8VwtHJrCzk for ; Thu, 24 Jul 2014 15:15:24 -0400 (EDT) Received: from EGR authenticated sender Message-ID: <53D15B4C.40104@egr.msu.edu> Date: Thu, 24 Jul 2014 15:15:24 -0400 From: Adam McDougall User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: link_elf_obj: symbol icl_pdu_new_bhs undefined References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 19:15:32 -0000 On 07/24/2014 11:45, Jimmy Olgeni wrote: > > Hi, > > Is anybody seeing anything like this on recent stable/10? > > $ sudo service ctld restart > ctld not running? (check /var/run/ctld.pid). > kldload: an error occurred while loading the module. Please check > dmesg(8) for more details. > /etc/rc.d/ctld: WARNING: Unable to load kernel module ctl > /etc/rc.d/ctld: WARNING: failed precmd routine for ctld > > $ dmesg > [...] > link_elf_obj: symbol icl_pdu_new_bhs undefined > linker_load_file: Unsupported file type > > -- > jimmy Yes, someone on irc ran into it, I confirmed it with -stable, and someone beat me to filing a bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192031 From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 19:30:55 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E1E381B7 for ; Thu, 24 Jul 2014 19:30:55 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 691B12F56 for ; Thu, 24 Jul 2014 19:30:55 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s6OJUnE7034040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2014 22:30:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s6OJUnE7034040 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s6OJUn1D034038; Thu, 24 Jul 2014 22:30:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 24 Jul 2014 22:30:48 +0300 From: Konstantin Belousov To: Harald Schmalzbauer Subject: Re: panic/lock on 9.3-RELEASE with nullfs/nfs/zfs combination Message-ID: <20140724193048.GU93733@kib.kiev.ua> References: <53D12973.3010805@omnilan.de> <20140724165917.GT93733@kib.kiev.ua> <53D1503B.2030200@omnilan.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aw451JwZw0N/VzGo" Content-Disposition: inline In-Reply-To: <53D1503B.2030200@omnilan.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 19:30:56 -0000 --aw451JwZw0N/VzGo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 24, 2014 at 08:28:11PM +0200, Harald Schmalzbauer wrote: > Bez??glich Konstantin Belousov's Nachricht vom 24.07.2014 18:59 > (localtime): > > ??? > > The lockmgr flags are LK_SHARE | LK_RETRY, and error 11 =3D=3D EDEADLK > > indicates that the lock is already taken by the curthread in the > > exclusive mode. I am interested in what line of code did the locking. > > > > Add ddb, INVARIANTS, WITNESS and DEBUG_VFS_LOCKS options to the kernel > > config, reproduce the issue and, after the panic occured and you > > get at the ddb prompt, issue command 'show alllocks'. > > > > Also, do 'show mount', after which do 'show mount ', where > > is the address of your nullfs mount point, printed by 'show mount'. > > > > I need all console output starting from the panic message. >=20 > FreeBSD/amd64 (mira.inop.mo1.omnilan.net) (ttyu0) >=20 > login: panic: LK_RETRY set with incompatible flags (0x200400) or an > error occured (11) > cpuid =3D 1 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame > 0xffffff82e565fc70 > kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff82e565fd30 > panic() at panic+0x1cd/frame 0xffffff82e565fe30 > _vn_lock() at _vn_lock+0x77/frame 0xffffff82e565fe90 > zfs_lookup() at zfs_lookup+0x420/frame 0xffffff82e565ff20 > zfs_freebsd_lookup() at zfs_freebsd_lookup+0xa6/frame 0xffffff82e5660070 > VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0x102/frame > 0xffffff82e56600a0 > vfs_cache_lookup() at vfs_cache_lookup+0xff/frame 0xffffff82e5660110 > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x102/frame 0xffffff82e5660140 > null_lookup() at null_lookup+0x92/frame 0xffffff82e56601c0 > VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x102/frame 0xffffff82e56601f0 > lookup() at lookup+0x32f/frame 0xffffff82e5660290 > namei() at namei+0x3df/frame 0xffffff82e5660340 > vn_open_cred() at vn_open_cred+0x1e2/frame 0xffffff82e56604b0 > vop_stdvptocnp() at vop_stdvptocnp+0x1af/frame 0xffffff82e56607e0 > null_vptocnp() at null_vptocnp+0xf5/frame 0xffffff82e5660850 > VOP_VPTOCNP_APV() at VOP_VPTOCNP_APV+0x105/frame 0xffffff82e5660880 > vn_vptocnp_locked() at vn_vptocnp_locked+0x15b/frame 0xffffff82e5660910 > vn_fullpath1() at vn_fullpath1+0x100/frame 0xffffff82e5660970 > kern___getcwd() at kern___getcwd+0xd4/frame 0xffffff82e56609d0 > amd64_syscall() at amd64_syscall+0x318/frame 0xffffff82e5660af0 > Xfast_syscall() at Xfast_syscall+0xf7/frame 0xffffff82e5660af0 > --- syscall (326, FreeBSD ELF64, sys___getcwd), rip =3D 0x8011a191c, rsp = =3D > 0x7fffffffe658, rbp =3D 0x801873400 --- > KDB: enter: panic > [ thread pid 1918 tid 100919 ] > Stopped at kdb_enter+0x3b: movq $0,0x645622(%rip) > db> show alllocks > db> Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B30A57E0 for ; Thu, 24 Jul 2014 20:51:23 +0000 (UTC) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C3D92738 for ; Thu, 24 Jul 2014 20:51:23 +0000 (UTC) Received: from pmather.tower.lib.vt.edu (pmather.tower.lib.vt.edu [128.173.51.28]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 320553EF for ; Thu, 24 Jul 2014 16:41:53 -0400 (EDT) From: Paul Mather Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Bhyve on AMD CPUs under 10-STABLE? Message-Id: <7F88A9D9-FA25-45C2-9AA1-C637DA7D9057@gromit.dlib.vt.edu> Date: Thu, 24 Jul 2014 16:41:52 -0400 To: freebsd-stable Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 20:51:23 -0000 Does bhyve work on AMD CPUs under 10-STABLE? I rebuilt my system=20 yesterday (to r269010) but the bhyve module does not appear to load=20 properly. I get this on the console when I kldload vmm: =3D=3D=3D=3D=3D amdv_init: not implemented amdv_cleanup: not implemented module_register_init: MOD_LOAD (vmm, 0xffffffff81c1a590, 0) error 6 =3D=3D=3D=3D=3D The system has a 6-core AMD FX-6300 CPU: =3D=3D=3D=3D=3D FreeBSD 10.0-STABLE #0 r269010: Wed Jul 23 08:25:27 EDT 2014 paul@chumby.chumby.lan:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 CPU: AMD FX(tm)-6300 Six-Core Processor (3515.86-MHz = K8-class CPU) Origin =3D "AuthenticAMD" Id =3D 0x600f20 Family =3D 0x15 Model =3D = 0x2 Stepping =3D 0 = Features=3D0x178bfbff = Features2=3D0x3e98320b AMD Features=3D0x2e500800 AMD = Features2=3D0x1ebbfff Structured Extended Features=3D0x8 TSC: P-state invariant, performance statistics real memory =3D 8589934592 (8192 MB) avail memory =3D 8225202176 (7844 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <042713 APIC1042> FreeBSD/SMP: Multiprocessor System Detected: 6 CPUs FreeBSD/SMP: 1 package(s) x 6 core(s) [[...]] =3D=3D=3D=3D=3D It has the POPCNT feature, which is the one the bhyve documentation=20 says to look for. Does bhyve only work on Intel CPUs for now? Does anyone have it=20 working on an AMD FX-6300-based 10-STABLE system? Cheers, Paul.= From owner-freebsd-stable@FreeBSD.ORG Thu Jul 24 21:38:24 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 21161AB0 for ; Thu, 24 Jul 2014 21:38:24 +0000 (UTC) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D28C52B42 for ; Thu, 24 Jul 2014 21:38:22 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id v10so3628204qac.5 for ; Thu, 24 Jul 2014 14:38:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=7hK0lBh5+5GoGHhcT43twUDY30PcsPrX1o9ektwcwUM=; b=eaMteLJXxmP4cKM24dGenLT8SC0v+hT76MK0xmp2q58Dw7C3/3pwis6gk+OHefp4If YdyVlj4+MWZVPe0FaR/NWNjoaJkeGqffWooIHjImQJZTpUMKztcPjwQq/RYdvJLJwFrN xO4gr/mj/Fdy8H8s7doOA4tBEN+hoInHcsDB6uXyWhlNzov2sILYf1iVV1EBDRkv8uBu VeOhA1HmBIvDIWZQmUtq/SXZ6x3YSCuq/fuIaG67//ftJHk3NH0H+tB7Q8v7MMrve3nm AeMZhLk2qgitJnQSsVmBxQUpK5WxqWIh/YUmN0qsftmz25dL81GM6kWkesCcTcVH7RTG mIAA== X-Gm-Message-State: ALoCoQnuqoNpeDm5pr0kWWR9pDGUZGm/dAgnft7Oa0Jq6trnPxLMtLp115WBssnthOkhjOqKgZVx X-Received: by 10.224.103.134 with SMTP id k6mr20429407qao.24.1406237902026; Thu, 24 Jul 2014 14:38:22 -0700 (PDT) Received: from [97.1.116.31] (31.sub-97-1-116.myvzw.com. [97.1.116.31]) by mx.google.com with ESMTPSA id a60sm8537609qge.30.2014.07.24.14.38.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 14:38:20 -0700 (PDT) References: <7F88A9D9-FA25-45C2-9AA1-C637DA7D9057@gromit.dlib.vt.edu> Mime-Version: 1.0 (1.0) In-Reply-To: <7F88A9D9-FA25-45C2-9AA1-C637DA7D9057@gromit.dlib.vt.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3E657A77-63D9-40EF-8BD0-1247621E6AE0@longcount.org> X-Mailer: iPhone Mail (11D257) From: Mark Saad Subject: Re: Bhyve on AMD CPUs under 10-STABLE? Date: Thu, 24 Jul 2014 17:32:21 -0400 To: Paul Mather Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 21:38:24 -0000 > On Jul 24, 2014, at 4:41 PM, Paul Mather wrote: >=20 > Does bhyve work on AMD CPUs under 10-STABLE? =20 No there is work being done on head and on out of tree on 10-stable . The l= ast snapshot I knew of was at http://mirrors.nycbug.org/pub/bhyve .=20 > I rebuilt my system=20 > yesterday (to r269010) but the bhyve module does not appear to load=20 > properly. I get this on the console when I kldload vmm: >=20 > =3D=3D=3D=3D=3D > amdv_init: not implemented > amdv_cleanup: not implemented > module_register_init: MOD_LOAD (vmm, 0xffffffff81c1a590, 0) error 6 > =3D=3D=3D=3D=3D > The system has a 6-core AMD FX-6300 CPU: >=20 > =3D=3D=3D=3D=3D > FreeBSD 10.0-STABLE #0 r269010: Wed Jul 23 08:25:27 EDT 2014 > paul@chumby.chumby.lan:/usr/obj/usr/src/sys/GENERIC amd64 > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 > CPU: AMD FX(tm)-6300 Six-Core Processor (3515.86-MHz K8-class= CPU) > Origin =3D "AuthenticAMD" Id =3D 0x600f20 Family =3D 0x15 Model =3D 0x= 2 Stepping =3D 0 > Features=3D0x178bfbff > Features2=3D0x3e98320b > AMD Features=3D0x2e500800 > AMD Features2=3D0x1ebbfff > Structured Extended Features=3D0x8 > TSC: P-state invariant, performance statistics > real memory =3D 8589934592 (8192 MB) > avail memory =3D 8225202176 (7844 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: <042713 APIC1042> > FreeBSD/SMP: Multiprocessor System Detected: 6 CPUs > FreeBSD/SMP: 1 package(s) x 6 core(s) > [[...]] > =3D=3D=3D=3D=3D >=20 > It has the POPCNT feature, which is the one the bhyve documentation=20 > says to look for. >=20 > Does bhyve only work on Intel CPUs for now? Does anyone have it=20 > working on an AMD FX-6300-based 10-STABLE system? >=20 > Cheers, >=20 > Paul. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" Mark saad | mark.saad@longcount.org=20= From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 00:15:10 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CEA7ED04 for ; Fri, 25 Jul 2014 00:15:10 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 946262984 for ; Fri, 25 Jul 2014 00:15:10 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQEAHKg0VODaFve/2dsb2JhbABRCBaDSlcEgnTGPwqHRQGBJneEAwEBAQMBAQIgVhsOCgICDRkCKi8GiE0IDacTgROXNheBLI1IASI0B4J4gU4Fji2KGoRBih2IVoNkIS8BgQNB X-IronPort-AV: E=Sophos;i="5.01,727,1400040000"; d="scan'208";a="143515400" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 24 Jul 2014 20:14:02 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id BD625B408D; Thu, 24 Jul 2014 20:14:02 -0400 (EDT) Date: Thu, 24 Jul 2014 20:14:02 -0400 (EDT) From: Rick Macklem To: Harald Schmalzbauer Message-ID: <1327388853.3033655.1406247242764.JavaMail.root@uoguelph.ca> In-Reply-To: <53D0CBD6.1020708@omnilan.de> Subject: Re: nfsd server cache flooded, try to increase nfsrc_floodlevel MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 00:15:11 -0000 Harald Schmalzbauer wrote: > Bez=C3=BCglich Rick Macklem's Nachricht vom 08.08.2013 14:20 (localtime): > > Lars Eggert wrote: > >> Hi, > >> > >> every few days or so, my -STABLE NFS server (v3 and v4) gets > >> wedged > >> with a ton of messages about "nfsd server cache flooded, try to > >> increase nfsrc_floodlevel" in the log, and nfsstat shows TCPPeak > >> at > >> 16385. It requires a reboot to unwedge, restarting the server does > >> not help. > >> > >> The clients are (mostly) six -CURRENT nfsv4 boxes that netboot > >> from > >> the server and mount all drives from there. > >> Have you tried increasing vfs.nfsd.tcphighwater? This needs to be increased to increase the flood level above 16384. Garrett Wollman sets: vfs.nfsd.tcphighwater=3D100000 vfs.nfsd.tcpcachetimeo=3D300 or something like that, if I recall correctly. rick > >> I googled around and saw that others have hit this issue, but I > >> haven't seen any resolution posted. I guess I can increase > >> NFSRVCACHE_FLOODLEVEL in the source, but I wonder if I wouldn't > >> simply hit the increase value after a little while longer... > >> > >> Lars > >> > > You can either try this patch (which dynamically adjusts > > nfsrc_floodlevel > > along with handling a variety of overhead issues for the DRC under > > heavy load): > > http://people.freebsd.org/~rmacklem/drc4.patch > > > > or just bump it up a bunch. The default value was safe for a server > > with 256Mbytes > > of ram and a default mbuf cluster limit. The only thing you might > > have to do > > along with bumping NFSRC_FLOODLEVEL up is increasing > > kern.ipc.mbclusters. > > > > The variant of the above patch will make it into head someday, once > > I merge > > in changes from ivoras@'s similar patch and confer with him about > > it. >=20 > Dear all, >=20 > regarding the conversation from last year - quoted above, > I think I found the mentioned patch (it's variants) MFCd in r255532 > (from > http://svnweb.freebsd.org/base?view=3Drevision&revision=3D254337), > so it's included in 9.3-RELEASE. >=20 > Unfortunately I'm still having the nfsrc_floodlevel problem with > OpenOwner=3D16385, CacheSize=3D16385 (in nfsstat -e -s) in my production > environment under 9.3-RELEASE-amd64. > Extremely light load on the server (2 (FreeBSD8/9) clients), but the > building client (nfsv4) locks up frequently. It mounts 'home' and > 'ports/ports' via NFSv4 (this time, 'make index' in nfs-mounted > /usr/ports killed the nfsv4server). >=20 >=20 > I found another interesting 3 years old patch/thread, which seems > never beeing comitted: > http://lists.freebsd.org/pipermail/freebsd-fs/2011-July/012016.html >=20 > I don't really understand all these details of nfs(v4), but I observe > problems with regular usage, so I wanted to ask if there are new > findings regarding the "nfsd server cache flooded, try to increase > nfsrc_floodlevel" messages (while 'nfsrc_floodlevel' doesn't seem to > be > tunable in 9.3). > To my understanding, it's a problem on the server side, right? >=20 > Is the fix from 3 years back still adequate (does apply with view > offsets only to 9.3)? >=20 > I'm currently testing 9.3-RELEASE+noopen.patch, but it usually took > two > or three days until the client locked up (hadn't looked for the > reason > before the last issue, nfs(v4) was brand new reintroduced here) >=20 > Thanks, >=20 > -Harry >=20 >=20 From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 02:28:47 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F4A4E2B for ; Fri, 25 Jul 2014 02:28:47 +0000 (UTC) Received: from nahkohe.jetcafe.org (nahkohe.jetcafe.org [205.147.26.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 263692423 for ; Fri, 25 Jul 2014 02:28:46 +0000 (UTC) X-Envelope-To: Received: from [205.147.26.4] (hokkshideh.jetcafe.org [205.147.26.4]) by nahkohe.jetcafe.org (8.14.2/8.14.2) with ESMTP id s6P2FEs7081463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Jul 2014 19:15:14 -0700 (PDT) Message-ID: <53D1BDB2.7030906@jetcafe.org> Date: Thu, 24 Jul 2014 19:15:14 -0700 From: Dave Hayes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org Subject: Gmirror + gpart corruption on 9.3-PRE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 02:28:47 -0000 At 9.3-PRERELEASE #0 r268066M I've been trying unsucessfuly to set up a brand shiny new gmirror + gpt style Raid 0 mirror using the following procedure on a disk gpart create -s gpt ada0 ( shows 931G of space) gpart add -s 96G -t freebsd-swap -l swap0 ada0 gpart add -t freebsd-ufs -l rw0 ada0 gpart create -s gpt ada1 gpart add -s 96G -t freebsd-swap -l swap1 ada1 gpart add -t freebsd-ufs -l rw1 ada1 gmirror label swap /dev/ada0p1 /dev/ada1p1 gmirror label rw /dev/ada0p2 /dev/ada1p2 gpart create -s gpt mirror/swap gpart add -s95G -t freebsd-swap -l FBCDSWAP mirror/swap gpart create -s gpt mirror/rw gpart add -s833G -t freebsd-ufs -l FBCDRW mirror/rw This consistently gives me the dreaded GEOM: mirror/rw: the secondary GPT table is corrupt or invalid just as soon as I provision the mirror/rw device. I have tried many ideas of padding these partitions so I don't get this message, but to noavail. I'm willing to try more, the machine isn't live (yet) so it can sit here while it gets figured out. :) Back at 9.2-PRERELEASE #0 r255456 I used the same procedure for setting up a gmirror, and this worked fine with no corruption. Here's the partition table: > gpart show => 34 976773101 ada0 GPT (465G) 34 46245840 1 freebsd-swap (22G) 46245874 930523232 2 freebsd-ufs (443G) 976769106 4029 - free - (2M) => 34 976773101 ada1 GPT (465G) 34 46245840 1 freebsd-swap (22G) 46245874 930523232 2 freebsd-ufs (443G) 976769106 4029 - free - (2M) => 34 46245772 mirror/swap0 GPT (22G) 34 46245772 1 freebsd-swap (22G) => 34 930523164 mirror/rw0 GPT (443G) 34 926941184 1 freebsd-ufs (442G) 926941218 3581980 - free - (1.7G) I've since upgraded this machine to the exact same 9.3 revision and it still works fine, no corruption. Am I missing something or did something change in between these two revisions that makes it difficult or different to set up? Thanks in advance for any insight you all can provide. -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>>> *The opinions expressed above are entirely my own* <<<< Enjoyment is not a goal, it is a feeling that accompanies important ongoing activity From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 04:04:51 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1734ECE for ; Fri, 25 Jul 2014 04:04:51 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B79532C86 for ; Fri, 25 Jul 2014 04:04:50 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id s6P44mWe029943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 24 Jul 2014 22:04:48 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id s6P44mcP029940; Thu, 24 Jul 2014 22:04:48 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Thu, 24 Jul 2014 22:04:48 -0600 (MDT) From: Warren Block To: Dave Hayes Subject: Re: Gmirror + gpart corruption on 9.3-PRE In-Reply-To: <53D1BDB2.7030906@jetcafe.org> Message-ID: References: <53D1BDB2.7030906@jetcafe.org> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Thu, 24 Jul 2014 22:04:48 -0600 (MDT) Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 04:04:51 -0000 On Thu, 24 Jul 2014, Dave Hayes wrote: > At 9.3-PRERELEASE #0 r268066M I've been trying unsucessfuly to set up a brand > shiny new gmirror + gpt style Raid 0 mirror using the following procedure on > a disk > > gpart create -s gpt ada0 > ( shows 931G of space) > gpart add -s 96G -t freebsd-swap -l swap0 ada0 > gpart add -t freebsd-ufs -l rw0 ada0 > gpart create -s gpt ada1 > gpart add -s 96G -t freebsd-swap -l swap1 ada1 > gpart add -t freebsd-ufs -l rw1 ada1 > gmirror label swap /dev/ada0p1 /dev/ada1p1 > gmirror label rw /dev/ada0p2 /dev/ada1p2 Mirrors of GPT partitions on different disks is fine. Or rather, it's sub-optimal but will work. > gpart create -s gpt mirror/swap > gpart add -s95G -t freebsd-swap -l FBCDSWAP mirror/swap > gpart create -s gpt mirror/rw > gpart add -s833G -t freebsd-ufs -l FBCDRW mirror/rw > This consistently gives me the dreaded > > GEOM: mirror/rw: the secondary GPT table is corrupt or invalid > > just as soon as I provision the mirror/rw device. I believe that GPT tables somehow work only on the drive level. That is, the GPT partitioning created inside the mirror actually overwrites the existing one on the drive. As odd as it sounds, I think this is intentional: GPT tables are only supposed to be at the beginning and end of a physical drive. But I'm also not the one to explain it. However, the attempted GPT partitioning inside the mirrors is not needed and can be left out. > I've since upgraded this machine to the exact same 9.3 revision and it still > works fine, no corruption. Am I missing something or did something change in > between these two revisions that makes it difficult or different to set up? GPT tests got more strict at some point. Maybe the rules for GPT tables did also. For reference, here is my article on mirroring GPT disk partitions. I do not recommend it. (Consider the head contention when multiple mirrors on the same drive attempt to rebuild. Or disable automatic rebuilding, but then it's going to be unpleasant in an emergency.) http://www.wonkity.com/~wblock/docs/html/gmirror.html For drives under 2TB, use MBR and bsdlabels, as ugly as it is. The recently-rewritten Handbook procedure shows the right way to do it, including alignment: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/geom-mirror.html If the memory is available, ZFS might handle mirrored partitions better. Maybe a per-pool configurable resilvering priority, but I don't know. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 04:30:01 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25F8E7CA for ; Fri, 25 Jul 2014 04:30:01 +0000 (UTC) Received: from nahkohe.jetcafe.org (nahkohe.jetcafe.org [205.147.26.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DF10A2E84 for ; Fri, 25 Jul 2014 04:30:00 +0000 (UTC) X-Envelope-To: freebsd-stable@freebsd.org Received: from [205.147.26.4] (hokkshideh.jetcafe.org [205.147.26.4]) by nahkohe.jetcafe.org (8.14.2/8.14.2) with ESMTP id s6P4TxXd083207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Jul 2014 21:29:59 -0700 (PDT) Message-ID: <53D1DD47.4040403@jetcafe.org> Date: Thu, 24 Jul 2014 21:29:59 -0700 From: Dave Hayes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Warren Block Subject: Re: Gmirror + gpart corruption on 9.3-PRE References: <53D1BDB2.7030906@jetcafe.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 04:30:01 -0000 On 07/24/2014 21:04, Warren Block wrote: > I believe that GPT tables somehow work only on the drive level. That > is, the GPT partitioning created inside the mirror actually overwrites > the existing one on the drive. As odd as it sounds, I think this is > intentional: GPT tables are only supposed to be at the beginning and end > of a physical drive. But I'm also not the one to explain it. > > However, the attempted GPT partitioning inside the mirrors is not needed > and can be left out. I did this because newfs seemed to corrupt the partition table if I did not do this. > GPT tests got more strict at some point. Maybe the rules for GPT tables > did also. That sounds like the simplest explanation. > For reference, here is my article on mirroring GPT disk partitions. I > do not recommend it. (Consider the head contention when multiple > mirrors on the same drive attempt to rebuild. Or disable automatic > rebuilding, but then it's going to be unpleasant in an emergency.) Since I'm only having two mirrors, would it be better to disable just the automatic rebuilding on the swap space? Would graid be better to use to achieve a mirrored volume? > For drives under 2TB, use MBR and bsdlabels, as ugly as it is. The > recently-rewritten Handbook procedure shows the right way to do it, > including alignment: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/geom-mirror.html Yeah, I'd do this except there will come a day when 2TB drives cannot be found, and I have a significant history of having machines more than 6-7 years old. Sadly, I cannot use ZFS in this circumstance due to heavy memory requirements of what the machine will be used for. -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>>> *The opinions expressed above are entirely my own* <<<< There are only 10 kinds of people that understand binary - those that do, and those that don't. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 05:34:59 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 927EE5E2 for ; Fri, 25 Jul 2014 05:34:59 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 394F323C0 for ; Fri, 25 Jul 2014 05:34:59 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id s6P5Yvg0053727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 24 Jul 2014 23:34:57 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id s6P5Yvd0053724; Thu, 24 Jul 2014 23:34:57 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Thu, 24 Jul 2014 23:34:57 -0600 (MDT) From: Warren Block To: Dave Hayes Subject: Re: Gmirror + gpart corruption on 9.3-PRE In-Reply-To: <53D1DD47.4040403@jetcafe.org> Message-ID: References: <53D1BDB2.7030906@jetcafe.org> <53D1DD47.4040403@jetcafe.org> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Thu, 24 Jul 2014 23:34:57 -0600 (MDT) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 05:34:59 -0000 On Thu, 24 Jul 2014, Dave Hayes wrote: > On 07/24/2014 21:04, Warren Block wrote: >> I believe that GPT tables somehow work only on the drive level. That >> is, the GPT partitioning created inside the mirror actually overwrites >> the existing one on the drive. As odd as it sounds, I think this is >> intentional: GPT tables are only supposed to be at the beginning and end >> of a physical drive. But I'm also not the one to explain it. >> >> However, the attempted GPT partitioning inside the mirrors is not needed >> and can be left out. > > I did this because newfs seemed to corrupt the partition table if I did not > do this. Following the procedure in my GPT partition link, I did not have that problem. The old Handbook procedure for creating mirrors did some questionable things which could have caused problems. The new (current) one does it right. >> GPT tests got more strict at some point. Maybe the rules for GPT tables >> did also. > > That sounds like the simplest explanation. > >> For reference, here is my article on mirroring GPT disk partitions. I >> do not recommend it. (Consider the head contention when multiple >> mirrors on the same drive attempt to rebuild. Or disable automatic >> rebuilding, but then it's going to be unpleasant in an emergency.) > > Since I'm only having two mirrors, would it be better to disable just the > automatic rebuilding on the swap space? I think that would be ideal. Swap doesn't need to be rebuilt anyway, the mirror could just be destroyed and recreated. > Would graid be better to use to achieve a mirrored volume? Seems unlikely to me. The main advantage graid(8) has is the BIOS being able to boot from the mirror directly. >> For drives under 2TB, use MBR and bsdlabels, as ugly as it is. The >> recently-rewritten Handbook procedure shows the right way to do it, >> including alignment: >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/geom-mirror.html > > Yeah, I'd do this except there will come a day when 2TB drives cannot be > found, and I have a significant history of having machines more than 6-7 > years old. True. But partitioning can be specific to the drive. It's not like GPT-partitioned drives can be copied with dd (well, not correctly). A new drive would be partitioned and then the data transferred, hopefully just with labels instead of device names. > Sadly, I cannot use ZFS in this circumstance due to heavy memory requirements > of what the machine will be used for. A lot of legacy machines just can't accept enough memory for ZFS anyway. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 05:56:30 2014 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65A89AB8; Fri, 25 Jul 2014 05:56:30 +0000 (UTC) Received: from mout.gmx.com (mout.gmx.com [74.208.4.200]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 32328256A; Fri, 25 Jul 2014 05:56:30 +0000 (UTC) Received: from [157.181.98.237] ([157.181.98.237]) by mail.gmx.com (mrgmxus002) with ESMTPSA (Nemesis) id 0M4nHf-1WIAno1PUz-00z1cA; Fri, 25 Jul 2014 07:51:17 +0200 Message-ID: <53D1F00F.7060301@gmx.com> Date: Fri, 25 Jul 2014 07:50:07 +0200 From: dt71@gmx.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 To: Baptiste Daroussin , ports@FreeBSD.org, stable@FreeBSD.org, current@FreeBSD.org Subject: Re: [ANNOUNCEMENT] pkg 1.3.0 out! References: <20140723144249.GD69907@ivaldir.etoilebsd.net> In-Reply-To: <20140723144249.GD69907@ivaldir.etoilebsd.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:bt6LSGsDi2AUKtA4gcQcem+K1R0YUwUAjkNzT5ejivR0DAWjjS6 CTK2JtoPiLwU8wHjYbyzAGDXknlsZ2z0+SAv0EvRMZdrbzHhGC0rKtbaujs77Ggd9gbaPU0 KQzpaCXAd0UFHZt2iBPvBIZrhd+si0k3tRLT4kz//MZKYYcbx1ACpVmQR52nMD3WK0QHd/W ol69y60UIgYY1KxuyTRMA== X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 05:56:30 -0000 Baptiste Daroussin wrote, On 07/23/2014 16:42: > So much has happened that it is hard to summarize so I'll try to highlight the > major points: > - New solver, now pkg has a real SAT solver able to automatically handle > conflicts and dynamically discover them. (yes pkg set -o is deprecated now) Does pkg/Pkg/PKG/pkgng/PkgNg/PKGNG/whatever now downgrade/revert packages when removing an alternative repository, such as FreeBSD_new_xorg? (Previously, it didn't: I was required to manually remove and (re)install all X11-related packages.) From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 06:56:45 2014 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CEB99BED; Fri, 25 Jul 2014 06:56:45 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 185C12B6C; Fri, 25 Jul 2014 06:56:45 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 0B69EB84D; Fri, 25 Jul 2014 08:56:42 +0200 (SAST) Date: Fri, 25 Jul 2014 08:56:41 +0200 From: John Hay To: Baptiste Daroussin Subject: Re: [ANNOUNCEMENT] pkg 1.3.0 out! Message-ID: <20140725065641.GA88239@zibbi.meraka.csir.co.za> References: <20140723144249.GD69907@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20140723144249.GD69907@ivaldir.etoilebsd.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ports@FreeBSD.org, stable@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 06:56:46 -0000 On Wed, Jul 23, 2014 at 04:42:51PM +0200, Baptiste Daroussin wrote: > Hi all, > > I'm very please to announce the release of pkg 1.3.0 > This version is the result of almost 9 month of hard work > ... > Thank you to all contributors: > Alberto Villa, Alexandre Perrin, Andrej Zverev, Antoine Brodin, Brad Davis, > Bryan Drewery, Dag-Erling Sm?rgrav, Dmitry Marakasov, Elvira Khabirova, Jamie > Landeg Jones, Jilles Tjoelker, John Marino, Julien Laffaye, Mathieu Arnold, > Matthew Seaman, Maximilian Ga?, Michael Gehring, Michael Gmelin, Nicolas Szalay, > Rodrigo Osorio, Roman Naumann, Rui Paulo, Sean Channel, Stanislav E. Putrya, > Vsevolod Stakhov, Xin Li, coctic > > Regards, > Bapt on behalf of the pkg@ Version 1.3 does better on armeb. It does not crash while installing itself, but still complains and get the architecture wrong: ################ root@cambria-build:/usr/ports/ports-mgmt/pkg # make install ===> Installing for pkg-1.3.0 ===> Checking if ports-mgmt/pkg already installed pkg-static: failed to find the version elf note ===> Registering installation for pkg-1.3.0 pkg-static: failed to find the version elf note pkg-static: failed to find the version elf note If you are upgrading from the old package format, first run: # pkg2ng root@cambria-build:/usr/ports/ports-mgmt/pkg # pkg info pkg pkg: failed to find the version elf note pkg-1.3.0 Name : pkg Version : 1.3.0 Installed on : Fri Jul 25 06:36:42 UTC 2014 Origin : ports-mgmt/pkg Architecture :  ¸ Prefix : /usr/local Categories : ports-mgmt Licenses : BSD2CLAUSE Maintainer : portmgr@FreeBSD.org WWW : http://wiki.freebsd.org/pkgng Comment : Package manager Flat size : 7.14MiB Description : Package management tool WWW: http://wiki.freebsd.org/pkgng root@cambria-build:/usr/ports/ports-mgmt/pkg # uname -a FreeBSD cambria-build 11.0-CURRENT FreeBSD 11.0-CURRENT #13 r269057M: Thu Jul 24 15:54:38 SAST 2014 jhay@dolphin.meraka.csir.co.za:/usr/obj/arm.armeb/snaps/arm/11-tst/src/sys/CAMBRIA arm root@cambria-build:/usr/ports/ports-mgmt/pkg # uname -p armeb root@cambria-build:/usr/ports/ports-mgmt/pkg # uname -m arm root@cambria-build:/usr/ports/ports-mgmt/pkg ################### On the previous pkg, I used a small crow-bar patch (attached) then it did install properly and its architecture looked like this: ################### % pkg info pkg pkg-1.2.7_3 Name : pkg Version : 1.2.7_3 Installed on : Thu Jul 17 15:15:05 SAST 2014 Origin : ports-mgmt/pkg Architecture : freebsd:11:arm:32:eb:eabi:softfp Prefix : /usr/local Categories : ports-mgmt Licenses : BSD2CLAUSE Maintainer : portmgr@FreeBSD.org WWW : http://wiki.freebsd.org/pkgng Comment : Package manager Shared Libs required: libpkg.so.1 Flat size : 6.48MiB Description : Package management tool WWW: http://wiki.freebsd.org/pkgng ################### Regards John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za --- libpkg/pkg_elf.c.orig 2014-03-15 13:15:46.000000000 +0000 +++ libpkg/pkg_elf.c 2014-06-23 17:41:35.000000000 +0000 @@ -636,6 +636,12 @@ int ret = EPKG_OK; int i; const char *arch, *abi, *endian_corres_str, *wordsize_corres_str, *fpu; + const char *path; + char localname[] = "freebsd"; + + path = getenv("ABI_FILE"); + if (path == NULL) + path = _PATH_BSHELL; if (elf_version(EV_CURRENT) == EV_NONE) { pkg_emit_error("ELF library initialization failed: %s", @@ -643,7 +649,7 @@ return (EPKG_FATAL); } - if ((fd = open(_PATH_BSHELL, O_RDONLY)) < 0) { + if ((fd = open(path, O_RDONLY)) < 0) { pkg_emit_errno("open", _PATH_BSHELL); snprintf(dest, sz, "%s", "unknown"); return (EPKG_FATAL); @@ -687,6 +693,7 @@ break; src += note.n_namesz + note.n_descsz; } +#if 0 if ((uintptr_t)src >= ((uintptr_t)data->d_buf + data->d_size)) { ret = EPKG_FATAL; pkg_emit_error("failed to find the version elf note"); @@ -698,7 +705,10 @@ version = be32dec(src); else version = le32dec(src); - +#else + osname = localname; + version = 11 * 100000; +#endif for (i = 0; osname[i] != '\0'; i++) osname[i] = (char)tolower(osname[i]); From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 07:00:07 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8548BEE3 for ; Fri, 25 Jul 2014 07:00:07 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0E9892BB1 for ; Fri, 25 Jul 2014 07:00:06 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s6P70361067948; Fri, 25 Jul 2014 09:00:03 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id A7741371E; Fri, 25 Jul 2014 09:00:02 +0200 (CEST) Message-ID: <53D2006C.7090207@omnilan.de> Date: Fri, 25 Jul 2014 08:59:56 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: panic/lock on 9.3-RELEASE with nullfs/nfs/zfs combination References: <53D12973.3010805@omnilan.de> <20140724165917.GT93733@kib.kiev.ua> <53D1503B.2030200@omnilan.de> <20140724193048.GU93733@kib.kiev.ua> In-Reply-To: <20140724193048.GU93733@kib.kiev.ua> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig68781FB02668C51F2ED66DBA" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Fri, 25 Jul 2014 09:00:03 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 07:00:07 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig68781FB02668C51F2ED66DBA Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Bez=FCglich Konstantin Belousov's Nachricht vom 24.07.2014 21:30 (localtime): > On Thu, Jul 24, 2014 at 08:28:11PM +0200, Harald Schmalzbauer wrote: >> Bez??glich Konstantin Belousov's Nachricht vom 24.07.2014 18:59 >> (localtime): >>> ??? >>> The lockmgr flags are LK_SHARE | LK_RETRY, and error 11 =3D=3D EDEADL= K >>> indicates that the lock is already taken by the curthread in the >>> exclusive mode. I am interested in what line of code did the locking.= >>> >>> Add ddb, INVARIANTS, WITNESS and DEBUG_VFS_LOCKS options to the kerne= l >>> config, reproduce the issue and, after the panic occured and you >>> get at the ddb prompt, issue command 'show alllocks'. >>> >>> Also, do 'show mount', after which do 'show mount ', where >>> is the address of your nullfs mount point, printed by 'show mount'. >>> >>> I need all console output starting from the panic message. >> FreeBSD/amd64 (mira.inop.mo1.omnilan.net) (ttyu0) >> >> login: panic: LK_RETRY set with incompatible flags (0x200400) or an >> error occured (11) >> cpuid =3D 1 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame >> 0xffffff82e565fc70 >> kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff82e565fd30 >> panic() at panic+0x1cd/frame 0xffffff82e565fe30 >> _vn_lock() at _vn_lock+0x77/frame 0xffffff82e565fe90 >> zfs_lookup() at zfs_lookup+0x420/frame 0xffffff82e565ff20 >> zfs_freebsd_lookup() at zfs_freebsd_lookup+0xa6/frame 0xffffff82e56600= 70 >> VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0x102/frame >> 0xffffff82e56600a0 >> vfs_cache_lookup() at vfs_cache_lookup+0xff/frame 0xffffff82e5660110 >> VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x102/frame 0xffffff82e5660140 >> null_lookup() at null_lookup+0x92/frame 0xffffff82e56601c0 >> VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x102/frame 0xffffff82e56601f0 >> lookup() at lookup+0x32f/frame 0xffffff82e5660290 >> namei() at namei+0x3df/frame 0xffffff82e5660340 >> vn_open_cred() at vn_open_cred+0x1e2/frame 0xffffff82e56604b0 >> vop_stdvptocnp() at vop_stdvptocnp+0x1af/frame 0xffffff82e56607e0 >> null_vptocnp() at null_vptocnp+0xf5/frame 0xffffff82e5660850 >> VOP_VPTOCNP_APV() at VOP_VPTOCNP_APV+0x105/frame 0xffffff82e5660880 >> vn_vptocnp_locked() at vn_vptocnp_locked+0x15b/frame 0xffffff82e566091= 0 >> vn_fullpath1() at vn_fullpath1+0x100/frame 0xffffff82e5660970 >> kern___getcwd() at kern___getcwd+0xd4/frame 0xffffff82e56609d0 >> amd64_syscall() at amd64_syscall+0x318/frame 0xffffff82e5660af0 >> Xfast_syscall() at Xfast_syscall+0xf7/frame 0xffffff82e5660af0 >> --- syscall (326, FreeBSD ELF64, sys___getcwd), rip =3D 0x8011a191c, r= sp =3D >> 0x7fffffffe658, rbp =3D 0x801873400 --- >> KDB: enter: panic >> [ thread pid 1918 tid 100919 ] >> Stopped at kdb_enter+0x3b: movq $0,0x645622(%rip) >> db> show alllocks >> db> You do not have WITNESS in your kernel config, most likely. Hmm enabled it is, from the boot msg: gcc version 4.2.1 20070831 patched [FreeBSD] WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz (3292.52-MHz K8-class CPU)= But there's another WITNESS message: WITNESS: unable to allocate a new witness object. Ill ask the relatives what they know about this message (aunt bing, uncle google aso). -Harry --------------enig68781FB02668C51F2ED66DBA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlPSAHIACgkQLDqVQ9VXb8icrACfd15HIry7l8fndzGlq6oSQaJ2 1WUAn0mPxaK5YW371RxEMfWigyNAYutp =Fza1 -----END PGP SIGNATURE----- --------------enig68781FB02668C51F2ED66DBA-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 07:14:52 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 36EB92D6 for ; Fri, 25 Jul 2014 07:14:52 +0000 (UTC) Received: from nijmegen.renzel.net (mx1.renzel.net [195.243.213.130]) by mx1.freebsd.org (Postfix) with ESMTP id EE3B62D44 for ; Fri, 25 Jul 2014 07:14:50 +0000 (UTC) Received: from dublin.vkf.isb.de.renzel.net (unknown [10.0.0.80]) by nijmegen.renzel.net (smtpd) with ESMTP id 0281E141483B for ; Fri, 25 Jul 2014 09:14:29 +0200 (CEST) Received: from asbach.renzel.net (unknown [10.2.0.7]) by dublin.vkf.isb.de.renzel.net (Postfix) with ESMTP id C9D5C1CEA03 for ; Fri, 25 Jul 2014 09:14:34 +0200 (CEST) Content-Type: text/plain; charset="ISO-8859-1" From: Nils Beyer Organization: VKF Renzel GmbH Date: Fri, 25 Jul 2014 09:14:34 +0200 User-Agent: KNode/4.12.5 Content-Transfer-Encoding: 7Bit Subject: Re: Bhyve on AMD CPUs under 10-STABLE? To: freebsd-stable@freebsd.org References: <7F88A9D9-FA25-45C2-9AA1-C637DA7D9057@gromit.dlib.vt.edu> Lines: 24 MIME-Version: 1.0 X-Virus-Scanned: clamav-milter 0.98 at nijmegen.renzel.net X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=7.0 tests=BAYES_00,MISSING_MID, UNPARSEABLE_RELAY autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on nijmegen.renzel.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 07:14:52 -0000 Hi Paul, Paul Mather wrote: > Does bhyve work on AMD CPUs under 10-STABLE? I rebuilt my system > yesterday (to r269010) but the bhyve module does not appear to load > properly. I get this on the console when I kldload vmm: > > ===== > amdv_init: not implemented > amdv_cleanup: not implemented > module_register_init: MOD_LOAD (vmm, 0xffffffff81c1a590, 0) error 6 > ===== You'll have to SVN-checkout: svn://svn.freebsd.org/base/projects/bhyve_svm and rebuild your world/kernel. With that you'll should be able to get bhyve working on your AMD CPU. It works here on my Phenom II... Regards, Nils From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 07:18:50 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69BB74FA for ; Fri, 25 Jul 2014 07:18:50 +0000 (UTC) Received: from nijmegen.renzel.net (mx1.renzel.net [195.243.213.130]) by mx1.freebsd.org (Postfix) with ESMTP id 2C5DE2D8F for ; Fri, 25 Jul 2014 07:18:50 +0000 (UTC) Received: from dublin.vkf.isb.de.renzel.net (unknown [10.0.0.80]) by nijmegen.renzel.net (smtpd) with ESMTP id 52F791414816 for ; Fri, 25 Jul 2014 09:18:35 +0200 (CEST) Received: from asbach.renzel.net (unknown [10.2.0.7]) by dublin.vkf.isb.de.renzel.net (Postfix) with ESMTP id 241FF1CEA6E for ; Fri, 25 Jul 2014 09:18:41 +0200 (CEST) Content-Type: text/plain; charset="ISO-8859-1" From: Nils Beyer Organization: VKF Renzel GmbH Date: Fri, 25 Jul 2014 09:18:41 +0200 User-Agent: KNode/4.12.5 Content-Transfer-Encoding: 7Bit Subject: Re: link_elf_obj: symbol icl_pdu_new_bhs undefined To: freebsd-stable@freebsd.org References: <53D15B4C.40104@egr.msu.edu> Lines: 14 MIME-Version: 1.0 X-Virus-Scanned: clamav-milter 0.98 at nijmegen.renzel.net X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=7.0 tests=BAYES_00,MISSING_MID, UNPARSEABLE_RELAY autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on nijmegen.renzel.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 07:18:50 -0000 Hi Adam, Adam McDougall wrote: > Yes, someone on irc ran into it, I confirmed it with -stable, and > someone beat me to filing a bug report: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192031 That was me. Unfortunately, there hasn't been any interest in that report yet and I don't know how to fix that on my own. So I've reverted to r268571 and live with it now... Regards, Nils From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 07:42:05 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0D60EC8E for ; Fri, 25 Jul 2014 07:42:05 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A4BB02015 for ; Fri, 25 Jul 2014 07:42:04 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s6P7g2vE068249; Fri, 25 Jul 2014 09:42:02 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 35F413731; Fri, 25 Jul 2014 09:42:02 +0200 (CEST) Message-ID: <53D20A49.5020803@omnilan.de> Date: Fri, 25 Jul 2014 09:42:01 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Rick Macklem Subject: Re: nfsd server cache flooded, try to increase nfsrc_floodlevel References: <1327388853.3033655.1406247242764.JavaMail.root@uoguelph.ca> In-Reply-To: <1327388853.3033655.1406247242764.JavaMail.root@uoguelph.ca> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1B596AD85497A1C3986BEBD9" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Fri, 25 Jul 2014 09:42:02 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 07:42:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1B596AD85497A1C3986BEBD9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Rick Macklem's Nachricht vom 25.07.2014 02:14 (localtime)= : > Harald Schmalzbauer wrote: >> Bez=C3=BCglich Rick Macklem's Nachricht vom 08.08.2013 14:20 (localtim= e): >>> Lars Eggert wrote: >>>> Hi, >>>> >>>> every few days or so, my -STABLE NFS server (v3 and v4) gets >>>> wedged >>>> with a ton of messages about "nfsd server cache flooded, try to >>>> increase nfsrc_floodlevel" in the log, and nfsstat shows TCPPeak >>>> at >>>> 16385. It requires a reboot to unwedge, restarting the server does >>>> not help. >>>> >>>> The clients are (mostly) six -CURRENT nfsv4 boxes that netboot >>>> from >>>> the server and mount all drives from there. >>>> > Have you tried increasing vfs.nfsd.tcphighwater? > This needs to be increased to increase the flood level above 16384. > > Garrett Wollman sets: > vfs.nfsd.tcphighwater=3D100000 > vfs.nfsd.tcpcachetimeo=3D300 > > or something like that, if I recall correctly. Thanks you for your help! I read about tuning these sysctls, but I object individually altering these, because I don't have hundreds of clients torturing a poor server or any other not well balanced setup. I run into this problem with one client, connected via 1GbE (not 10 or 40GbE) link, talking to modern server with 10G RAM - and this environment forces me to reboot the storage server every 2nd day. IMHO such a setup shouldn't require manual tuning and I consider this as a really urgent problem! Whatever causes the server to lock up is strongly required to be fixed for next release, otherwise the shipped implementation of NFS is not really suitable for production environment and needs a warning message when enabled. The impact of this failure forces admins to change the operation system in order to get a core service back into operation. The importance is, that I don't suffer from weaker performance or lags/delays, but my server stops NFS completely and only a reboot solves this situation. Are there later modifcations or other findings which are known to obsolet= e your noopen.patch (http://people.freebsd.org/~rmacklem/noopen.patch)? I'm testing this atm, but having other panics on the same machine related to vfs locking, so results of the test won't be available too soo= n. Thank you, -Harry --------------enig1B596AD85497A1C3986BEBD9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlPSCkkACgkQLDqVQ9VXb8jATQCgl9/tYE9u+sKP8e7zyqCSX4HC MA0AnjpN4eJpBxFS5Jl+WzB0HbEFE3cX =URAE -----END PGP SIGNATURE----- --------------enig1B596AD85497A1C3986BEBD9-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 07:52:44 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9943AF6C for ; Fri, 25 Jul 2014 07:52:44 +0000 (UTC) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2E87820F7 for ; Fri, 25 Jul 2014 07:52:43 +0000 (UTC) Received: from hugo10.ka.punkt.de ([217.29.45.10]) by gate2.intern.punkt.de with ESMTP id s6P7f9qs016506; Fri, 25 Jul 2014 09:41:09 +0200 (CEST) Received: from hausen-mbp.intern.punkt.de (hausen-mbp.intern.punkt.de [217.29.45.147]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id s6P7f8ga018212; Fri, 25 Jul 2014 09:41:09 +0200 (CEST) (envelope-from hausen@punkt.de) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Gmirror + gpart corruption on 9.3-PRE From: "Patrick M. Hausen" In-Reply-To: Date: Fri, 25 Jul 2014 09:41:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53D1BDB2.7030906@jetcafe.org> <53D1DD47.4040403@jetcafe.org> To: Warren Block X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 07:52:44 -0000 Hi, all, Am 25.07.2014 um 07:34 schrieb Warren Block : > True. But partitioning can be specific to the drive. It's not like = GPT-partitioned drives can be copied with dd (well, not correctly). Errrr ... sorry, but ... could you please elaborate on that? Up until = now I was sure that any drive could be copied with dd(1). Puzzled. :-) Thanks and best regards Patrick --=20 punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: J=FCrgen Egeling AG Mannheim 108285 From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 09:21:13 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C46AD9 for ; Fri, 25 Jul 2014 09:21:13 +0000 (UTC) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0739028A4 for ; Fri, 25 Jul 2014 09:21:12 +0000 (UTC) Received: by mail-la0-f48.google.com with SMTP id gl10so2806044lab.21 for ; Fri, 25 Jul 2014 02:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=orBM4SUuKaezXWh/KEOJf6Eb3A7z7QCTmlC0KbbD8Jk=; b=VwVGZXj1YjSTumRVC9vCseC7lBST4TMlXsbNzvyzzBg9jXBz2eFrll6NFT4CNgEABu 7EHZjWpBBmsI5CZcidNnKBf5+sHG14qE4VUJdj/NkZatX7CGMZsxNJ9SbKm9J2hE/vDn ueIKL6qxyAIa8fKrCFmbWgQ/KkhqjJoY5GY4GOzvr2n4T9hFiotmg9mUHfHb/pkNfZLA E+BnSDOcOlb2DLhJ+Dtw7j2hz+PAAPwj/hPqHMtIyH8JTLfvUB1Wc3gX/uVbotQTOFRP 7amVkznwhXsy9MCFrnUVtpfrn5pA6Wg4CgWO6Ggsi+lAcUq6W5KlpwaIzObZdNl5hQ28 wX3Q== MIME-Version: 1.0 X-Received: by 10.112.129.9 with SMTP id ns9mr13917765lbb.23.1406280070662; Fri, 25 Jul 2014 02:21:10 -0700 (PDT) Received: by 10.112.217.4 with HTTP; Fri, 25 Jul 2014 02:21:10 -0700 (PDT) Reply-To: huanghwh@gmail.com Date: Fri, 25 Jul 2014 17:21:10 +0800 Message-ID: Subject: panic on 10-STABLE with if_run+hostapd From: Huang Wen Hui To: "freebsd-stable@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 09:21:13 -0000 hi, I run these command: ifconfig wlan0 destroy ifconfig wlan0 create wlandev run0 wlanmode hostap ifconfig wlan0 inet 192.168.2.1 mode 11g sleep 5 /etc/rc.d/hostapd onestart and got a panic: http://sw.gddsn.org.cn/freebsd/2.JPG http://sw.gddsn.org.cn/freebsd/1.JPG #cat /etc/hostapd.conf interface=wlan0 debug=1 ctrl_interface=/var/run/hostapd ctrl_interface_group=wheel ssid=HWH wpa=1 wpa_passphrase=87686302 wpa_key_mgmt=WPA-PSK wpa_pairwise=CCMP TKIP # uname -a FreeBSD mbp.gddsn.org.cn 10.0-STABLE FreeBSD 10.0-STABLE #52 r268957M: Tue Jul 22 06:12:13 CST 2014 root@mbp.gddsn.org.cn:/usr/obj/usr/src/sys/MACBOOK amd64 # dmesg | grep run run0: <1.0> on usbus0 run0: MAC/BBP RT3070 (rev 0x0201), RF RT3020 (MIMO 1T1R), address 4c:e6:76:d4:c9:5e run0: firmware RT2870 ver. 0.33 loaded Cheers, Huang Wen Hui From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 09:32:33 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 890895AD for ; Fri, 25 Jul 2014 09:32:33 +0000 (UTC) Received: from nijmegen.renzel.net (mx1.renzel.net [195.243.213.130]) by mx1.freebsd.org (Postfix) with ESMTP id 4B4F929C7 for ; Fri, 25 Jul 2014 09:32:33 +0000 (UTC) Received: from dublin.vkf.isb.de.renzel.net (unknown [10.0.0.80]) by nijmegen.renzel.net (smtpd) with ESMTP id 7F79D1414868 for ; Fri, 25 Jul 2014 11:32:16 +0200 (CEST) Received: from asbach.renzel.net (unknown [10.2.0.7]) by dublin.vkf.isb.de.renzel.net (Postfix) with ESMTP id 547AA1CE99D for ; Fri, 25 Jul 2014 11:32:22 +0200 (CEST) Content-Type: text/plain; charset="ISO-8859-1" From: Nils Beyer Organization: VKF Renzel GmbH Date: Fri, 25 Jul 2014 11:32:22 +0200 User-Agent: KNode/4.12.5 Content-Transfer-Encoding: 7Bit Subject: Re: link_elf_obj: symbol icl_pdu_new_bhs undefined To: freebsd-stable@freebsd.org References: <53D15B4C.40104@egr.msu.edu> <20140725071853.69F69522@hub.freebsd.org> Lines: 9 MIME-Version: 1.0 X-Virus-Scanned: clamav-milter 0.98 at nijmegen.renzel.net X-Virus-Status: Clean X-Spam-Status: No, score=-6.5 required=7.0 tests=BAYES_00,MISSING_MID, UNPARSEABLE_RELAY autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on nijmegen.renzel.net X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 09:32:33 -0000 I wrote: > [...] Unfortunately, there hasn't been any interest in that report yet and > I don't know how to fix that on my own. Found something that works for me - take a look into my bug report... Regards, Nils From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 10:34:36 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08A1E775 for ; Fri, 25 Jul 2014 10:34:36 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id C2F862017 for ; Fri, 25 Jul 2014 10:34:35 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooKADAy0lODaFve/2dsb2JhbABZFoNKVwEDgnTHCodFAYEnd4QDAQEEASNCFAUWDgoCAg0ZAlkGiE0IDad2l0IXgSyMNoERDxU0B4J4gU8FjjOIa4Vxih+IV4NkITCBAgEfIg X-IronPort-AV: E=Sophos;i="5.01,730,1400040000"; d="scan'208";a="144414634" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 25 Jul 2014 06:32:59 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 31254B3F43; Fri, 25 Jul 2014 06:32:59 -0400 (EDT) Date: Fri, 25 Jul 2014 06:32:59 -0400 (EDT) From: Rick Macklem To: Harald Schmalzbauer Message-ID: <1672084785.3195858.1406284379181.JavaMail.root@uoguelph.ca> In-Reply-To: <53D20A49.5020803@omnilan.de> Subject: Re: nfsd server cache flooded, try to increase nfsrc_floodlevel MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.209] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 10:34:36 -0000 Harald Schmaltzbauer wrote: > Bez=C3=BCglich Rick Macklem's Nachricht vom 25.07.2014 02:14 (localtime): > > Harald Schmalzbauer wrote: > >> Bez=C3=BCglich Rick Macklem's Nachricht vom 08.08.2013 14:20 > >> (localtime): > >>> Lars Eggert wrote: > >>>> Hi, > >>>> > >>>> every few days or so, my -STABLE NFS server (v3 and v4) gets > >>>> wedged > >>>> with a ton of messages about "nfsd server cache flooded, try to > >>>> increase nfsrc_floodlevel" in the log, and nfsstat shows TCPPeak > >>>> at > >>>> 16385. It requires a reboot to unwedge, restarting the server > >>>> does > >>>> not help. > >>>> > >>>> The clients are (mostly) six -CURRENT nfsv4 boxes that netboot > >>>> from > >>>> the server and mount all drives from there. > >>>> > > Have you tried increasing vfs.nfsd.tcphighwater? > > This needs to be increased to increase the flood level above 16384. > > > > Garrett Wollman sets: > > vfs.nfsd.tcphighwater=3D100000 > > vfs.nfsd.tcpcachetimeo=3D300 > > > > or something like that, if I recall correctly. >=20 > Thanks you for your help! >=20 > I read about tuning these sysctls, but I object individually altering > these, because I don't have hundreds of clients torturing a poor > server > or any other not well balanced setup. > I run into this problem with one client, connected via 1GbE (not 10 > or > 40GbE) link, talking to modern server with 10G RAM - and this > environment forces me to reboot the storage server every 2nd day. > IMHO such a setup shouldn't require manual tuning and I consider this > as > a really urgent problem! Well, the default was what worked for the hardware I have to test on: - single core i386 server with 256Mbytes of memory on 100Mbps network Since I have nothing close to 10Gbps networking (100Mbps only), I can't test even a situation like your server/single client, so all I can do is set a default that works for me. I don't think you can expect a "one size fits all" setting when you have servers ranging from what I have (i386 with 256Mbytes of memory) to 64 cores, Gbytes of RAM etc. Eventually, others (like iXsystems maybe) who can test on a range of servers may be able to come up with a way to tune it dynamically based on server size, but that requires a range of hardware to test on. Basically, although NFSv4 is now 10years old, people are just starting to use it, so experience is still pretty limited w.r.t. it. rick > Whatever causes the server to lock up is strongly required to be > fixed > for next release, > otherwise the shipped implementation of NFS is not really suitable > for > production environment and needs a warning message when enabled. > The impact of this failure forces admins to change the operation > system > in order to get a core service back into operation. > The importance is, that I don't suffer from weaker performance or > lags/delays, but my server stops NFS completely and only a reboot > solves > this situation. >=20 > Are there later modifcations or other findings which are known to > obsolete > your noopen.patch (http://people.freebsd.org/~rmacklem/noopen.patch)? >=20 > I'm testing this atm, but having other panics on the same machine > related to vfs locking, so results of the test won't be available too > soon. >=20 > Thank you, >=20 > -Harry >=20 >=20 >=20 From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 10:38:33 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E888497A for ; Fri, 25 Jul 2014 10:38:32 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id AD3242061 for ; Fri, 25 Jul 2014 10:38:32 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooKAGAz0lODaFve/2dsb2JhbABZFoNKVwEDgnTHCodFAYEnd4QDAQEEASNCFAUWDgoCAg0ZAlkGiE0IDad2l0EXgSyMNoEgFTQHgniBTwWOM4hrhXGKH4hXg2QhMIEDQQ X-IronPort-AV: E=Sophos;i="5.01,730,1400040000"; d="scan'208";a="144414953" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 25 Jul 2014 06:38:31 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 24B76B4057; Fri, 25 Jul 2014 06:38:31 -0400 (EDT) Date: Fri, 25 Jul 2014 06:38:31 -0400 (EDT) From: Rick Macklem To: Harald Schmalzbauer Message-ID: <1466875806.3196288.1406284711139.JavaMail.root@uoguelph.ca> In-Reply-To: <53D20A49.5020803@omnilan.de> Subject: Re: nfsd server cache flooded, try to increase nfsrc_floodlevel MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.209] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 10:38:33 -0000 Harald Schmalzbauer wrote: > Bez=C3=BCglich Rick Macklem's Nachricht vom 25.07.2014 02:14 (localtime): > > Harald Schmalzbauer wrote: > >> Bez=C3=BCglich Rick Macklem's Nachricht vom 08.08.2013 14:20 > >> (localtime): > >>> Lars Eggert wrote: > >>>> Hi, > >>>> > >>>> every few days or so, my -STABLE NFS server (v3 and v4) gets > >>>> wedged > >>>> with a ton of messages about "nfsd server cache flooded, try to > >>>> increase nfsrc_floodlevel" in the log, and nfsstat shows TCPPeak > >>>> at > >>>> 16385. It requires a reboot to unwedge, restarting the server > >>>> does > >>>> not help. > >>>> > >>>> The clients are (mostly) six -CURRENT nfsv4 boxes that netboot > >>>> from > >>>> the server and mount all drives from there. > >>>> > > Have you tried increasing vfs.nfsd.tcphighwater? > > This needs to be increased to increase the flood level above 16384. > > > > Garrett Wollman sets: > > vfs.nfsd.tcphighwater=3D100000 > > vfs.nfsd.tcpcachetimeo=3D300 > > > > or something like that, if I recall correctly. >=20 > Thanks you for your help! >=20 > I read about tuning these sysctls, but I object individually altering > these, because I don't have hundreds of clients torturing a poor > server > or any other not well balanced setup. > I run into this problem with one client, connected via 1GbE (not 10 > or > 40GbE) link, talking to modern server with 10G RAM - and this > environment forces me to reboot the storage server every 2nd day. > IMHO such a setup shouldn't require manual tuning and I consider this > as > a really urgent problem! Btw, what you can do to help with this is experiment with the tunable and if you find a setting that works well for your server, report that back as a data point that can be used for this. If you make it too large, the server runs out of address space that can be used by malloc() and that results in the whole machine being wedged and not just the NFS server. > Whatever causes the server to lock up is strongly required to be > fixed > for next release, > otherwise the shipped implementation of NFS is not really suitable > for > production environment and needs a warning message when enabled. > The impact of this failure forces admins to change the operation > system > in order to get a core service back into operation. > The importance is, that I don't suffer from weaker performance or > lags/delays, but my server stops NFS completely and only a reboot > solves > this situation. >=20 > Are there later modifcations or other findings which are known to > obsolete > your noopen.patch (http://people.freebsd.org/~rmacklem/noopen.patch)? >=20 > I'm testing this atm, but having other panics on the same machine > related to vfs locking, so results of the test won't be available too > soon. >=20 > Thank you, >=20 > -Harry >=20 >=20 >=20 From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 10:57:59 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B397CEC for ; Fri, 25 Jul 2014 10:57:59 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D00A62216 for ; Fri, 25 Jul 2014 10:57:58 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s6PAvtB7070083; Fri, 25 Jul 2014 12:57:55 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 45EB5378B; Fri, 25 Jul 2014 12:57:55 +0200 (CEST) Message-ID: <53D23832.6090000@omnilan.de> Date: Fri, 25 Jul 2014 12:57:54 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Rick Macklem Subject: Re: nfsd server cache flooded, try to increase nfsrc_floodlevel References: <1672084785.3195858.1406284379181.JavaMail.root@uoguelph.ca> In-Reply-To: <1672084785.3195858.1406284379181.JavaMail.root@uoguelph.ca> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig25BC1A0F8CB122F4411BA2E1" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Fri, 25 Jul 2014 12:57:55 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 10:57:59 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig25BC1A0F8CB122F4411BA2E1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Rick Macklem's Nachricht vom 25.07.2014 12:32 (localtime)= : > =E2=80=A6 >> environment forces me to reboot the storage server every 2nd day. >> IMHO such a setup shouldn't require manual tuning and I consider this >> as >> a really urgent problem! > Well, the default was what worked for the hardware I have to test on: > - single core i386 server with 256Mbytes of memory on 100Mbps network > > Since I have nothing close to 10Gbps networking (100Mbps only), I can't= > test even a situation like your server/single client, so all I can do > is set a default that works for me. > > I don't think you can expect a "one size fits all" setting when you > have servers ranging from what I have (i386 with 256Mbytes of memory) Very nice to have the possibillity to run an NFS server of this size! I really appreciate keeping minimalistic requirements in mind! > to 64 cores, Gbytes of RAM etc. Eventually, others (like iXsystems mayb= e) > who can test on a range of servers may be able to come up with a way to= > tune it dynamically based on server size, but that requires a range of > hardware to test on. > > Basically, although NFSv4 is now 10years old, people are just starting > to use it, so experience is still pretty limited w.r.t. it. I'm exactly one of this late adopters. But only because building reliable network services had forced me to avoid nfs for almost one decad= e=E2=80=A6 I absolutely understand that one-fits-all doesn't play well here, but a production quality nfsserver implementation must'nt completely lock up becuase of cache measurements on any common setup. I guess having 1GbE is absolutely common for people setting up FreeBSD-9.3. I'm noughty enough to state that 100mbit/s and 256MB RAM is a special case these days! Especially in production environment. And that's what the -Releases should be good for. So, please let's try to make sure that this nfsrc_floodlevel lockup doesn't hit users next -Release again! (and I'm not the only one who reported this problem) If this requires altering sysctl-values, please alter them even if throughput suffers or minmum requirements increase. Anything is better than a locked service which needs rebooting! Again, I'd like to ask if there are reasons known not to use the noopen.patch (http://people.freebsd.org/~rmacklem/noopen.patch)? Thanks, -Harry --------------enig25BC1A0F8CB122F4411BA2E1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlPSODIACgkQLDqVQ9VXb8jLNQCfW3sg2ZiEUGHJzL1bxv/ndtFj mtAAoJXK360tQa3D/xAs84X3SIOn1dl4 =0/a4 -----END PGP SIGNATURE----- --------------enig25BC1A0F8CB122F4411BA2E1-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 11:11:22 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8898FB9 for ; Fri, 25 Jul 2014 11:11:22 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 13E4C2392 for ; Fri, 25 Jul 2014 11:11:21 +0000 (UTC) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s6PBBJgl070218; Fri, 25 Jul 2014 13:11:20 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 89DA93795; Fri, 25 Jul 2014 13:11:19 +0200 (CEST) Message-ID: <53D23B57.8020208@omnilan.de> Date: Fri, 25 Jul 2014 13:11:19 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Rick Macklem Subject: Re: nfsd server cache flooded, try to increase nfsrc_floodlevel References: <1466875806.3196288.1406284711139.JavaMail.root@uoguelph.ca> In-Reply-To: <1466875806.3196288.1406284711139.JavaMail.root@uoguelph.ca> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6BF2466DEC75AAEEEF472C52" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Fri, 25 Jul 2014 13:11:20 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 11:11:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6BF2466DEC75AAEEEF472C52 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Rick Macklem's Nachricht vom 25.07.2014 12:38 (localtime)= : > Harald Schmalzbauer wrote: >> Bez=C3=BCglich Rick Macklem's Nachricht vom 25.07.2014 02:14 (localtim= e): >>> Harald Schmalzbauer wrote: >>>> Bez=C3=BCglich Rick Macklem's Nachricht vom 08.08.2013 14:20 >>>> (localtime): >>>>> Lars Eggert wrote: >>>>>> Hi, >>>>>> >>>>>> every few days or so, my -STABLE NFS server (v3 and v4) gets >>>>>> wedged >>>>>> with a ton of messages about "nfsd server cache flooded, try to >>>>>> increase nfsrc_floodlevel" in the log, and nfsstat shows TCPPeak >>>>>> at >>>>>> 16385. It requires a reboot to unwedge, restarting the server >>>>>> does >>>>>> not help. >>>>>> >>>>>> The clients are (mostly) six -CURRENT nfsv4 boxes that netboot >>>>>> from >>>>>> the server and mount all drives from there. >>>>>> >>> Have you tried increasing vfs.nfsd.tcphighwater? >>> This needs to be increased to increase the flood level above 16384. >>> >>> Garrett Wollman sets: >>> vfs.nfsd.tcphighwater=3D100000 >>> vfs.nfsd.tcpcachetimeo=3D300 >>> >>> or something like that, if I recall correctly. >> Thanks you for your help! >> >> I read about tuning these sysctls, but I object individually altering >> these, because I don't have hundreds of clients torturing a poor >> server >> or any other not well balanced setup. >> I run into this problem with one client, connected via 1GbE (not 10 >> or >> 40GbE) link, talking to modern server with 10G RAM - and this >> environment forces me to reboot the storage server every 2nd day. >> IMHO such a setup shouldn't require manual tuning and I consider this >> as >> a really urgent problem! > Btw, what you can do to help with this is experiment with the tunable > and if you find a setting that works well for your server, report that > back as a data point that can be used for this. > > If you make it too large, the server runs out of address space that > can be used by malloc() and that results in the whole machine being > wedged and not just the NFS server. I'd happily provide experience results, but I see my environment (the only one I reintroduced nfs atm.) as uncommon, because few LANs out there have NFS services with just two clientes, where only one does really use nfs. So before tuning sysctls in other production environments than my own (small and uncommon) setup, I need to be prooven that nfs is usable these days (v4). If the noopen.patch prooves to be one possibility to stabilize things, I'll be able to find out optimized settings of vfs.nfsd.tcp*. Then I could have the patched kernel in addation, which I need to be able to ensure reliable service. Additinally I should first read somhere what they are doing to get the right understanding=E2=80=A6 Thanks, -Harry P.S.: I'd happily donate some used GbE switch+server if that helps! --------------enig6BF2466DEC75AAEEEF472C52 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlPSO1cACgkQLDqVQ9VXb8iH9gCfffWM0OMO1RuiSJ4tsM0Dtx1U f+IAn3yyjKEf35NzGm1aIaen6O4LiOI4 =gYG4 -----END PGP SIGNATURE----- --------------enig6BF2466DEC75AAEEEF472C52-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 11:14:03 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EDEDC2F6 for ; Fri, 25 Jul 2014 11:14:03 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id B421723CA for ; Fri, 25 Jul 2014 11:14:03 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkKAJE70lODaFve/2dsb2JhbABZFoNKVwEDgnTHDIdFAYEnd4QDAQEEASNCFAUWDgoCAg0ZAlkGiE0IDagLl0AXgSyMNoEgFTQHgniBUQWOOYhvhXGKIIhYg2QhMIEDQQ X-IronPort-AV: E=Sophos;i="5.01,730,1400040000"; d="scan'208";a="144418237" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 25 Jul 2014 07:14:02 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 699C9B3F1A; Fri, 25 Jul 2014 07:14:02 -0400 (EDT) Date: Fri, 25 Jul 2014 07:14:02 -0400 (EDT) From: Rick Macklem To: Harald Schmalzbauer Message-ID: <2146856958.3199855.1406286842423.JavaMail.root@uoguelph.ca> In-Reply-To: <53D20A49.5020803@omnilan.de> Subject: Re: nfsd server cache flooded, try to increase nfsrc_floodlevel MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 11:14:04 -0000 Harald Schmalzbauer wrote: > Bez=C3=BCglich Rick Macklem's Nachricht vom 25.07.2014 02:14 (localtime): > > Harald Schmalzbauer wrote: > >> Bez=C3=BCglich Rick Macklem's Nachricht vom 08.08.2013 14:20 > >> (localtime): > >>> Lars Eggert wrote: > >>>> Hi, > >>>> > >>>> every few days or so, my -STABLE NFS server (v3 and v4) gets > >>>> wedged > >>>> with a ton of messages about "nfsd server cache flooded, try to > >>>> increase nfsrc_floodlevel" in the log, and nfsstat shows TCPPeak > >>>> at > >>>> 16385. It requires a reboot to unwedge, restarting the server > >>>> does > >>>> not help. > >>>> > >>>> The clients are (mostly) six -CURRENT nfsv4 boxes that netboot > >>>> from > >>>> the server and mount all drives from there. > >>>> > > Have you tried increasing vfs.nfsd.tcphighwater? > > This needs to be increased to increase the flood level above 16384. > > > > Garrett Wollman sets: > > vfs.nfsd.tcphighwater=3D100000 > > vfs.nfsd.tcpcachetimeo=3D300 > > > > or something like that, if I recall correctly. >=20 > Thanks you for your help! >=20 > I read about tuning these sysctls, but I object individually altering > these, because I don't have hundreds of clients torturing a poor > server > or any other not well balanced setup. > I run into this problem with one client, connected via 1GbE (not 10 > or > 40GbE) link, talking to modern server with 10G RAM - and this > environment forces me to reboot the storage server every 2nd day. > IMHO such a setup shouldn't require manual tuning and I consider this > as > a really urgent problem! > Whatever causes the server to lock up is strongly required to be > fixed > for next release, > otherwise the shipped implementation of NFS is not really suitable > for > production environment and needs a warning message when enabled. > The impact of this failure forces admins to change the operation > system > in order to get a core service back into operation. > The importance is, that I don't suffer from weaker performance or > lags/delays, but my server stops NFS completely and only a reboot > solves > this situation. >=20 Btw, you can increase vfs.nfsd.tcphighwater on the fly when it wedges and avoid having to reboot. > Are there later modifcations or other findings which are known to > obsolete > your noopen.patch (http://people.freebsd.org/~rmacklem/noopen.patch)? >=20 > I'm testing this atm, but having other panics on the same machine > related to vfs locking, so results of the test won't be available too > soon. >=20 > Thank you, >=20 > -Harry >=20 >=20 >=20 From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 11:31:13 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DCAF8AEF for ; Fri, 25 Jul 2014 11:31:13 +0000 (UTC) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 70C31257B for ; Fri, 25 Jul 2014 11:31:13 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id k48so4212311wev.12 for ; Fri, 25 Jul 2014 04:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=pQcqQ47E6Azlt3W1rBLviNpkIfCZBQ4j37IrR4/U+iE=; b=wIxXIiC7EZyLqFQ97QMd4AW3C/AFJTDgAloJXWfyXot1bvMBGrtuB08Z+5sME07X7N kBTe/gdlYRFm8fMJhIHrVGfU/OOJIVMCwio5cGoFKX2+27mQb+OukazvJjZfFfuxXMJV IfJHJfoGrpExYMJu0VtD8D7MW7SXh68hu0FUAq6k3VKvqUWlh+7cRjd69wX5MnNXAqZz FL8hpmMqO/HY4IR+AcN5gIZtDIgDKHQz8uNashhBQ8qwtAt4zzEZ+tJ6G6pXPojbXw1c kLeUGm1BLYy2bqoGfePIJm9AAuOuHlqtnR9MtuOznzTv7m58dxvy8R1AbalqBsMC0NAb hb2g== X-Received: by 10.194.187.4 with SMTP id fo4mr20734268wjc.35.1406287871665; Fri, 25 Jul 2014 04:31:11 -0700 (PDT) Received: from brick.home (cmu49.neoplus.adsl.tpnet.pl. [83.31.148.49]) by mx.google.com with ESMTPSA id ey16sm4856574wid.14.2014.07.25.04.31.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Jul 2014 04:31:11 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Fri, 25 Jul 2014 13:31:06 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Nils Beyer Subject: Re: link_elf_obj: symbol icl_pdu_new_bhs undefined Message-ID: <20140725113106.GA1231@brick.home> Mail-Followup-To: Nils Beyer , freebsd-stable@freebsd.org References: <53D15B4C.40104@egr.msu.edu> <20140725071853.5C488510@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140725071853.5C488510@hub.freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 11:31:14 -0000 On 0725T0918, Nils Beyer wrote: > Hi Adam, > > Adam McDougall wrote: > > Yes, someone on irc ran into it, I confirmed it with -stable, and > > someone beat me to filing a bug report: > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192031 > > That was me. Unfortunately, there hasn't been any interest in that report > yet and I don't know how to fix that on my own. So I've reverted to r268571 > and live with it now... Thanks for tracking it down! I've committed a fix to CURRENT, will MFC in three days. I wonder what broke it. Some linker changes? From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 13:45:27 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9669B551 for ; Fri, 25 Jul 2014 13:45:27 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 43BE322D9 for ; Fri, 25 Jul 2014 13:45:26 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id s6PDjOTY076583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 25 Jul 2014 07:45:24 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id s6PDjNZS076580; Fri, 25 Jul 2014 07:45:24 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Fri, 25 Jul 2014 07:45:23 -0600 (MDT) From: Warren Block To: "Patrick M. Hausen" Subject: Re: Gmirror + gpart corruption on 9.3-PRE In-Reply-To: Message-ID: References: <53D1BDB2.7030906@jetcafe.org> <53D1DD47.4040403@jetcafe.org> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Fri, 25 Jul 2014 07:45:24 -0600 (MDT) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 13:45:27 -0000 On Fri, 25 Jul 2014, Patrick M. Hausen wrote: > Am 25.07.2014 um 07:34 schrieb Warren Block : >> True. But partitioning can be specific to the drive. It's not like GPT-partitioned drives can be copied with dd (well, not correctly). > > Errrr ... sorry, but ... could you please elaborate on that? Up until now I was sure that any drive could be > copied with dd(1). > > Puzzled. :-) GPT partitioning puts a primary partition table at the beginning of the drive, and a backup partition table at the end of the drive. Use dd to copy a 500G drive to a 1TB drive, and that backup partition is now in the middle of the drive. If the drives are even a single block different in size, that backup table will be in the wrong place, not found by the software and effectively lost. This is dd's bug/feature: it does not understand the data being copied. gpart(8) can back up and restore partition tables between differently-sized drives, and does it correctly. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 15:14:54 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27D6DCC0 for ; Fri, 25 Jul 2014 15:14:54 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BD6F72C37 for ; Fri, 25 Jul 2014 15:14:53 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s6PFEmQV005076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2014 18:14:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s6PFEmQV005076 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s6PFEmQi005075; Fri, 25 Jul 2014 18:14:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 25 Jul 2014 18:14:48 +0300 From: Konstantin Belousov To: Harald Schmalzbauer Subject: Re: panic/lock on 9.3-RELEASE with nullfs/nfs/zfs combination Message-ID: <20140725151448.GY93733@kib.kiev.ua> References: <53D12973.3010805@omnilan.de> <20140724165917.GT93733@kib.kiev.ua> <53D1503B.2030200@omnilan.de> <20140724193048.GU93733@kib.kiev.ua> <53D2006C.7090207@omnilan.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VmIAD9aKo2BNqjfq" Content-Disposition: inline In-Reply-To: <53D2006C.7090207@omnilan.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 15:14:54 -0000 --VmIAD9aKo2BNqjfq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 25, 2014 at 08:59:56AM +0200, Harald Schmalzbauer wrote: > Bez?glich Konstantin Belousov's Nachricht vom 24.07.2014 21:30 > (localtime): > > On Thu, Jul 24, 2014 at 08:28:11PM +0200, Harald Schmalzbauer wrote: > >> Bez??glich Konstantin Belousov's Nachricht vom 24.07.2014 18:59 > >> (localtime): > >>> ??? > >>> The lockmgr flags are LK_SHARE | LK_RETRY, and error 11 =3D=3D EDEADLK > >>> indicates that the lock is already taken by the curthread in the > >>> exclusive mode. I am interested in what line of code did the locking. > >>> > >>> Add ddb, INVARIANTS, WITNESS and DEBUG_VFS_LOCKS options to the kernel > >>> config, reproduce the issue and, after the panic occured and you > >>> get at the ddb prompt, issue command 'show alllocks'. > >>> > >>> Also, do 'show mount', after which do 'show mount ', where > >>> is the address of your nullfs mount point, printed by 'show mount'. > >>> > >>> I need all console output starting from the panic message. > >> FreeBSD/amd64 (mira.inop.mo1.omnilan.net) (ttyu0) > >> > >> login: panic: LK_RETRY set with incompatible flags (0x200400) or an > >> error occured (11) > >> cpuid =3D 1 > >> KDB: stack backtrace: > >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame > >> 0xffffff82e565fc70 > >> kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff82e565fd30 > >> panic() at panic+0x1cd/frame 0xffffff82e565fe30 > >> _vn_lock() at _vn_lock+0x77/frame 0xffffff82e565fe90 > >> zfs_lookup() at zfs_lookup+0x420/frame 0xffffff82e565ff20 > >> zfs_freebsd_lookup() at zfs_freebsd_lookup+0xa6/frame 0xffffff82e56600= 70 > >> VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0x102/frame > >> 0xffffff82e56600a0 > >> vfs_cache_lookup() at vfs_cache_lookup+0xff/frame 0xffffff82e5660110 > >> VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x102/frame 0xffffff82e5660140 > >> null_lookup() at null_lookup+0x92/frame 0xffffff82e56601c0 > >> VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x102/frame 0xffffff82e56601f0 > >> lookup() at lookup+0x32f/frame 0xffffff82e5660290 > >> namei() at namei+0x3df/frame 0xffffff82e5660340 > >> vn_open_cred() at vn_open_cred+0x1e2/frame 0xffffff82e56604b0 > >> vop_stdvptocnp() at vop_stdvptocnp+0x1af/frame 0xffffff82e56607e0 > >> null_vptocnp() at null_vptocnp+0xf5/frame 0xffffff82e5660850 > >> VOP_VPTOCNP_APV() at VOP_VPTOCNP_APV+0x105/frame 0xffffff82e5660880 > >> vn_vptocnp_locked() at vn_vptocnp_locked+0x15b/frame 0xffffff82e5660910 > >> vn_fullpath1() at vn_fullpath1+0x100/frame 0xffffff82e5660970 > >> kern___getcwd() at kern___getcwd+0xd4/frame 0xffffff82e56609d0 > >> amd64_syscall() at amd64_syscall+0x318/frame 0xffffff82e5660af0 > >> Xfast_syscall() at Xfast_syscall+0xf7/frame 0xffffff82e5660af0 > >> --- syscall (326, FreeBSD ELF64, sys___getcwd), rip =3D 0x8011a191c, r= sp =3D > >> 0x7fffffffe658, rbp =3D 0x801873400 --- > >> KDB: enter: panic > >> [ thread pid 1918 tid 100919 ] > >> Stopped at kdb_enter+0x3b: movq $0,0x645622(%rip) > >> db> show alllocks > >> db> > You do not have WITNESS in your kernel config, most likely. >=20 > Hmm enabled it is, from the boot msg: > gcc version 4.2.1 20070831 patched [FreeBSD] > WARNING: WITNESS option enabled, expect reduced performance. > CPU: Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz (3292.52-MHz K8-class CPU) >=20 > But there's another WITNESS message: > WITNESS: unable to allocate a new witness object. > Ill ask the relatives what they know about this message (aunt bing, > uncle google aso). Yes, this is the problem. In sys/kern/subr_witness.c, change the #define WITNESS_COUNT from 1024 to e.g. 2048. --VmIAD9aKo2BNqjfq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT0nRoAAoJEJDCuSvBvK1BTK8P/0li4bzqj3SKJ7PfCxLKWh9+ p7Ns/8JoTkYTESlvVVekUypCciHovMgZqxTWICtfQdM5Ibbgq4WdIo1kXq1VBcba VZrSkbGUp9zR2nWs5JKCmU/E6C6i3/6V9FtSxOHGYricpA5loZytOuFBhdT0sDQ3 S/1ZWb8CNmKpkFajnezvx6P9QYzVZ3Ms0cWT3cGieJhzplgvQHNOsi7Aqwr/9lJD ptGsetfm/P6tNDTIVPQXsklHdxwP5ZlxoDCyoAri/oqw/aCuHlkyye/paHd1wKWa pNYw8Xl2arodIAbT9lON6wVRpmSHdJAjkz6u79qmVZEOnP3jOr+DqRstuQScTsQU fTqbEAGu636cpFHxFg+49EbgW8Ah+16l/tnZGXWOSLfm2cYlQ3Qdk+Z2aRD4rS0h +5GSO4oHMFFHyVkD2Lp8adZlwxzHvbu+nK6SicVv9WQJyZCYJihFZL5T3PGoBff4 vlhTLWAd3+/Jn7dOnF189eEnuiKqyQrR8chL/QC6ZEwO0v+5zDWQ8RuElBED3fjR x1Xvjhl6pK1STdVWSOR+WGDk7cMcVWQyw31qso0HvSyAEfZfA1iG3ETTy/VqgEXH qqWPX5rQwjLQyoRJyn2s8cwJ9ld5I75xyn4RWlul847buax1B2YMqNxnPQH4TJbQ 4IESM9X8WpJClNsSBwtG =Z7Pa -----END PGP SIGNATURE----- --VmIAD9aKo2BNqjfq-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 18:03:06 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28C5E8FF; Fri, 25 Jul 2014 18:03:06 +0000 (UTC) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CCE9F2C32; Fri, 25 Jul 2014 18:03:05 +0000 (UTC) Received: by mail-qg0-f46.google.com with SMTP id z60so5493247qgd.33 for ; Fri, 25 Jul 2014 11:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HU1LDgbrrq4tCsi+ZGJLd1MHhjHZ/x1gFhQ/DO474d0=; b=pOLEzcdEZPsZdfVEQPgxrGHLANVsuYdj7wI6hQyT6hZnwZSSZ2iVVPq8gjTKZBFqON 6GqxXYcpQbmeymjQ53W+XM3ajRYs+3Jdhvoreu3dGTNnkTG8rV8ouX8WAcbT1ucqnDd7 fAZRRbMrhq8DVX/yQ5nVo6JXpjBlg07d95xE8JG6wi/mBQiTU4/f0IB+c94iRrejWDyr 1gR6NjtVtQbOPRmRgy4hAHXLcDMvGJ1lvJ3ysi37kFOMx5BSDFCp4gx5OUj4jhE3Ac0C RCQE5vnIonElTp6cw1UwWgdSK4KE4Inj5xTF+I+0Z4n/OTgUCCNoRyFbPTbXpgeeY+zw JQ5Q== MIME-Version: 1.0 X-Received: by 10.224.28.66 with SMTP id l2mr30449761qac.46.1406311384978; Fri, 25 Jul 2014 11:03:04 -0700 (PDT) Sender: carpeddiem@gmail.com Received: by 10.140.50.243 with HTTP; Fri, 25 Jul 2014 11:03:04 -0700 (PDT) In-Reply-To: References: <201406262133.s5QLXXP8029811@svn.freebsd.org> Date: Fri, 25 Jul 2014 14:03:04 -0400 X-Google-Sender-Auth: Pp5tpDK5dAbo1mPenZrIv0kMPDQ Message-ID: Subject: Re: svn commit: r267935 - head/sys/dev/e1000 From: Ed Maste To: Jack Vogel Content-Type: text/plain; charset=UTF-8 Cc: Jack F Vogel , "stable@freebsd.org" , hiren panchasara X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 18:03:06 -0000 >> On Wed, Jul 16, 2014 at 11:49 PM, Herbert J. Skuhra wrote: >> > Den 26.06.2014 23:33, skrev Jack F Vogel: >> > >> >> Author: jfv >> >> Date: Thu Jun 26 21:33:32 2014 >> >> New Revision: 267935 >> >> URL: http://svnweb.freebsd.org/changeset/base/267935 >> >> >> >> Log: >> >> Sync the E1000 shared code with Intel internal, this adds fixes, >> >> and more importantly, new I218 adapter support to the em driver. >> >> >> >> MFC after: 1 week >> > >> > >> > Does anyone know when this will be commited to stable/10? >> > Any open issues with this change? > > On 17 July 2014 03:31, Jack Vogel wrote: > Will try to squeeze it in between crises next week :) Hi Jack - do you think you'll be able to tackle this soon? It will be very good to get test exposure in advance of the fast-approaching 10.1 release process. Thanks, Ed From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 19:43:41 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 569CD4EF; Fri, 25 Jul 2014 19:43:41 +0000 (UTC) Received: from smtp-out-01.shaw.ca (smtp-out-01.shaw.ca [64.59.136.137]) by mx1.freebsd.org (Postfix) with ESMTP id ED8A2263E; Fri, 25 Jul 2014 19:43:40 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=BkBxTXsSVzyY7C2joSQK+JNK4mJr1It1Skr7Xe8+Jh8= c=1 sm=1 a=7V3fggXvsmQA:10 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=8nJEP1OIZ-IA:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=6I5d2MoRAAAA:8 a=BWvPGDcYAAAA:8 a=1KmhjRZRDwvG-PhjtxoA:9 a=wPNLvfGTeEIA:10 a=RgXXd5XzHKoA:10 a=SV7veod9ZcQA:10 a=V7tsTZBp22UA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-01.shaw.ca with ESMTP; 25 Jul 2014 13:42:32 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id 110F1A46C; Fri, 25 Jul 2014 12:42:32 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.9/8.14.9) with ESMTP id s6PJCVZN003786; Fri, 25 Jul 2014 12:12:31 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.14.9/8.14.8/Submit) with ESMTP id s6PHK8YX095747; Fri, 25 Jul 2014 10:20:08 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201407251720.s6PHK8YX095747@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: trasz@FreeBSD.org Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2014 In-Reply-To: Message from Glen Barber of "Thu, 24 Jul 2014 14:33:53 -0400." <20140724183353.GL1065@hub.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Jul 2014 10:19:55 -0700 Cc: Glen Barber , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 19:43:41 -0000 In message <20140724183353.GL1065=40hub.FreeBSD.org>, Glen Barber writes:= > New Automounter >=20 > Contact: Edward Tomasz Napieral/a >=20 > Deficiencies in the current automounter, amd(8), are a recurring > problem reported by many FreeBSD users. A new automounter is being > developed to address these concerns. >=20 > The automounter is a cleanroom implementation of functionality > available in most other Unix systems, using proper kernel support > implemented via an autofs filesystem. The automounter supports a > standard map format, and will integrate with the Lightweight Directo= ry > Access Protocol (LDAP) service. Will it also integrate with NIS (as SunOS and Solaris do)? FreeBSD's amd = currently integrates with NIS as well. --=20 Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 21:12:58 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 236DF7AF; Fri, 25 Jul 2014 21:12:58 +0000 (UTC) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D2432E4A; Fri, 25 Jul 2014 21:12:57 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id q58so4743405wes.18 for ; Fri, 25 Jul 2014 14:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=5CixpQx38wT7/cblhEdhEC7smrirlwRu2Ll1zdl9o+w=; b=DV0Jki0iD3c0brggRxNDicviEHnc0t1iYZJ/SAyY1ocoJHWv/iFz2F8A9wWAmkVsUp j3LYaUtrLbgTHyyXKcib3PJUpQDG9+4lBJ6GqHNfEOJMnxqTIjHZyYr0SgeqUgyJXrw7 pQCNABtN5jvBAmSUR2mw7VGa1RvMYq6cWm33WtoU9iebJrKezgM82QEsJsk6CfpWX3wl iNOkJU2SLl9loTDTzGpgo4f+H7pZjdfTUk1x3kxGdkkZR+mez0uRRHZfby6+7PfGW8aC 59F4CbE6IQvRks6c/1KbTIetNwTi6ovUeoHhqJxsaa/7zRdd3DHiCPRHg2Qk9Ttxcnr9 6PLQ== X-Received: by 10.180.221.172 with SMTP id qf12mr8791812wic.54.1406322775536; Fri, 25 Jul 2014 14:12:55 -0700 (PDT) Received: from brick.home (cmu49.neoplus.adsl.tpnet.pl. [83.31.148.49]) by mx.google.com with ESMTPSA id u10sm10363103wix.14.2014.07.25.14.12.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Jul 2014 14:12:54 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Fri, 25 Jul 2014 23:12:49 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Cy Schubert Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2014 Message-ID: <20140725211249.GA3933@brick.home> Mail-Followup-To: Cy Schubert , Glen Barber , freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org References: <20140724183353.GL1065@hub.FreeBSD.org> <201407251720.s6PHK8YX095747@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201407251720.s6PHK8YX095747@slippy.cwsent.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Glen Barber , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 21:12:58 -0000 On 0725T1019, Cy Schubert wrote: > In message <20140724183353.GL1065@hub.FreeBSD.org>, Glen Barber writes: > > New Automounter > > > > Contact: Edward Tomasz Napieral/a > > > > Deficiencies in the current automounter, amd(8), are a recurring > > problem reported by many FreeBSD users. A new automounter is being > > developed to address these concerns. > > > > The automounter is a cleanroom implementation of functionality > > available in most other Unix systems, using proper kernel support > > implemented via an autofs filesystem. The automounter supports a > > standard map format, and will integrate with the Lightweight Directory > > Access Protocol (LDAP) service. > > Will it also integrate with NIS (as SunOS and Solaris do)? FreeBSD's amd > currently integrates with NIS as well. It's just a matter of testing, apart from a trivial shell script. Would you be able to help me with this? From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 22:54:04 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9CC934C for ; Fri, 25 Jul 2014 22:54:04 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 902932764 for ; Fri, 25 Jul 2014 22:54:04 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAOPe0lODaFve/2dsb2JhbABZhDuCdM0JgxcBgSV3hAMBAQQBI0IUBRYOCgICDRkCWQaITQinR5cWF4EsjVYVATMHgniBUQWOOZkAiFiDZCGBM0E X-IronPort-AV: E=Sophos;i="5.01,733,1400040000"; d="scan'208";a="143685607" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 25 Jul 2014 18:54:03 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 46D87B40A2; Fri, 25 Jul 2014 18:54:03 -0400 (EDT) Date: Fri, 25 Jul 2014 18:54:03 -0400 (EDT) From: Rick Macklem To: Harald Schmalzbauer Message-ID: <666117227.3741955.1406328843281.JavaMail.root@uoguelph.ca> In-Reply-To: <53D23B57.8020208@omnilan.de> Subject: Re: nfsd server cache flooded, try to increase nfsrc_floodlevel MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.209] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 22:54:04 -0000 Harald Schmalzbauer wrote: > Bez=C3=BCglich Rick Macklem's Nachricht vom 25.07.2014 12:38 (localtime): > > Harald Schmalzbauer wrote: > >> Bez=C3=BCglich Rick Macklem's Nachricht vom 25.07.2014 02:14 > >> (localtime): > >>> Harald Schmalzbauer wrote: > >>>> Bez=C3=BCglich Rick Macklem's Nachricht vom 08.08.2013 14:20 > >>>> (localtime): > >>>>> Lars Eggert wrote: > >>>>>> Hi, > >>>>>> > >>>>>> every few days or so, my -STABLE NFS server (v3 and v4) gets > >>>>>> wedged > >>>>>> with a ton of messages about "nfsd server cache flooded, try > >>>>>> to > >>>>>> increase nfsrc_floodlevel" in the log, and nfsstat shows > >>>>>> TCPPeak > >>>>>> at > >>>>>> 16385. It requires a reboot to unwedge, restarting the server > >>>>>> does > >>>>>> not help. > >>>>>> > >>>>>> The clients are (mostly) six -CURRENT nfsv4 boxes that netboot > >>>>>> from > >>>>>> the server and mount all drives from there. > >>>>>> > >>> Have you tried increasing vfs.nfsd.tcphighwater? > >>> This needs to be increased to increase the flood level above > >>> 16384. > >>> > >>> Garrett Wollman sets: > >>> vfs.nfsd.tcphighwater=3D100000 > >>> vfs.nfsd.tcpcachetimeo=3D300 > >>> > >>> or something like that, if I recall correctly. > >> Thanks you for your help! > >> > >> I read about tuning these sysctls, but I object individually > >> altering > >> these, because I don't have hundreds of clients torturing a poor > >> server > >> or any other not well balanced setup. > >> I run into this problem with one client, connected via 1GbE (not > >> 10 > >> or > >> 40GbE) link, talking to modern server with 10G RAM - and this > >> environment forces me to reboot the storage server every 2nd day. > >> IMHO such a setup shouldn't require manual tuning and I consider > >> this > >> as > >> a really urgent problem! > > Btw, what you can do to help with this is experiment with the > > tunable > > and if you find a setting that works well for your server, report > > that > > back as a data point that can be used for this. > > > > If you make it too large, the server runs out of address space that > > can be used by malloc() and that results in the whole machine being > > wedged and not just the NFS server. >=20 > I'd happily provide experience results, but I see my environment (the > only one I reintroduced nfs atm.) as uncommon, because few LANs out > there have NFS services with just two clientes, where only one does > really use nfs. > So before tuning sysctls in other production environments than my own > (small and uncommon) setup, I need to be prooven that nfs is usable > these days (v4). If the noopen.patch prooves to be one possibility to > stabilize things, I'll be able to find out optimized settings of > vfs.nfsd.tcp*. > Then I could have the patched kernel in addation, which I need to be > able to ensure reliable service. Note that, for this situation it isn't the number of clients, but the number of different processes on the client(s) that is the issue. For example: Client type A - Has a long running process that opens/closes many files. This one will only result in one OpenOwner and probably wouldn't exceed 16K OpenOwners, even for 1000s of clients. Client type B - Parent process forks a lot of children who open files. This one results in an OpenOwner for each of the forked child processes and even a single client of this type could exceed 16K OpenOwners. Each process on a client that opens a file results in an OpenOwner. Unfortunately, for NFSv4.0, there is no well defined time when an OpenOwner can be safely deleted. It must be retained until the related Opens are clos= ed, but retaining it longer helps w.r.t. correct behaviour if a networking part= ition occurs. As such, I made the default timeout for OenOwners very conservative at 12hrs. You definitely want to decrease this (vfs.nfsd.tcpcachetimeo), po= ssibly as low as 300sec. After this change, I suspect your single client case will be resolved and y= ou can see what the peek value for OpenOwners is for one client. Then multiply that by the number of clients you wish to support and set vfs.nfsd.tcphighwater to that value. The key piece of information to help figure out how to tune this dynamicall= y is the server machine's memory and arch (32 vs 64bit) plus a value for vfs.nfsd.tcphighwater that it runs stably at. (And the peek value of OpenOw= ner that you see while in operation.) The problem with setting vfs.nfsd.tcphighwater too large is that an overloa= ded server can run out of kernel address space/memory it can use for malloc() a= nd then the whole machine wedges. (I can only test to see what is safe for a 256Mbyte i386.) If you can't get tunable values of the above that work, you can set vfs.nfsd.cachetcp=3D0 and then this problem goes away, although the result is a level of correctness for non-idempotent operations that is the same as the old NFS server (which didn't try to use the DRC for TCP). All of this is fixed by a component of NFSv4.1 called sessions. rick > Additinally I should first read somhere what they are doing to get > the > right understanding=E2=80=A6 >=20 > Thanks, >=20 > -Harry >=20 > P.S.: I'd happily donate some used GbE switch+server if that helps! >=20 >=20 From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 23:11:47 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94496B3F for ; Fri, 25 Jul 2014 23:11:47 +0000 (UTC) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 52D8628A8 for ; Fri, 25 Jul 2014 23:11:47 +0000 (UTC) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.14.7/8.14.7) with ESMTP id s6PNBYdC087960; Fri, 25 Jul 2014 19:11:34 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.14.7/8.14.4/Submit) id s6PNBYid087959; Fri, 25 Jul 2014 19:11:34 -0400 (EDT) (envelope-from wollman) Date: Fri, 25 Jul 2014 19:11:34 -0400 (EDT) Message-Id: <201407252311.s6PNBYid087959@hergotha.csail.mit.edu> From: Garrett Wollman To: rmacklem@uoguelph.ca Subject: Re: nfsd server cache flooded, try to increase nfsrc_floodlevel References: <53D23B57.8020208@omnilan.de> <666117227.3741955.1406328843281.JavaMail.root@uoguelph.ca> Organization: none X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (hergotha.csail.mit.edu [127.0.0.1]); Fri, 25 Jul 2014 19:11:34 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, HEADER_FROM_DIFFERENT_DOMAINS autolearn=disabled version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on hergotha.csail.mit.edu Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 23:11:47 -0000 In article <666117227.3741955.1406328843281.JavaMail.root@uoguelph.ca>, Rick Macklem writes: >The problem with setting vfs.nfsd.tcphighwater too large is that an overloaded >server can run out of kernel address space/memory it can use for malloc() and >then the whole machine wedges. (I can only test to see what is safe for a >256Mbyte i386.) Rick, The FreeBSD Foundation maintains significant resources in the various FreeBSD clusters for the purpose of testing FreeBSD on a variety of hardware platforms and scales. Why don't you ask them for access to some of these systems so you can run tests of your own? I don't think it would be hard to come up with a test plan that would cover at least the most common cases. -GAWollman From owner-freebsd-stable@FreeBSD.ORG Fri Jul 25 23:16:50 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80647DD6 for ; Fri, 25 Jul 2014 23:16:50 +0000 (UTC) Received: from nahkohe.jetcafe.org (nahkohe.jetcafe.org [205.147.26.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5E7C82958 for ; Fri, 25 Jul 2014 23:16:49 +0000 (UTC) X-Envelope-To: freebsd-stable@freebsd.org Received: from [205.147.26.4] (hokkshideh.jetcafe.org [205.147.26.4]) by nahkohe.jetcafe.org (8.14.2/8.14.2) with ESMTP id s6PNGm6M004448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Jul 2014 16:16:48 -0700 (PDT) Message-ID: <53D2E560.5090100@jetcafe.org> Date: Fri, 25 Jul 2014 16:16:48 -0700 From: Dave Hayes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Warren Block Subject: Re: Gmirror + gpart corruption on 9.3-PRE References: <53D1BDB2.7030906@jetcafe.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 23:16:50 -0000 On 07/24/2014 21:04, Warren Block wrote: > On Thu, 24 Jul 2014, Dave Hayes wrote: > >> At 9.3-PRERELEASE #0 r268066M I've been trying unsucessfuly to set up >> a brand shiny new gmirror + gpt style Raid 0 mirror using the >> following procedure on a disk >> >> gpart create -s gpt ada0 >> ( shows 931G of space) >> gpart add -s 96G -t freebsd-swap -l swap0 ada0 >> gpart add -t freebsd-ufs -l rw0 ada0 >> gpart create -s gpt ada1 >> gpart add -s 96G -t freebsd-swap -l swap1 ada1 >> gpart add -t freebsd-ufs -l rw1 ada1 >> gmirror label swap /dev/ada0p1 /dev/ada1p1 >> gmirror label rw /dev/ada0p2 /dev/ada1p2 I need to be clearer. Above is the point at which the corrupt table message is encountered. I believe the above is the equivalent of your method, and hence your method may not work on 9.3-PRE and above. If you happen to be able to test this, I'd be curious as to the results. I'm going to try gmirroring the entire disk and and using BSD labels for separate partitions. I think this will have the effect I want, and it's worth a test. -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>>> *The opinions expressed above are entirely my own* <<<< A neighbor asked Nasrudin to borrow his donkey. "It is out on loan," said the Mulla. At that moment the donkey was heard to bray, somewhere inside the stable. "But I can hear it bray, in there." "Whom do you believe," said the Mulla, "me or a donkey?" From owner-freebsd-stable@FreeBSD.ORG Sat Jul 26 00:32:19 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA06565F for ; Sat, 26 Jul 2014 00:32:19 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8AA122F8E for ; Sat, 26 Jul 2014 00:32:18 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.9/8.14.9) with ESMTP id s6Q0WHp5037316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 25 Jul 2014 18:32:17 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.9/8.14.9/Submit) with ESMTP id s6Q0WHQK037313; Fri, 25 Jul 2014 18:32:17 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Fri, 25 Jul 2014 18:32:17 -0600 (MDT) From: Warren Block To: Dave Hayes Subject: Re: Gmirror + gpart corruption on 9.3-PRE In-Reply-To: <53D2E560.5090100@jetcafe.org> Message-ID: References: <53D1BDB2.7030906@jetcafe.org> <53D2E560.5090100@jetcafe.org> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Fri, 25 Jul 2014 18:32:17 -0600 (MDT) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 00:32:19 -0000 On Fri, 25 Jul 2014, Dave Hayes wrote: > On 07/24/2014 21:04, Warren Block wrote: >> On Thu, 24 Jul 2014, Dave Hayes wrote: >> >>> At 9.3-PRERELEASE #0 r268066M I've been trying unsucessfuly to set up >>> a brand shiny new gmirror + gpt style Raid 0 mirror using the >>> following procedure on a disk >>> >>> gpart create -s gpt ada0 >>> ( shows 931G of space) >>> gpart add -s 96G -t freebsd-swap -l swap0 ada0 >>> gpart add -t freebsd-ufs -l rw0 ada0 >>> gpart create -s gpt ada1 >>> gpart add -s 96G -t freebsd-swap -l swap1 ada1 >>> gpart add -t freebsd-ufs -l rw1 ada1 >>> gmirror label swap /dev/ada0p1 /dev/ada1p1 >>> gmirror label rw /dev/ada0p2 /dev/ada1p2 > > I need to be clearer. Above is the point at which the corrupt table message > is encountered. I believe the above is the equivalent of your method, and > hence your method may not work on 9.3-PRE and above. If you happen to be able > to test this, I'd be curious as to the results. Just tried here with 10-STABLE, although only a single drive in the mirror. # gpart destroy -F da0 da0 destroyed # gpart create -s gpt da0 da0 created # gpart add -s 4g -t freebsd-swap -l swap0 da0 da0p1 added # gpart add -t freebsd-ufs -l rw0 da0 da0p2 added # gmirror label swap /dev/da0p1 # gmirror label rw /dev/da0p2 # ls /dev/mirror ls: /dev/mirror: No such file or directory # gmirror load # gpart show da0 => 34 117210173 da0 GPT (56G) 34 8388608 1 freebsd-swap (4.0G) 8388642 108821565 2 freebsd-ufs (52G) # ls /dev/mirror rw swap root@lightning# gpart show da0 => 34 117210173 da0 GPT (56G) 34 8388608 1 freebsd-swap (4.0G) 8388642 108821565 2 freebsd-ufs (52G) # gmirror status Name Status Components mirror/swap COMPLETE da0p1 (ACTIVE) mirror/rw COMPLETE da0p2 (ACTIVE) # newfs -U /dev/mirror/rw /dev/mirror/rw: 53135.5MB (108821560 sectors) block size 32768, fragment size 4096 using 85 cylinder groups of 626.09MB, 20035 blks, 80256 inodes. with soft updates ... # newfs -U /dev/mirror/swap /dev/mirror/swap: 4096.0MB (8388600 sectors) block size 32768, fragment size 4096 using 7 cylinder groups of 626.09MB, 20035 blks, 80256 inodes. with soft updates ... # gpart show da0 => 34 117210173 da0 GPT (56G) 34 8388608 1 freebsd-swap (4.0G) 8388642 108821565 2 freebsd-ufs (52G) The 'gpart show' would have shown "corrupt" if something overwrote the backup GPT. The only kernel messages were: kernel: GEOM_MIRROR: Cancelling unmapped because of da0p1. kernel: GEOM_MIRROR: Device mirror/swap launched (1/1). kernel: GEOM_MIRROR: Cancelling unmapped because of da0p2. kernel: GEOM_MIRROR: Device mirror/rw launched (1/1). Now I'll create GPT partitioning inside the mirrors: # gpart create -s gpt mirror/swap mirror/swap created # gpart add -s3g -t freebsd-swap mirror/swap mirror/swapp1 added # gpart create -s gpt mirror/rw mirror/rw created # gpart add -t freebsd-ufs mirror/rw mirror/rwp1 added # gpart show mirror/swap => 34 8388540 mirror/swap GPT (4.0G) 34 6291456 1 freebsd-swap (3.0G) 6291490 2097084 - free - (1.0G) # gpart show mirror/rw => 34 108821497 mirror/rw GPT (52G) 34 108821497 1 freebsd-ufs (52G) # newfs -U /dev/mirror/rwp1 /dev/mirror/rwp1: 53135.5MB (108821496 sectors) block size 32768, fragment size 4096 using 85 cylinder groups of 626.09MB, 20035 blks, 80256 inodes. with soft updates ... No errors. After disconnecting and reconnecting the drive: # gpart show da0 => 34 117210173 da0 GPT (56G) 34 8388608 1 freebsd-swap (4.0G) 8388642 108821565 2 freebsd-ufs (52G) # gpart show mirror/swap => 34 8388540 mirror/swap GPT (4.0G) 34 6291456 1 freebsd-swap (3.0G) 6291490 2097084 - free - (1.0G) # gpart show mirror/rw => 34 108821497 mirror/rw GPT (52G) 34 108821497 1 freebsd-ufs (52G) This is actually working better than it should. I'm getting lost in the recursion, but maybe comparison will help. > I'm going to try gmirroring the entire disk and and using BSD labels for > separate partitions. I think this will have the effect I want, and it's worth > a test. That would be a "dangerously dedicated" layout. It's pretty much the same as standard MBR/bsdlabel layout, but may be less likely to boot on modern systems. From owner-freebsd-stable@FreeBSD.ORG Sat Jul 26 02:46:43 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14CE5616; Sat, 26 Jul 2014 02:46:43 +0000 (UTC) Received: from smtp-out-02.shaw.ca (smtp-out-02.shaw.ca [64.59.136.138]) by mx1.freebsd.org (Postfix) with ESMTP id BA50328C9; Sat, 26 Jul 2014 02:46:41 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=UbGOdjJMTOnDdlSKs4VLEv47Nwxh2hlhayjdFxkzNJk= c=1 sm=1 a=7V3fggXvsmQA:10 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=6I5d2MoRAAAA:8 a=BWvPGDcYAAAA:8 a=jn4Z1P99xdyqle8XhOAA:9 a=CjuIK1q_8ugA:10 a=RgXXd5XzHKoA:10 a=SV7veod9ZcQA:10 a=V7tsTZBp22UA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-02.shaw.ca with ESMTP; 25 Jul 2014 20:46:34 -0600 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id A52EBA56F; Fri, 25 Jul 2014 19:46:34 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.9/8.14.9) with ESMTP id s6Q2kXdV013283; Fri, 25 Jul 2014 19:46:33 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.14.9/8.14.8/Submit) with ESMTP id s6Q2kX7n013280; Fri, 25 Jul 2014 19:46:33 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201407260246.s6Q2kX7n013280@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Cy Schubert , Glen Barber , freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2014 In-Reply-To: Message from Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= of "Fri, 25 Jul 2014 23:12:49 +0200." <20140725211249.GA3933@brick.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Jul 2014 19:46:33 -0700 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 02:46:43 -0000 In message <20140725211249.GA3933@brick.home>, Edward Tomasz =?utf-8?Q?Napiera= C5=82a?= writes: > On 0725T1019, Cy Schubert wrote: > > In message <20140724183353.GL1065@hub.FreeBSD.org>, Glen Barber writes: > > > New Automounter > > > > > > Contact: Edward Tomasz Napieral/a > > > > > > Deficiencies in the current automounter, amd(8), are a recurring > > > problem reported by many FreeBSD users. A new automounter is being > > > developed to address these concerns. > > > > > > The automounter is a cleanroom implementation of functionality > > > available in most other Unix systems, using proper kernel support > > > implemented via an autofs filesystem. The automounter supports a > > > standard map format, and will integrate with the Lightweight Directory > > > Access Protocol (LDAP) service. > > > > Will it also integrate with NIS (as SunOS and Solaris do)? FreeBSD's amd > > currently integrates with NIS as well. > > It's just a matter of testing, apart from a trivial shell script. > Would you be able to help me with this? > Sure! Just point me in the direction of the patches. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-stable@FreeBSD.ORG Sat Jul 26 06:35:12 2014 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D86455A1; Sat, 26 Jul 2014 06:35:12 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8B5902B8F; Sat, 26 Jul 2014 06:35:12 +0000 (UTC) Received: from latte.bs.cs.huji.ac.il ([132.65.179.20] helo=mbpro2.bs.cs.huji.ac.il) by kabab.cs.huji.ac.il with esmtp id 1XAvZO-000GTG-Oc; Sat, 26 Jul 2014 09:35:02 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2014 From: Daniel Braniss In-Reply-To: <201407260246.s6Q2kX7n013280@slippy.cwsent.com> Date: Sat, 26 Jul 2014 09:40:04 +0300 Content-Transfer-Encoding: 7bit Message-Id: <53C46240-10B2-453C-A077-8C151A4B391C@cs.huji.ac.il> References: <201407260246.s6Q2kX7n013280@slippy.cwsent.com> To: Cy Schubert X-Mailer: Apple Mail (2.1878.6) Cc: Glen Barber , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 06:35:12 -0000 On Jul 26, 2014, at 5:46 AM, Cy Schubert wrote: > In message <20140725211249.GA3933@brick.home>, Edward Tomasz > =?utf-8?Q?Napiera= > C5=82a?= writes: >> On 0725T1019, Cy Schubert wrote: >>> In message <20140724183353.GL1065@hub.FreeBSD.org>, Glen Barber writes: >>>> New Automounter >>>> >>>> Contact: Edward Tomasz Napieral/a >>>> >>>> Deficiencies in the current automounter, amd(8), are a recurring >>>> problem reported by many FreeBSD users. A new automounter is being >>>> developed to address these concerns. >>>> >>>> The automounter is a cleanroom implementation of functionality >>>> available in most other Unix systems, using proper kernel support >>>> implemented via an autofs filesystem. The automounter supports a >>>> standard map format, and will integrate with the Lightweight Directory >>>> Access Protocol (LDAP) service. >>> >>> Will it also integrate with NIS (as SunOS and Solaris do)? FreeBSD's amd >>> currently integrates with NIS as well. >> and hesiod? i can help with the testing danny >> It's just a matter of testing, apart from a trivial shell script. >> Would you be able to help me with this? >> > > > Sure! Just point me in the direction of the patches. > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Sat Jul 26 10:03:57 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D736D3 for ; Sat, 26 Jul 2014 10:03:57 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 10E312BE1 for ; Sat, 26 Jul 2014 10:03:56 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s6QA3rjd083082; Sat, 26 Jul 2014 12:03:53 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id B4F4C3A65; Sat, 26 Jul 2014 12:03:52 +0200 (CEST) Message-ID: <53D37D08.2000104@omnilan.de> Date: Sat, 26 Jul 2014 12:03:52 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Rick Macklem Subject: Re: nfsd server cache flooded, try to increase nfsrc_floodlevel References: <2146856958.3199855.1406286842423.JavaMail.root@uoguelph.ca> In-Reply-To: <2146856958.3199855.1406286842423.JavaMail.root@uoguelph.ca> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig356C2EC62062CDEBB8D2BE15" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Sat, 26 Jul 2014 12:03:53 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 10:03:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig356C2EC62062CDEBB8D2BE15 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Rick Macklem's Nachricht vom 25.07.2014 13:14 (localtime)= : > Harald Schmalzbauer wrote: >> Bez=C3=BCglich Rick Macklem's Nachricht vom 25.07.2014 02:14 (localtim= e): >>> Harald Schmalzbauer wrote: >>>> Bez=C3=BCglich Rick Macklem's Nachricht vom 08.08.2013 14:20 >>>> (localtime): >>>>> Lars Eggert wrote: >>>>>> Hi, >>>>>> >>>>>> every few days or so, my -STABLE NFS server (v3 and v4) gets >>>>>> wedged >>>>>> with a ton of messages about "nfsd server cache flooded, try to >>>>>> increase nfsrc_floodlevel" in the log, and nfsstat shows TCPPeak >>>>>> at >>>>>> 16385. It requires a reboot to unwedge, restarting the server >>>>>> does >>>>>> not help. >>>>>> >>>>>> =E2=80=A6 >> IMHO such a setup shouldn't require manual tuning and I consider this >> as >> a really urgent problem! >> Whatever causes the server to lock up is strongly required to be >> fixed >> for next release, >> otherwise the shipped implementation of NFS is not really suitable >> for >> production environment and needs a warning message when enabled. >> The impact of this failure forces admins to change the operation >> system >> in order to get a core service back into operation. >> The importance is, that I don't suffer from weaker performance or >> lags/delays, but my server stops NFS completely and only a reboot >> solves >> this situation. >> > Btw, you can increase vfs.nfsd.tcphighwater on the fly when it wedges > and avoid having to reboot. One suggestion: If raising vfs.nfsd.tcphighwater at runtime solves the locked nfsserver (which I thought I have tried, but I'm not sure any more), maybe the log message should reflect that. My first guess was to look for a systcl named 'nfsrc_floodlevel'. If the log message makes more sense to contain nfsrc_floodlevel instead of tcphighwater, the latter should be metioned in the man page anyway. If the problem is solvable without rebooting, it's a cosmetic problem IMHO, not that serious show stopper I considered at first. Evereything but a reboot is fine ;-) Thanks, -Harry --------------enig356C2EC62062CDEBB8D2BE15 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlPTfQgACgkQLDqVQ9VXb8jGEgCgsSdlFmMhy8ykYbcyTLdgsUrI HX4AoJ6f6Rq526YVBy4RXc3iMW2AUpv6 =uqjU -----END PGP SIGNATURE----- --------------enig356C2EC62062CDEBB8D2BE15-- From owner-freebsd-stable@FreeBSD.ORG Sat Jul 26 10:19:34 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADDC03DC for ; Sat, 26 Jul 2014 10:19:34 +0000 (UTC) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 07A972CBB for ; Sat, 26 Jul 2014 10:19:33 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s6QAJVo5083203; Sat, 26 Jul 2014 12:19:31 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 423CE3A6B; Sat, 26 Jul 2014 12:19:31 +0200 (CEST) Message-ID: <53D380B2.2080700@omnilan.de> Date: Sat, 26 Jul 2014 12:19:30 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: panic/lock on 9.3-RELEASE with nullfs/nfs/zfs combination References: <53D12973.3010805@omnilan.de> <20140724165917.GT93733@kib.kiev.ua> <53D1503B.2030200@omnilan.de> <20140724193048.GU93733@kib.kiev.ua> <53D2006C.7090207@omnilan.de> <20140725151448.GY93733@kib.kiev.ua> In-Reply-To: <20140725151448.GY93733@kib.kiev.ua> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig38F03A934E680565AC552C34" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Sat, 26 Jul 2014 12:19:32 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 10:19:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig38F03A934E680565AC552C34 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Bez=C3=BCglich Konstantin Belousov's Nachricht vom 25.07.2014 17:14 (localtime): > On Fri, Jul 25, 2014 at 08:59:56AM +0200, Harald Schmalzbauer wrote: >> =E2=80=A6 >> But there's another WITNESS message: >> WITNESS: unable to allocate a new witness object. >> Ill ask the relatives what they know about this message (aunt bing, >> uncle google aso). > Yes, this is the problem. In sys/kern/subr_witness.c, change the > #define WITNESS_COUNT from 1024 to e.g. 2048. Thank you very much, havn't found it myself :-( FreeBSD/amd64 (mira.inop.mo1.omnilan.net) (ttyu0) login: shared lock of (lockmgr) zfs @ /usr/local/share/deploy-tools/RELENG_9_3/src/sys/modules/zfs/../../cddl/c= ontrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1513 while exclusively locked from /usr/local/share/deploy-tools/RELENG_9_3/src/sys/modules/zfs/../../cddl/c= ontrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1511 panic: share->excl cpuid =3D 2 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xffffff82e526da80 kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff82e526db40 panic() at panic+0x1cd/frame 0xffffff82e526dc40 witness_checkorder() at witness_checkorder+0x161/frame 0xffffff82e526dd00= __lockmgr_args() at __lockmgr_args+0x150a/frame 0xffffff82e526dde0 vop_stdlock() at vop_stdlock+0x39/frame 0xffffff82e526de00 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xe3/frame 0xffffff82e526de30 _vn_lock() at _vn_lock+0x57/frame 0xffffff82e526de90 zfs_lookup() at zfs_lookup+0x420/frame 0xffffff82e526df20 zfs_freebsd_lookup() at zfs_freebsd_lookup+0xa6/frame 0xffffff82e526e070 VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0x102/frame 0xffffff82e526e0a0 vfs_cache_lookup() at vfs_cache_lookup+0xff/frame 0xffffff82e526e110 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x102/frame 0xffffff82e526e140 null_lookup() at null_lookup+0x92/frame 0xffffff82e526e1c0 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0x102/frame 0xffffff82e526e1f0 lookup() at lookup+0x32f/frame 0xffffff82e526e290 namei() at namei+0x3df/frame 0xffffff82e526e340 vn_open_cred() at vn_open_cred+0x1e2/frame 0xffffff82e526e4b0 vop_stdvptocnp() at vop_stdvptocnp+0x1af/frame 0xffffff82e526e7e0 null_vptocnp() at null_vptocnp+0xf5/frame 0xffffff82e526e850 VOP_VPTOCNP_APV() at VOP_VPTOCNP_APV+0x105/frame 0xffffff82e526e880 vn_vptocnp_locked() at vn_vptocnp_locked+0x15b/frame 0xffffff82e526e910 vn_fullpath1() at vn_fullpath1+0x100/frame 0xffffff82e526e970 kern___getcwd() at kern___getcwd+0xd4/frame 0xffffff82e526e9d0 amd64_syscall() at amd64_syscall+0x318/frame 0xffffff82e526eaf0 Xfast_syscall() at Xfast_syscall+0xf7/frame 0xffffff82e526eaf0 --- syscall (326, FreeBSD ELF64, sys___getcwd), rip =3D 0x8011a191c, rsp = =3D 0x7fffffffe658, rbp =3D 0x801873400 --- KDB: enter: panic [ thread pid 1668 tid 100854 ] Stopped at kdb_enter+0x3b: movq $0,0x645622(%rip) db> show alllocks Process 1668 (vim) thread 0xfffffe0033498920 (100854) exclusive lockmgr zfs (zfs) r =3D 0 (0xfffffe001dbc5488) locked @ /usr/local/share/deploy-tools/RELENG_9_3/src/sys/modules/zfs/../../cddl/c= ontrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1511 db> show mount =E2=80=A6 0xfffffe0033a24338 /zfs/netshares/deployment/pub/FreeBSD/OmniLAN/ports/ports on /.JAILfbsm/usr/ports (nullfs) =E2=80=A6 db> show mount 0xfffffe0033a24338 0xfffffe0033a24338 /zfs/netshares/deployment/pub/FreeBSD/OmniLAN/ports/ports on /.JAILfbsm/usr/ports (nullfs) mnt_flag =3D LOCAL mnt_kern_flag =3D EXTENDED_SHARED, SHARED_WRITES, LOOKUP_EXCL_DOTDOT, MPSAFE, LOOKUP_SHARED mnt_opt =3D rw, fstype, fspath, target, errmsg mnt_stat =3D { version=3D537068824 type=3D222 flags=3D0x0000000000001000 bsize=3D512 iosize=3D131072 blocks=3D6314029472 bfree=3D6309830941 bavail=3D6309830941 files=3D6310126321 ffree=3D6309830941 syncwrites=3D0 asyncwrites=3D0 syncreads=3D0 asyncreads=3D0 namemax=3D255 owner=3D0 fsid=3D[687931140, 41] } mnt_cred =3D { uid=3D0 ruid=3D0 } mnt_ref =3D 24 mnt_gen =3D 1 mnt_nvnodelistsize =3D 24 mnt_activevnodelistsize =3D 5 mnt_writeopcount =3D 0 mnt_maxsymlinklen =3D 0 mnt_iosize_max =3D 65536 mnt_hashseed =3D 279534051 mnt_secondary_writes =3D 0 mnt_secondary_accwrites =3D 0 mnt_gjprovider =3D NULL List of active vnodes vnode vnode 0xfffffe01077375e8: 0xfffffe01077375e8: tag null, type VDIR tag null, type VDIR usecount 2, writecount 0, refcount 2 mountedhere 0 usecount 2, writecount 0, refcount 2 mountedhere 0 flags (VI_ACTIVE) flags (VI_ACTIVE) v_object 0xfffffe006c8d30e8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe006c8d30e8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: EXCL by thread 0xfffffe0033498920 (pid 1668) lock type zfs: EXCL by thread 0xfffffe0033498920 (pid 1668) vp=3D0xfffffe01077375e8, lowervp=3D0xfffffe001dbc53f0 vp=3D0xfffffe01077375e8, lowervp=3D0xfffffe001dbc53f0 vnode vnode 0xfffffe006cdf79d8: 0xfffffe006cdf79d8: tag null, type VDIR tag null, type VDIR usecount 3, writecount 0, refcount 3 mountedhere 0 usecount 3, writecount 0, refcount 3 mountedhere 0 flags (VI_ACTIVE) flags (VI_ACTIVE) v_object 0xfffffe006c76eae0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe006c76eae0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe006cdf79d8, lowervp=3D0xfffffe006cdf77e0 vp=3D0xfffffe006cdf79d8, lowervp=3D0xfffffe006cdf77e0 vnode vnode 0xfffffe006cb67000: 0xfffffe006cb67000: tag null, type VDIR tag null, type VDIR usecount 1, writecount 0, refcount 1 mountedhere 0xfffffe001dc0e9a8 usecount 1, writecount 0, refcount 1 mountedhere 0xfffffe001dc0e9a8 flags (VI_ACTIVE) flags (VI_ACTIVE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe006cb67000, lowervp=3D0xfffffe006cb671f8 vp=3D0xfffffe006cb67000, lowervp=3D0xfffffe006cb671f8 vnode vnode 0xfffffe006cb869d8: 0xfffffe006cb869d8: tag syncer, type VNON= tag syncer, type VNON usecount 1, writecount 0, refcount 1 mountedhere 0 usecount 1, writecount 0, refcount 1 mountedhere 0 flags (VI_ACTIVE) flags (VI_ACTIVE) lock type syncer: UNLOCKED lock type syncer: UNLOCKED vnode vnode 0xfffffe006cb86bd0: 0xfffffe006cb86bd0: tag null, type VDIR tag null, type VDIR usecount 1, writecount 0, refcount 1 mountedhere 0 usecount 1, writecount 0, refcount 1 mountedhere 0 flags (VV_ROOT|VI_ACTIVE) flags (VV_ROOT|VI_ACTIVE) v_object 0xfffffe006c8d30e8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe006c8d30e8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: EXCL by thread 0xfffffe0033498920 (pid 1668) lock type zfs: EXCL by thread 0xfffffe0033498920 (pid 1668) vp=3D0xfffffe006cb86bd0, lowervp=3D0xfffffe001dbc53f0 vp=3D0xfffffe006cb86bd0, lowervp=3D0xfffffe001dbc53f0 List of inactive vnodes vnode vnode 0xfffffe006cd8a1f8: 0xfffffe006cd8a1f8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe006c718cb0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe006c718cb0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe006cd8a1f8, lowervp=3D0xfffffe006c895bd0 vp=3D0xfffffe006cd8a1f8, lowervp=3D0xfffffe006c895bd0 vnode vnode 0xfffffe006cebf1f8: 0xfffffe006cebf1f8: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe006ce740e8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe006ce740e8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe006cebf1f8, lowervp=3D0xfffffe006cebf3f0 vp=3D0xfffffe006cebf1f8, lowervp=3D0xfffffe006cebf3f0 vnode vnode 0xfffffe006cdf6000: 0xfffffe006cdf6000: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe006cdf6000, lowervp=3D0xfffffe006cddfdc8 vp=3D0xfffffe006cdf6000, lowervp=3D0xfffffe006cddfdc8 vnode vnode 0xfffffe006cdf63f0: 0xfffffe006cdf63f0: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe006ce75570 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe006ce75570 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe006cdf63f0, lowervp=3D0xfffffe006cdf61f8 vp=3D0xfffffe006cdf63f0, lowervp=3D0xfffffe006cdf61f8 vnode vnode 0xfffffe006cdf6dc8: 0xfffffe006cdf6dc8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe006cdf6dc8, lowervp=3D0xfffffe006cdf65e8 vp=3D0xfffffe006cdf6dc8, lowervp=3D0xfffffe006cdf65e8 vnode vnode 0xfffffe006cdf75e8: 0xfffffe006cdf75e8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe006cdf75e8, lowervp=3D0xfffffe006cdf73f0 vp=3D0xfffffe006cdf75e8, lowervp=3D0xfffffe006cdf73f0 vnode vnode 0xfffffe006cdf7dc8: 0xfffffe006cdf7dc8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe006cdd7ae0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe006cdd7ae0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe006cdf7dc8, lowervp=3D0xfffffe006cdf7bd0 vp=3D0xfffffe006cdf7dc8, lowervp=3D0xfffffe006cdf7bd0 vnode vnode 0xfffffe006cde41f8: 0xfffffe006cde41f8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe006cde41f8, lowervp=3D0xfffffe006cde4000 vp=3D0xfffffe006cde41f8, lowervp=3D0xfffffe006cde4000 vnode vnode 0xfffffe006cde45e8: 0xfffffe006cde45e8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe006cde45e8, lowervp=3D0xfffffe006cde43f0 vp=3D0xfffffe006cde45e8, lowervp=3D0xfffffe006cde43f0 vnode vnode 0xfffffe006cde49d8: 0xfffffe006cde49d8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe006cde49d8, lowervp=3D0xfffffe006cde47e0 vp=3D0xfffffe006cde49d8, lowervp=3D0xfffffe006cde47e0 vnode vnode 0xfffffe0033460bd0: 0xfffffe0033460bd0: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe0033460bd0, lowervp=3D0xfffffe006c56e000 vp=3D0xfffffe0033460bd0, lowervp=3D0xfffffe006c56e000 vnode vnode 0xfffffe006cfa85e8: 0xfffffe006cfa85e8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe006cfa85e8, lowervp=3D0xfffffe006cde51f8 vp=3D0xfffffe006cfa85e8, lowervp=3D0xfffffe006cde51f8 vnode vnode 0xfffffe006cfa81f8: 0xfffffe006cfa81f8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe006cfa81f8, lowervp=3D0xfffffe006cfa83f0 vp=3D0xfffffe006cfa81f8, lowervp=3D0xfffffe006cfa83f0 vnode vnode 0xfffffe006cfa7dc8: 0xfffffe006cfa7dc8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe006cfa7dc8, lowervp=3D0xfffffe006cfa8000 vp=3D0xfffffe006cfa7dc8, lowervp=3D0xfffffe006cfa8000 vnode vnode 0xfffffe006cfa79d8: 0xfffffe006cfa79d8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe006cfa79d8, lowervp=3D0xfffffe006cfa7bd0 vp=3D0xfffffe006cfa79d8, lowervp=3D0xfffffe006cfa7bd0 vnode vnode 0xfffffe006cfa75e8: 0xfffffe006cfa75e8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe006cfa75e8, lowervp=3D0xfffffe006cfa77e0 vp=3D0xfffffe006cfa75e8, lowervp=3D0xfffffe006cfa77e0 vnode vnode 0xfffffe006cfa71f8: 0xfffffe006cfa71f8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe006cfa71f8, lowervp=3D0xfffffe006cfa73f0 vp=3D0xfffffe006cfa71f8, lowervp=3D0xfffffe006cfa73f0 vnode vnode 0xfffffe006cfa6dc8: 0xfffffe006cfa6dc8: tag null, type VREG tag null, type VREG usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe006cfa6dc8, lowervp=3D0xfffffe006cfa7000 vp=3D0xfffffe006cfa6dc8, lowervp=3D0xfffffe006cfa7000 vnode vnode 0xfffffe01077377e0: 0xfffffe01077377e0: tag null, type VDIR tag null, type VDIR usecount 0, writecount 0, refcount 0 mountedhere 0 usecount 0, writecount 0, refcount 0 mountedhere 0 flags (VI_FREE) flags (VI_FREE) v_object 0xfffffe006c718cb0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 v_object 0xfffffe006c718cb0 ref 0 pages 0 cleanbuf 0 dirtybuf 0 lock type zfs: UNLOCKED lock type zfs: UNLOCKED vp=3D0xfffffe01077377e0, lowervp=3D0xfffffe006c895bd0 vp=3D0xfffffe01077377e0, lowervp=3D0xfffffe006c895bd0 Hope this is more useful. Maybe these LORs are not very interesting (haven't check if they are on the begnin list), but I get these now after raising WITNESS_COUNT: lock order reversal: 1st 0xfffffe0007b3f680 unionfs (unionfs) @ /usr/local/share/deploy-tools/RELENG_9_3/src/sys/fs/unionfs/union_subr.c:= 368 2nd 0xfffffe000779e098 ufs (ufs) @ /usr/local/share/deploy-tools/RELENG_9_3/src/sys/kern/vfs_subr.c:2337 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xffffff82e10ce180 kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff82e10ce240 _witness_debugger() at _witness_debugger+0x2c/frame 0xffffff82e10ce260 witness_checkorder() at witness_checkorder+0x875/frame 0xffffff82e10ce320= __lockmgr_args() at __lockmgr_args+0x1197/frame 0xffffff82e10ce400 ffs_lock() at ffs_lock+0x9c/frame 0xffffff82e10ce450 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xe3/frame 0xffffff82e10ce480 _vn_lock() at _vn_lock+0x57/frame 0xffffff82e10ce4e0 vputx() at vputx+0x310/frame 0xffffff82e10ce540 unionfs_noderem() at unionfs_noderem+0x1d7/frame 0xffffff82e10ce5c0 unionfs_reclaim() at unionfs_reclaim+0x11/frame 0xffffff82e10ce5d0 VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0x105/frame 0xffffff82e10ce600 vgonel() at vgonel+0x12f/frame 0xffffff82e10ce670 vrecycle() at vrecycle+0x5a/frame 0xffffff82e10ce6a0 unionfs_inactive() at unionfs_inactive+0x20/frame 0xffffff82e10ce6b0 VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0x105/frame 0xffffff82e10ce6e0 vinactive() at vinactive+0xa4/frame 0xffffff82e10ce730 vputx() at vputx+0x425/frame 0xffffff82e10ce790 kern_statat_vnhook() at kern_statat_vnhook+0x15b/frame 0xffffff82e10ce910= kern_statat() at kern_statat+0x15/frame 0xffffff82e10ce930 sys_lstat() at sys_lstat+0x2a/frame 0xffffff82e10ce9d0 amd64_syscall() at amd64_syscall+0x318/frame 0xffffff82e10ceaf0 Xfast_syscall() at Xfast_syscall+0xf7/frame 0xffffff82e10ceaf0 --- syscall (190, FreeBSD ELF64, sys_lstat), rip =3D 0x80060fa0c, rsp =3D= 0x7fffffffd6d8, rbp =3D 0 --- lock order reversal: 1st 0xffffff826a62da08 bufwait (bufwait) @ /usr/local/share/deploy-tools/RELENG_9_3/src/sys/kern/vfs_bio.c:3140 2nd 0xfffffe0033431000 dirhash (dirhash) @ /usr/local/share/deploy-tools/RELENG_9_3/src/sys/ufs/ufs/ufs_dirhash.c:28= 4 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xffffff82e114b2d0 kdb_backtrace() at kdb_backtrace+0x37/frame 0xffffff82e114b390 _witness_debugger() at _witness_debugger+0x2c/frame 0xffffff82e114b3b0 witness_checkorder() at witness_checkorder+0x875/frame 0xffffff82e114b470= _sx_xlock() at _sx_xlock+0x70/frame 0xffffff82e114b4a0 ufsdirhash_acquire() at ufsdirhash_acquire+0x44/frame 0xffffff82e114b4c0 ufsdirhash_add() at ufsdirhash_add+0x19/frame 0xffffff82e114b4f0 ufs_direnter() at ufs_direnter+0x6d8/frame 0xffffff82e114b5c0 ufs_mkdir() at ufs_mkdir+0x501/frame 0xffffff82e114b7b0 VOP_MKDIR_APV() at VOP_MKDIR_APV+0x105/frame 0xffffff82e114b7e0 kern_mkdirat() at kern_mkdirat+0x290/frame 0xffffff82e114b9d0 amd64_syscall() at amd64_syscall+0x318/frame 0xffffff82e114baf0 Xfast_syscall() at Xfast_syscall+0xf7/frame 0xffffff82e114baf0 --- syscall (136, FreeBSD ELF64, sys_mkdir), rip =3D 0x80091324c, rsp =3D= 0x7fffffffe778, rbp =3D 0x800c07050 --- Thanks, -Harry --------------enig38F03A934E680565AC552C34 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlPTgLIACgkQLDqVQ9VXb8g6dQCdHS4v7yicMkVrUQiFAH88lQdS 4zQAn3eHF0HJ/LEWg5jl61/nPUkuYpgt =OAOM -----END PGP SIGNATURE----- --------------enig38F03A934E680565AC552C34-- From owner-freebsd-stable@FreeBSD.ORG Sat Jul 26 11:48:46 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B7456C5 for ; Sat, 26 Jul 2014 11:48:46 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A765A23DC for ; Sat, 26 Jul 2014 11:48:45 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s6QBmdmK029711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Jul 2014 14:48:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s6QBmdmK029711 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s6QBmdS3029710; Sat, 26 Jul 2014 14:48:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 26 Jul 2014 14:48:39 +0300 From: Konstantin Belousov To: Harald Schmalzbauer Subject: Re: panic/lock on 9.3-RELEASE with nullfs/nfs/zfs combination Message-ID: <20140726114839.GF93733@kib.kiev.ua> References: <53D12973.3010805@omnilan.de> <20140724165917.GT93733@kib.kiev.ua> <53D1503B.2030200@omnilan.de> <20140724193048.GU93733@kib.kiev.ua> <53D2006C.7090207@omnilan.de> <20140725151448.GY93733@kib.kiev.ua> <53D380B2.2080700@omnilan.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lmwYJyD+fGI+a3sE" Content-Disposition: inline In-Reply-To: <53D380B2.2080700@omnilan.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 11:48:46 -0000 --lmwYJyD+fGI+a3sE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 26, 2014 at 12:19:30PM +0200, Harald Schmalzbauer wrote: > vnode vnode 0xfffffe006cb86bd0: 0xfffffe006cb86bd0: tag null, type VDIR > tag null, type VDIR > usecount 1, writecount 0, refcount 1 mountedhere 0 > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags (VV_ROOT|VI_ACTIVE) > flags (VV_ROOT|VI_ACTIVE) > v_object 0xfffffe006c8d30e8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 > v_object 0xfffffe006c8d30e8 ref 0 pages 0 cleanbuf 0 dirtybuf 0 > lock type zfs: EXCL by thread 0xfffffe0033498920 (pid 1668) > lock type zfs: EXCL by thread 0xfffffe0033498920 (pid 1668) > vp=3D0xfffffe006cb86bd0, lowervp=3D0xfffffe001dbc53f0 > vp=3D0xfffffe006cb86bd0, lowervp=3D0xfffffe001dbc53f0 >=20 It is useful, but still requires more work to get to the issue. From the data you posted, I see that the problem was already reported sometime this winter. We did not come to any conclusion that time. Please, do the following. First, apply this debugging patch and obtain the same data as you did right now. Hopefully, the assert below would trigger. diff --git a/sys/fs/nullfs/null_vnops.c b/sys/fs/nullfs/null_vnops.c index 70402e3..bc9772c 100644 --- a/sys/fs/nullfs/null_vnops.c +++ b/sys/fs/nullfs/null_vnops.c @@ -372,6 +372,10 @@ null_lookup(struct vop_lookup_args *ap) */ ldvp =3D NULLVPTOLOWERVP(dvp); vp =3D lvp =3D NULL; + KASSERT((ldvp->v_vflag & VV_ROOT) =3D=3D 0 || + ((dvp->v_vflag & VV_ROOT) !=3D 0 && (flags & ISDOTDOT) =3D=3D 0), + ("ldvp %p fl %#x dvp %p fl %#x flags %#x", ldvp, ldvp->v_vflag, + dvp, dvp->v_vflag, flags)); error =3D VOP_LOOKUP(ldvp, &lvp, cnp); if (error =3D=3D EJUSTRETURN && (flags & ISLASTCN) && (dvp->v_mount->mnt_flag & MNT_RDONLY) && After that, you could try the patch which I posted at winter, but which was not tested. I do not know whether it is of any help, and I do need the debugging information with the patch above before I can make any conclusions. diff --git a/sys/fs/nullfs/null_subr.c b/sys/fs/nullfs/null_subr.c index fa6c4af..3f74579 100644 --- a/sys/fs/nullfs/null_subr.c +++ b/sys/fs/nullfs/null_subr.c @@ -251,6 +251,7 @@ null_nodeget(mp, lowervp, vpp) vp->v_type =3D lowervp->v_type; vp->v_data =3D xp; vp->v_vnlock =3D lowervp->v_vnlock; + vp->v_vflag =3D lowervp->v_vflag & VV_ROOT; error =3D insmntque1(vp, mp, null_insmntque_dtr, xp); if (error !=3D 0) return (error); --lmwYJyD+fGI+a3sE Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT05WXAAoJEJDCuSvBvK1BeogP/jNVZIb8Bz6mf5ec2OimQBMZ H3bTLf+KHW1eR6F9CHLLafgmoiIf4Pa735Uer8BEruxvbwKOF13yqnRTMk2UEyNG bPe1uIV/+KAMfHgdPFUUo/46Tav9xCLAYbYPBBthTl+4pW5ZoG7h6IKF9zEQZQy4 7qOLAp5tZjFMT2zCKpT105vXYs3mgEZHKIotLzT/SmTD6ddpDH7oYBSrRmtRe1LD wGmMplA2SWiMi7/kFHafQbMhDS7fQXZ0JJJnQbYO1SgSFm5eBh/eCfzGNh48RJCr PJ4Br8v3N0Hw1p8FMzFoZ4nk7e4pz0d/WPV3jh/JPJwb1rQFCRa37e9zeWsqIdQm pp+dGFOVcFGQByAlC9Q6+U0l2DKEMp7BiBN+F2YAlYE+sgzh2fZr+Gj24pl6nVC7 ZTj3gZOwIP5cw0SwWQAQUIob3Lj8zkh0nk5tCUJCpUh1kHSc9ySAnvgBI+CWU4no lLrUE1Zk4XX/xhmP4gDP6Nl0KnjLvVc1L699r0/O0+S1iHbC4ny/vd13fkwhM7Wa M49jn3WpF4n7FC7hX/XReT8HU8TnLmotrfQdBUHiiJGBpVOCRYJQ2osmQuBbGOqL UIDoyIGJJ7cklfchLsR86QwRKfb6NYQ57OABfkgX62UHkwlVi4FfqJ61A+Ub+cXE Rj/qIdlxxN1WuxMz74KP =MPp0 -----END PGP SIGNATURE----- --lmwYJyD+fGI+a3sE-- From owner-freebsd-stable@FreeBSD.ORG Sat Jul 26 13:22:34 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55E13E38; Sat, 26 Jul 2014 13:22:34 +0000 (UTC) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6CAA62BCC; Sat, 26 Jul 2014 13:22:33 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id x48so5409334wes.17 for ; Sat, 26 Jul 2014 06:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=ppqEkfihE/lsMCuo50Sgpd699uh+4aTfKFl3ghjoKt4=; b=j4ofrRrx64wzHS8Z537Am5wndOylhAYctYQSuV/fVSdDqGt6E4ousT11cxBew0OE7B 4owAUxv9glPztU3Ee3pUmml2vtcJh6NMhK3OGNigm14iq3MSA5U7Jv3bHX7q/arR6tBk XVaZ11to0R+xLt+VCDdfHqvErtW3hDsof3jEPxdg55Tl92ih2GIbLizh/g2uNBErkSb0 V8iCIpikD32VTP4kmxaFZI3D3hlLMSjpq2EbQ6Qn7cFv3SeKgRs9s4aT0uLH3JR+/4gh nIIlWp/MmB3DFdEeaoYGcb+ivYe24Sag83VVu/JpboGZjk5fuYDmtqQ3ymy/MZMvtbzA hq3g== X-Received: by 10.194.2.132 with SMTP id 4mr30720137wju.49.1406380950875; Sat, 26 Jul 2014 06:22:30 -0700 (PDT) Received: from brick.home (cmu49.neoplus.adsl.tpnet.pl. [83.31.148.49]) by mx.google.com with ESMTPSA id wd7sm33644582wjc.36.2014.07.26.06.22.29 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 26 Jul 2014 06:22:30 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Sat, 26 Jul 2014 15:22:27 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Cy Schubert Subject: Re: FreeBSD Quarterly Status Report - Second Quarter 2014 Message-ID: <20140726132227.GA6812@brick.home> Mail-Followup-To: Cy Schubert , Glen Barber , freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org References: <20140725211249.GA3933@brick.home> <201407260246.s6Q2kX7n013280@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201407260246.s6Q2kX7n013280@slippy.cwsent.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Glen Barber , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 13:22:34 -0000 On 0725T1946, Cy Schubert wrote: > In message <20140725211249.GA3933@brick.home>, Edward Tomasz > =?utf-8?Q?Napiera= > C5=82a?= writes: > > On 0725T1019, Cy Schubert wrote: > > > In message <20140724183353.GL1065@hub.FreeBSD.org>, Glen Barber writes: > > > > New Automounter > > > > > > > > Contact: Edward Tomasz Napieral/a > > > > > > > > Deficiencies in the current automounter, amd(8), are a recurring > > > > problem reported by many FreeBSD users. A new automounter is being > > > > developed to address these concerns. > > > > > > > > The automounter is a cleanroom implementation of functionality > > > > available in most other Unix systems, using proper kernel support > > > > implemented via an autofs filesystem. The automounter supports a > > > > standard map format, and will integrate with the Lightweight Directory > > > > Access Protocol (LDAP) service. > > > > > > Will it also integrate with NIS (as SunOS and Solaris do)? FreeBSD's amd > > > currently integrates with NIS as well. > > > > It's just a matter of testing, apart from a trivial shell script. > > Would you be able to help me with this? > > > > > Sure! Just point me in the direction of the patches. So, the autofs branch is here: https://github.com/trasz/autofs. Directory services integration is done by external executable, which is usually a shell script. There is an LDAP example, at etc/autofs/include_ldap. Script to integrate with other services (which would be include_nis or include_hesiod) needs to do the same - retrieve the map named at the command line and output it to stdout, in a proper format. From owner-freebsd-stable@FreeBSD.ORG Sat Jul 26 18:45:50 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DFB6AC49; Sat, 26 Jul 2014 18:45:50 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id 8702B256B; Sat, 26 Jul 2014 18:45:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id 2CC4738091; Sat, 26 Jul 2014 13:39:49 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id t1OloxZAZnDP; Sat, 26 Jul 2014 13:39:49 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id 9252538090; Sat, 26 Jul 2014 13:39:48 -0500 (CDT) Message-ID: <53D3F5F2.7090403@freebsd.org> Date: Sat, 26 Jul 2014 11:39:46 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Hay , Baptiste Daroussin Subject: Re: [ANNOUNCEMENT] pkg 1.3.0 out! References: <20140723144249.GD69907@ivaldir.etoilebsd.net> <20140725065641.GA88239@zibbi.meraka.csir.co.za> In-Reply-To: <20140725065641.GA88239@zibbi.meraka.csir.co.za> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, stable@freebsd.org, current@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 18:45:51 -0000 On 07/24/14 23:56, John Hay wrote: > On Wed, Jul 23, 2014 at 04:42:51PM +0200, Baptiste Daroussin wrote: >> Hi all, >> >> I'm very please to announce the release of pkg 1.3.0 >> This version is the result of almost 9 month of hard work >> > ... >> Thank you to all contributors: >> Alberto Villa, Alexandre Perrin, Andrej Zverev, Antoine Brodin, Brad Davis, >> Bryan Drewery, Dag-Erling Sm?rgrav, Dmitry Marakasov, Elvira Khabirova, Jamie >> Landeg Jones, Jilles Tjoelker, John Marino, Julien Laffaye, Mathieu Arnold, >> Matthew Seaman, Maximilian Ga?, Michael Gehring, Michael Gmelin, Nicolas Szalay, >> Rodrigo Osorio, Roman Naumann, Rui Paulo, Sean Channel, Stanislav E. Putrya, >> Vsevolod Stakhov, Xin Li, coctic >> >> Regards, >> Bapt on behalf of the pkg@ > Version 1.3 does better on armeb. It does not crash while installing > itself, but still complains and get the architecture wrong: > > [snip] Would it make sense to get the architecture from the kernel, with a manual override for cross-installs? It seems like that would prevent cases like this permanently. -Nathan From owner-freebsd-stable@FreeBSD.ORG Sat Jul 26 19:19:04 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 500AA851; Sat, 26 Jul 2014 19:19:04 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id E48642875; Sat, 26 Jul 2014 19:19:03 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id EED5FB843; Sat, 26 Jul 2014 21:19:00 +0200 (SAST) Date: Sat, 26 Jul 2014 21:19:00 +0200 From: John Hay To: Nathan Whitehorn Subject: Re: [ANNOUNCEMENT] pkg 1.3.0 out! Message-ID: <20140726191900.GA85979@zibbi.meraka.csir.co.za> References: <20140723144249.GD69907@ivaldir.etoilebsd.net> <20140725065641.GA88239@zibbi.meraka.csir.co.za> <53D3F5F2.7090403@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53D3F5F2.7090403@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ports@freebsd.org, Baptiste Daroussin , stable@freebsd.org, current@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 19:19:04 -0000 On Sat, Jul 26, 2014 at 11:39:46AM -0700, Nathan Whitehorn wrote: > On 07/24/14 23:56, John Hay wrote: > > On Wed, Jul 23, 2014 at 04:42:51PM +0200, Baptiste Daroussin wrote: > >> Hi all, > >> > >> I'm very please to announce the release of pkg 1.3.0 > >> This version is the result of almost 9 month of hard work > >> > > ... > >> Thank you to all contributors: > >> Alberto Villa, Alexandre Perrin, Andrej Zverev, Antoine Brodin, Brad Davis, > >> Bryan Drewery, Dag-Erling Sm?rgrav, Dmitry Marakasov, Elvira Khabirova, Jamie > >> Landeg Jones, Jilles Tjoelker, John Marino, Julien Laffaye, Mathieu Arnold, > >> Matthew Seaman, Maximilian Ga?, Michael Gehring, Michael Gmelin, Nicolas Szalay, > >> Rodrigo Osorio, Roman Naumann, Rui Paulo, Sean Channel, Stanislav E. Putrya, > >> Vsevolod Stakhov, Xin Li, coctic > >> > >> Regards, > >> Bapt on behalf of the pkg@ > > Version 1.3 does better on armeb. It does not crash while installing > > itself, but still complains and get the architecture wrong: > > > > > [snip] > > Would it make sense to get the architecture from the kernel, with a > manual override for cross-installs? It seems like that would prevent > cases like this permanently. If a file has to be checked, what about the same mechanism that file (libmagic) use? It seems to get it right: root@cambria-build # file /bin/sh /bin/sh: ELF 32-bit MSB executable, ARM, EABI4 version 1 (SYSV), dynamically linked (uses shared libs), FreeBSD-style, for FreeBSD 11.0 (1100028), stripped John -- John Hay -- jhay@meraka.csir.co.za / jhay@meraka.org.za From owner-freebsd-stable@FreeBSD.ORG Sat Jul 26 19:40:18 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 594C336A; Sat, 26 Jul 2014 19:40:18 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7274C2A82; Sat, 26 Jul 2014 19:40:17 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id ho1so2528820wib.10 for ; Sat, 26 Jul 2014 12:40:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=aDNauzxtFJfrdZNfJUuTSeKxdBBowdUzkLJQRVAPb1s=; b=Xi3LJ7612mrzu3ytepL8aSxCj01wCaqDjjAdf41vwjtsAzPaFx+1llpwfwoSDW80Ap d3FoHT2JPFgZiphdLi8KhqWSXHOCEWDoXA0L3BflZsWj74+dXwMMSgsWihf/9L3l9Smk zJePN0GRBdaB3+KxXIXMmWnAzSN4H9Y0/WNtSSfJEeznFrYbOLYxOlQUJXlkPJNpEQuo nJbDN8keHDDJuintMoD7tOVZYxIzdJq6hVDEvq+hPgSnljfUmi3gkPaV6Da8EgQzrGoU xyf1hNZ6bJZaqgBhBf4lOPwqvJ+IpRy6mZqZiomH4Vg/WIgZ83kdKJ+J0EVIL8EkvGGf yAgQ== X-Received: by 10.194.219.225 with SMTP id pr1mr33664817wjc.34.1406403615658; Sat, 26 Jul 2014 12:40:15 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id fr4sm10658483wic.16.2014.07.26.12.40.13 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 26 Jul 2014 12:40:14 -0700 (PDT) Sender: Baptiste Daroussin Date: Sat, 26 Jul 2014 21:40:11 +0200 From: Baptiste Daroussin To: Nathan Whitehorn Subject: Re: [ANNOUNCEMENT] pkg 1.3.0 out! Message-ID: <20140726194011.GB50802@ivaldir.etoilebsd.net> References: <20140723144249.GD69907@ivaldir.etoilebsd.net> <20140725065641.GA88239@zibbi.meraka.csir.co.za> <53D3F5F2.7090403@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i0/AhcQY5QxfSsSZ" Content-Disposition: inline In-Reply-To: <53D3F5F2.7090403@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: ports@freebsd.org, stable@freebsd.org, current@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 19:40:18 -0000 --i0/AhcQY5QxfSsSZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 26, 2014 at 11:39:46AM -0700, Nathan Whitehorn wrote: > On 07/24/14 23:56, John Hay wrote: > > On Wed, Jul 23, 2014 at 04:42:51PM +0200, Baptiste Daroussin wrote: > >> Hi all, > >> > >> I'm very please to announce the release of pkg 1.3.0 > >> This version is the result of almost 9 month of hard work > >> > > ... > >> Thank you to all contributors: > >> Alberto Villa, Alexandre Perrin, Andrej Zverev, Antoine Brodin, Brad D= avis, > >> Bryan Drewery, Dag-Erling Sm?rgrav, Dmitry Marakasov, Elvira Khabirova= , Jamie > >> Landeg Jones, Jilles Tjoelker, John Marino, Julien Laffaye, Mathieu Ar= nold, > >> Matthew Seaman, Maximilian Ga?, Michael Gehring, Michael Gmelin, Nicol= as Szalay, > >> Rodrigo Osorio, Roman Naumann, Rui Paulo, Sean Channel, Stanislav E. P= utrya, > >> Vsevolod Stakhov, Xin Li, coctic > >> > >> Regards, > >> Bapt on behalf of the pkg@ > > Version 1.3 does better on armeb. It does not crash while installing > > itself, but still complains and get the architecture wrong: > > > > > [snip] >=20 > Would it make sense to get the architecture from the kernel, with a=20 > manual override for cross-installs? It seems like that would prevent=20 > cases like this permanently. > -Nathan THis will be completely rework including the patch you already sent me for = pkg 1.4.0. regards, Bapt --i0/AhcQY5QxfSsSZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlPUBBsACgkQ8kTtMUmk6ExOEQCcDZhSiyS/lasjgb9WecyZnzXO zHEAn2LImuQLrs6GKxPu2HyKhdcNmDtP =nQ3m -----END PGP SIGNATURE----- --i0/AhcQY5QxfSsSZ-- From owner-freebsd-stable@FreeBSD.ORG Sat Jul 26 19:53:03 2014 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79CBDA22; Sat, 26 Jul 2014 19:53:03 +0000 (UTC) Received: from i3mail.icecube.wisc.edu (i3mail.icecube.wisc.edu [128.104.255.23]) by mx1.freebsd.org (Postfix) with ESMTP id BFE1B2C22; Sat, 26 Jul 2014 19:53:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by i3mail.icecube.wisc.edu (Postfix) with ESMTP id 03C3F38091; Sat, 26 Jul 2014 14:53:02 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from i3mail.icecube.wisc.edu ([127.0.0.1]) by localhost (i3mail.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id N_6-j6VzmHBp; Sat, 26 Jul 2014 14:53:01 -0500 (CDT) Received: from comporellon.tachypleus.net (polaris.tachypleus.net [75.101.50.44]) by i3mail.icecube.wisc.edu (Postfix) with ESMTPSA id 6747738090; Sat, 26 Jul 2014 14:53:01 -0500 (CDT) Message-ID: <53D4071C.60607@freebsd.org> Date: Sat, 26 Jul 2014 12:53:00 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Baptiste Daroussin Subject: Re: [ANNOUNCEMENT] pkg 1.3.0 out! References: <20140723144249.GD69907@ivaldir.etoilebsd.net> <20140725065641.GA88239@zibbi.meraka.csir.co.za> <53D3F5F2.7090403@freebsd.org> <20140726194011.GB50802@ivaldir.etoilebsd.net> In-Reply-To: <20140726194011.GB50802@ivaldir.etoilebsd.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ports@freebsd.org, stable@freebsd.org, current@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 19:53:03 -0000 On 07/26/14 12:40, Baptiste Daroussin wrote: > On Sat, Jul 26, 2014 at 11:39:46AM -0700, Nathan Whitehorn wrote: >> On 07/24/14 23:56, John Hay wrote: >>> On Wed, Jul 23, 2014 at 04:42:51PM +0200, Baptiste Daroussin wrote: >>>> Hi all, >>>> >>>> I'm very please to announce the release of pkg 1.3.0 >>>> This version is the result of almost 9 month of hard work >>>> >>> ... >>>> Thank you to all contributors: >>>> Alberto Villa, Alexandre Perrin, Andrej Zverev, Antoine Brodin, Brad Davis, >>>> Bryan Drewery, Dag-Erling Sm?rgrav, Dmitry Marakasov, Elvira Khabirova, Jamie >>>> Landeg Jones, Jilles Tjoelker, John Marino, Julien Laffaye, Mathieu Arnold, >>>> Matthew Seaman, Maximilian Ga?, Michael Gehring, Michael Gmelin, Nicolas Szalay, >>>> Rodrigo Osorio, Roman Naumann, Rui Paulo, Sean Channel, Stanislav E. Putrya, >>>> Vsevolod Stakhov, Xin Li, coctic >>>> >>>> Regards, >>>> Bapt on behalf of the pkg@ >>> Version 1.3 does better on armeb. It does not crash while installing >>> itself, but still complains and get the architecture wrong: >>> >>> >> [snip] >> >> Would it make sense to get the architecture from the kernel, with a >> manual override for cross-installs? It seems like that would prevent >> cases like this permanently. >> -Nathan > THis will be completely rework including the patch you already sent me for pkg > 1.4.0. > > regards, > Bapt Oh sure. I'm not suggesting this be done now, or even close to now. Adding in another case for armeb to the existing ELF logic is a far easier solution that fixes the immediate issue. Just musing about longer term. -Nathan From owner-freebsd-stable@FreeBSD.ORG Sat Jul 26 21:54:13 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EECCAA1F for ; Sat, 26 Jul 2014 21:54:13 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id B42F1255A for ; Sat, 26 Jul 2014 21:54:13 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAA8j1FODaFve/2dsb2JhbABRCIQ7gnTNF4MXAYEgd4QDAQEEASNWBRYOCgICDRkCWQaITQimI5ZpF4EsjUoiNAeCeYFRBZcqkBSIWoNlIYF0 X-IronPort-AV: E=Sophos;i="5.01,737,1400040000"; d="scan'208";a="144633780" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 26 Jul 2014 17:54:02 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 678A9B4062; Sat, 26 Jul 2014 17:54:02 -0400 (EDT) Date: Sat, 26 Jul 2014 17:54:02 -0400 (EDT) From: Rick Macklem To: Harald Schmalzbauer Message-ID: <1626176481.3920822.1406411642415.JavaMail.root@uoguelph.ca> In-Reply-To: <53D37D08.2000104@omnilan.de> Subject: Re: nfsd server cache flooded, try to increase nfsrc_floodlevel MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 21:54:14 -0000 Harald Schmalzbauer wrote: > Bez=C3=BCglich Rick Macklem's Nachricht vom 25.07.2014 13:14 (localtime): > > Harald Schmalzbauer wrote: > >> Bez=C3=BCglich Rick Macklem's Nachricht vom 25.07.2014 02:14 > >> (localtime): > >>> Harald Schmalzbauer wrote: > >>>> Bez=C3=BCglich Rick Macklem's Nachricht vom 08.08.2013 14:20 > >>>> (localtime): > >>>>> Lars Eggert wrote: > >>>>>> Hi, > >>>>>> > >>>>>> every few days or so, my -STABLE NFS server (v3 and v4) gets > >>>>>> wedged > >>>>>> with a ton of messages about "nfsd server cache flooded, try > >>>>>> to > >>>>>> increase nfsrc_floodlevel" in the log, and nfsstat shows > >>>>>> TCPPeak > >>>>>> at > >>>>>> 16385. It requires a reboot to unwedge, restarting the server > >>>>>> does > >>>>>> not help. > >>>>>> > >>>>>> =E2=80=A6 > >> IMHO such a setup shouldn't require manual tuning and I consider > >> this > >> as > >> a really urgent problem! > >> Whatever causes the server to lock up is strongly required to be > >> fixed > >> for next release, > >> otherwise the shipped implementation of NFS is not really suitable > >> for > >> production environment and needs a warning message when enabled. > >> The impact of this failure forces admins to change the operation > >> system > >> in order to get a core service back into operation. > >> The importance is, that I don't suffer from weaker performance or > >> lags/delays, but my server stops NFS completely and only a reboot > >> solves > >> this situation. > >> > > Btw, you can increase vfs.nfsd.tcphighwater on the fly when it > > wedges > > and avoid having to reboot. > One suggestion: If raising vfs.nfsd.tcphighwater at runtime solves > the > locked nfsserver (which I thought I have tried, but I'm not sure any > more), maybe the log message should reflect that. My first guess was > to > look for a systcl named 'nfsrc_floodlevel'. If the log message makes > more sense to contain nfsrc_floodlevel instead of tcphighwater, the > latter should be metioned in the man page anyway. >=20 Yes, I'll admit I had intended to do that, but it slipped through the cracks. I will also try and make sure that bumping it up will allow the server to get working again without a reboot. > If the problem is solvable without rebooting, it's a cosmetic problem > IMHO, not that serious show stopper I considered at first. > Evereything > but a reboot is fine ;-) >=20 I would like to come up with a way to tune this based on server size (RAM + 32 vs 64bit arch or similar), but it may take a while to gather enough knowledge to do so. rick > Thanks, >=20 > -Harry >=20 >=20 >=20 >=20 >=20