From owner-freebsd-current@freebsd.org Sun Nov 20 02:19:47 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1605CC3E6EE for ; Sun, 20 Nov 2016 02:19:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-30.reflexion.net [208.70.210.30]) (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 C10ADF0C for ; Sun, 20 Nov 2016 02:19:46 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5508 invoked from network); 20 Nov 2016 02:19:24 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 20 Nov 2016 02:19:24 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Sat, 19 Nov 2016 21:19:24 -0500 (EST) Received: (qmail 13650 invoked from network); 20 Nov 2016 02:19:24 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 Nov 2016 02:19:24 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 4E2FCEC8FDE; Sat, 19 Nov 2016 18:19:38 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: svn commit: r308817 - head/sys/powerpc/include [Still have pmap_t and struct pmap ppowerpc64 problems as of -r308860] Message-Id: <39962D4C-29BA-4AA4-B77D-2344A68FDB54@dsl-only.net> Date: Sat, 19 Nov 2016 18:19:37 -0800 To: Justin Hibbits , svn-src-head@freebsd.org, FreeBSD Current X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 02:19:47 -0000 > Author: jhibbits > Date: Fri Nov 18 22:59:33 2016 > New Revision: 308817 > URL: https://svnweb.freebsd.org/changeset/base/308817 >=20 > Log: > Fix buildworld > =20 > Change the pv_tracked flag to an int, just in case userspace decides = to include > this file and defines BOOKE. > =20 > Guard this block from unintentional inclusion with ifdef BOOKE. > =20 > Reported by: emaste . . . (Later quotes are not from the list or from E-mail but from files.) I'm not targeting BOOKE but GENERIC64 (via include, with AIM but not ps3). I'm at head -r308860 yet for TARGET_ARCH=3Dpowerpc64 I get the following that did not happen with my older -r308247 builds: > --- kinfo_getallproc.o --- . . . > In file included from /usr/src/sys/sys/user.h:53:0, > from q:34: > /usr/src/sys/vm/vm_map.h:190:2: error: unknown type name 'pmap_t' > pmap_t pmap; /* (c) Physical map */ > ^ > /usr/src/sys/vm/vm_map.h:250:14: error: field 'vm_pmap' has incomplete = type > struct pmap vm_pmap; /* private physical map */ > ^ > --- kinfo_getfile.o --- > In file included from /usr/src/sys/sys/user.h:53:0, > from /usr/src/lib/libutil/kinfo_getfile.c:5: > /usr/src/sys/vm/vm_map.h:190:2: error: unknown type name 'pmap_t' > pmap_t pmap; /* (c) Physical map */ > ^ > /usr/src/sys/vm/vm_map.h:250:14: error: field 'vm_pmap' has incomplete = type > struct pmap vm_pmap; /* private physical map */ It is almost like a machine/pmap.h include is missing now so that the types are not defined. But I've not yet found where the relevant difference(s) are from -r308247. Showing a compile command (with -v) with its failure. . . > --- kinfo_getallproc.o --- > Using built-in specs. > COLLECT_GCC=3D/usr/local/bin/powerpc64-portbld-freebsd12.0-gcc > Target: powerpc64-portbld-freebsd12.0 > Configured with: = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-5.3.0/configure = --target=3Dpowerpc64-portbld-freebsd12.0 --disable-nls = --enable-languages=3Dc,c++ --without-headers --with-gmp=3D/usr/local = --with-pkgversion=3D'FreeBSD Ports Collection for powerpc64' = --with-system-zlib --with-as=3D/usr/local/bin/powerpc64-freebsd-as = --with-ld=3D/usr/local/bin/powerpc64-freebsd-ld --prefix=3D/usr/local = --localstatedir=3D/var --mandir=3D/usr/local/man = --infodir=3D/usr/local/info/ --build=3Dx86_64-portbld-freebsd12.0 > Thread model: posix > gcc version 5.3.0 (FreeBSD Ports Collection for powerpc64)=20 > COLLECT_GCC_OPTIONS=3D'-isystem' = '/usr/obj/powerpc64vtsc_xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/inclu= de' = '-L/usr/obj/powerpc64vtsc_xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib= ' '-B' = '/usr/obj/powerpc64vtsc_xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib' = '-B' '/usr/local/powerpc64-freebsd/bin/' '-O2' '-pipe' '-D' 'LIBC_SCCS' = '-D' 'INET6' '-I' '/usr/src/lib/libutil' '-I' = '/usr/src/lib/libutil/../libc/gen/' '-std=3Dgnu99' = '-fstack-protector-strong' '-Wsystem-headers' '-Wall' '-Wno-format-y2k' = '-Wextra' '-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' = '-Wno-pointer-sign' '-Wno-error=3Daddress' '-Wno-error=3Darray-bounds' = '-Wno-error=3Dattributes' '-Wno-error=3Dbool-compare' = '-Wno-error=3Dcast-align' '-Wno-error=3Dclobbered' = '-Wno-error=3Denum-compare' '-Wno-error=3Dextra' '-Wno-error=3Dinline' = '-Wno-error=3Dlogical-not-parentheses' '-Wno-error=3Dstrict-aliasing' = '-Wno-error=3Duninitialized' '-Wno-error=3Dunused-but-set-variable' = '-Wno-error=3Dunused-function' '-Wno-error=3Dunused-value' = '-Wno-error=3Dstrict-overflow' '-v' '-c' '-o' 'kinfo_getallproc.o' > /usr/local/libexec/gcc/powerpc64-portbld-freebsd12.0/5.3.0/cc1 -quiet = -v -I /usr/src/lib/libutil -I /usr/src/lib/libutil/../libc/gen/ = -isysroot = /usr/obj/powerpc64vtsc_xtoolchain/powerpc.powerpc64/usr/src/tmp -D = LIBC_SCCS -D INET6 -isystem = /usr/obj/powerpc64vtsc_xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/includ= e /usr/src/lib/libutil/kinfo_getallproc.c -quiet -dumpbase = kinfo_getallproc.c -auxbase-strip kinfo_getallproc.o -O2 = -Wsystem-headers -Wall -Wno-format-y2k -Wextra -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 -Wno-pointer-sign -Wno-error=3Daddress = -Wno-error=3Darray-bounds -Wno-error=3Dattributes = -Wno-error=3Dbool-compare -Wno-error=3Dcast-align -Wno-error=3Dclobbered = -Wno-error=3Denum-compare -Wno-error=3Dextra -Wno-error=3Dinline = -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dstrict-aliasing = -Wno-error=3Duninitialized -Wno-error=3Dunused-but-set-variable = -Wno-error=3Dunused-function -Wno-error=3Dunused-value = -Wno-error=3Dstrict-overflow -std=3Dgnu99 -version = -fstack-protector-strong -o - | > /usr/local/bin/powerpc64-freebsd-as -v -I /usr/src/lib/libutil -I = /usr/src/lib/libutil/../libc/gen/ --traditional-format -a64 -mppc64 = -many -o kinfo_getallproc.o > GNU C99 (FreeBSD Ports Collection for powerpc64) version 5.3.0 = (powerpc64-portbld-freebsd12.0) > compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 3.8.0 = (tags/RELEASE_380/final 262564), GMP version 5.1.3, MPFR version 3.1.5, = MPC version 1.0.3 > GGC heuristics: --param ggc-min-expand=3D100 --param = ggc-min-heapsize=3D131072 > ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd12.0/5.3.0/../../../../powerp= c64-portbld-freebsd12.0/sys-include" > ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd12.0/5.3.0/../../../../powerp= c64-portbld-freebsd12.0/include" > #include "..." search starts here: > #include <...> search starts here: > /usr/src/lib/libutil > /usr/src/lib/libutil/../libc/gen/ > = /usr/obj/powerpc64vtsc_xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/includ= e > /usr/local/lib/gcc/powerpc64-portbld-freebsd12.0/5.3.0/include > /usr/local/lib/gcc/powerpc64-portbld-freebsd12.0/5.3.0/include-fixed > End of search list. > GNU C99 (FreeBSD Ports Collection for powerpc64) version 5.3.0 = (powerpc64-portbld-freebsd12.0) > compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 3.8.0 = (tags/RELEASE_380/final 262564), GMP version 5.1.3, MPFR version 3.1.5, = MPC version 1.0.3 > GGC heuristics: --param ggc-min-expand=3D100 --param = ggc-min-heapsize=3D131072 > GNU assembler version 2.25.1 (powerpc64-freebsd) using BFD version = (GNU Binutils) 2.25.1 > Compiler executable checksum: f075193fe6b42ec6fb8ba336147ebe8e > In file included from /usr/src/sys/sys/user.h:53:0, > from /usr/src/lib/libutil/kinfo_getallproc.c:34: > /usr/src/sys/vm/vm_map.h:190:2: error: unknown type name 'pmap_t' > pmap_t pmap; /* (c) Physical map */ > ^ > /usr/src/sys/vm/vm_map.h:250:14: error: field 'vm_pmap' has incomplete = type > struct pmap vm_pmap; /* private physical map */ > ^ This is a powerpc64-xtoolchain-gcc based cross build: (I build with libc++ capable materials, not with gcc 4.2.1 .) > # uname -apKU > FreeBSD FreeBSDx64 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r308860M: Sat = Nov 19 14:00:24 PST 2016 = markmi@FreeBSDx64:/usr/obj/amd64_clang/amd64_amd64/usr/src/sys/GENERIC-NOD= BG amd64 amd64 1200014 1200014 > # svnlite info /usr/src/ | grep "Re[lpv]" > Relative URL: ^/head > Repository Root: svn://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 308860 > Last Changed Rev: 308860 > # more /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG=20 > # > # GENERIC -- Custom configuration for the powerpc/powerpc64 > # >=20 > include "GENERIC64" >=20 > ident GENERIC64vtsc-NODGB >=20 > makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols >=20 > nooptions PS3 # Sony Playstation 3 = HACK!!! to allow sc >=20 > options KDB # Enable kernel debugger = support >=20 > # For minimum debugger support (stable branch) use: > options KDB_TRACE # Print a stack trace for a = panic > options DDB # Enable the kernel debugger > options GDB # HACK!!! ... >=20 > # Extra stuff: > #options VERBOSE_SYSINIT # Enable verbose sysinit = messages > #options BOOTVERBOSE=3D1 > #options BOOTHOWTO=3DRB_VERBOSE > #options KTR > #options KTR_MASK=3DKTR_TRAP > ##options KTR_CPUMASK=3D0xF > #options KTR_VERBOSE >=20 > # HACK!!! to allow sc for 2560x1440 display on Radeon X1950 that vt = historically mishandled during booting > device sc > #device kbdmux # HACK: already listed by vt > options SC_OFWFB # OFW frame buffer > options SC_DFLT_FONT # compile font in > makeoptions SC_DFLT_FONT=3Dcp437 >=20 >=20 > # Disable any extra checking for. . . > nooptions DEADLKRES # Enable the deadlock resolver > nooptions INVARIANTS # Enable calls of extra sanity = checking > nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS > nooptions WITNESS # Enable checks to detect = deadlocks and cycles > nooptions WITNESS_SKIPSPIN # Don't run witness on = spinlocks for speed > nooptions DIAGNOSTIC > nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones Its SRC_ENV_CONF binding is to. . . > # more ~/src.configs/src.conf.powerpc64-xtoolchain.amd64-host=20 > TO_TYPE=3Dpowerpc64 > TOOLS_TO_TYPE=3D${TO_TYPE} > VERSION_CONTEXT=3D12.0 > # > KERNCONF=3DGENERIC64vtsc-NODBG > TARGET=3Dpowerpc > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > WITHOUT_CROSS_COMPILER=3D > WITHOUT_SYSTEM_COMPILER=3D > # > WITH_LIBCPLUSPLUS=3D > WITHOUT_BINUTILS_BOOTSTRAP=3D > WITHOUT_CLANG_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_CLANG_EXTRAS=3D > WITH_LLDB=3D > # > WITH_BOOT=3D > # powerpc64 LIB32 builds via gcc 4.9 or later variants that I've tried > # but the LIB32 does not work [crtbeginS code problem(s)] > WITHOUT_LIB32=3D > # > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GCC_IS_CC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > #WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_DEBUG_FILES=3D > # > # > # For TO (so-called "cross") stages . . . > # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . > # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . = . > # > CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc > X_COMPILER_TYPE=3Dgcc > CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ > .if ${.MAKE.LEVEL} =3D=3D 0 > = XCC=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-gc= c > = XCXX=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-g= ++ > = XCPP=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-c= pp > .export XCC > .export XCXX > .export XCPP > XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as > XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar > XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld > XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm > XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy > XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump > XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib > XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size > #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings > XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings > .export XAS > .export XAR > .export XLD > .export XNM > .export XOBJCOPY > .export XOBJDUMP > .export XRANLIB > .export XSIZE > .export XSTRINGS > .endif > # > # > # =46rom based on clang (via system). . . > # > .if ${.MAKE.LEVEL} =3D=3D 0 > CC=3D/usr/bin/clang > CXX=3D/usr/bin/clang++ > CPP=3D/usr/bin/clang-cpp > .export CC > .export CXX > .export CPP > .endif > # svnlite status /usr/src/ > M = /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp > M /usr/src/lib/csu/powerpc64/Makefile > ? /usr/src/sys/amd64/conf/GENERIC-DBG > ? /usr/src/sys/amd64/conf/GENERIC-NODBG > ? /usr/src/sys/arm/conf/BPIM3-DBG > ? /usr/src/sys/arm/conf/BPIM3-NODBG > ? /usr/src/sys/arm/conf/RPI2-DBG > ? /usr/src/sys/arm/conf/RPI2-NODBG > ? /usr/src/sys/arm64/conf/GENERIC-DBG > ? /usr/src/sys/arm64/conf/GENERIC-NODBG > M /usr/src/sys/boot/ofw/Makefile.inc > M /usr/src/sys/boot/powerpc/Makefile.inc > M /usr/src/sys/boot/powerpc/kboot/Makefile > M /usr/src/sys/boot/uboot/Makefile.inc > M /usr/src/sys/conf/Makefile.powerpc > M /usr/src/sys/conf/kern.mk > M /usr/src/sys/conf/kmod.mk > M /usr/src/sys/ddb/db_main.c > M /usr/src/sys/ddb/db_script.c > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG > ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG > ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG > M /usr/src/sys/powerpc/ofw/ofw_machdep.c > M /usr/src/sys/powerpc/powerpc/exec_machdep.c =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sun Nov 20 02:31:35 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DFCEDC3ECAA; Sun, 20 Nov 2016 02:31:35 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A753F1503; Sun, 20 Nov 2016 02:31:35 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-it0-x243.google.com with SMTP id o1so10931876ito.1; Sat, 19 Nov 2016 18:31:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=bPSzWVIOz5/ECAvHbD2+qWropcS5v1a5C8wdu8b9VKo=; b=TLV8ihadlyHeaz0f9drIpGbuY1w5I7J6I36yTLAWuJ269Ziikxgb9beu/HNZCnuxaB y5u3sIhtycgf6tPnjMahPVaRxgE9Tao90IllR5Qwrdj/HC9jHPzrH1ZO8y0/HKdB0A8a JldeoFcUza+XV+zsvzUk/oI9C2o54CBtsCjp03KjKOeBx7dVYLwPuBDIgPUe2252wgLQ p5+XldR3rhmC8h0xtvWfIKUga3bp8QDoSTu+Ue3+Xc6Gfp7evaFGVPPhfIeVFSeL02F9 eUw40QnOflyInhy39KkJCIW81+mNUKhV5fwl5LtWmzDNawjrMMBTROT3DqI4Ho7A9hyJ 8rRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :in-reply-to:references:mime-version:content-transfer-encoding; bh=bPSzWVIOz5/ECAvHbD2+qWropcS5v1a5C8wdu8b9VKo=; b=fXrputIOeH8SFcGrvrqJR7ZR3dxMlmkA/7A0GrU1qRjEreJ0WoXnef4DADf80v/BHx BhRBk8QyqrQc3rTCI+4tyHCK/NHTC2R8R0vZwR0I8wR/z88LEPx+NDQ8CS9sijc/5VMe uJyLl44NoZ41I8Eeu8om1wD4E5hIIfDsZzLIgbEB3Ne4zIWJ9imScIPn/I8U4Cbhmu7x tN98rbzUNOv37Sbs6sr8rn0CwvBb7HG6Q+W6hRky6rLiDmAYHrGwMFLZHDQb41SB5GYz ocvQ7qJ16FvlJIRtzGiTwhxswqnFgUUxbW/nE1gIsSzHdaUQOlfoB18t38Lfp+Rzu0a/ PEEw== X-Gm-Message-State: AKaTC00Noy3Mey7aEIF5SQYoX1n2D/y8aBuMok/dqVQfBkfzSy8neUmfqmIGRDTlPDqy7A== X-Received: by 10.36.233.66 with SMTP id f63mr4540874ith.55.1479609093580; Sat, 19 Nov 2016 18:31:33 -0800 (PST) Received: from zhabar.knownspace (50-80-150-234.client.mchsi.com. [50.80.150.234]) by smtp.gmail.com with ESMTPSA id k198sm3735523itb.18.2016.11.19.18.31.32 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 19 Nov 2016 18:31:33 -0800 (PST) Sender: Justin Hibbits Date: Sat, 19 Nov 2016 20:31:28 -0600 From: Justin Hibbits To: Mark Millard Cc: svn-src-head@freebsd.org, FreeBSD Current , Alan Cox Subject: Re: svn commit: r308817 - head/sys/powerpc/include [Still have pmap_t and struct pmap ppowerpc64 problems as of -r308860] Message-ID: <20161119203128.2ac46708@zhabar.knownspace> In-Reply-To: <39962D4C-29BA-4AA4-B77D-2344A68FDB54@dsl-only.net> References: <39962D4C-29BA-4AA4-B77D-2344A68FDB54@dsl-only.net> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.29; powerpc64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 02:31:36 -0000 On Sat, 19 Nov 2016 18:19:37 -0800 Mark Millard wrote: > > Author: jhibbits > > Date: Fri Nov 18 22:59:33 2016 > > New Revision: 308817 > > URL: https://svnweb.freebsd.org/changeset/base/308817 > > > > Log: > > Fix buildworld > > > > Change the pv_tracked flag to an int, just in case userspace > > decides to include this file and defines BOOKE. > > > > Guard this block from unintentional inclusion with ifdef BOOKE. > > > > Reported by: emaste > . . . > > (Later quotes are not from the list or from E-mail but from files.) > > I'm not targeting BOOKE but GENERIC64 (via include, with AIM but not > ps3). I'm at head -r308860 yet for TARGET_ARCH=powerpc64 I get the > following that did not happen with my older -r308247 builds: > > > --- kinfo_getallproc.o --- > . . . > > In file included from /usr/src/sys/sys/user.h:53:0, > > from q:34: > > /usr/src/sys/vm/vm_map.h:190:2: error: unknown type name 'pmap_t' > > pmap_t pmap; /* (c) Physical map */ > > ^ > > /usr/src/sys/vm/vm_map.h:250:14: error: field 'vm_pmap' has > > incomplete type struct pmap vm_pmap; /* private physical map */ > > ^ > > --- kinfo_getfile.o --- > > In file included from /usr/src/sys/sys/user.h:53:0, > > from /usr/src/lib/libutil/kinfo_getfile.c:5: > > /usr/src/sys/vm/vm_map.h:190:2: error: unknown type name 'pmap_t' > > pmap_t pmap; /* (c) Physical map */ > > ^ > > /usr/src/sys/vm/vm_map.h:250:14: error: field 'vm_pmap' has > > incomplete type struct pmap vm_pmap; /* private physical map */ > > > It is almost like a machine/pmap.h include is missing now so that the > types are not defined. But I've not yet found where the relevant > difference(s) are from -r308247. > > Showing a compile command (with -v) with its failure. . . > The change is the "#elif defined(BOOKE)". Since userspace doesn't define either AIM nor BOOKE, struct pmap no longer exists. Alan, do you know if vmspace *needs* struct pmap to exist when read from userspace (in libprocstat and libkvm, from what I grepped)? If not, I can add a simple '#else struct pmap {};' to quiet the build. - Justin From owner-freebsd-current@freebsd.org Sun Nov 20 02:36:43 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1B7E2C3EE1E for ; Sun, 20 Nov 2016 02:36:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-30.reflexion.net [208.70.210.30]) (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 D00041881 for ; Sun, 20 Nov 2016 02:36:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17435 invoked from network); 20 Nov 2016 02:36:26 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 20 Nov 2016 02:36:26 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Sat, 19 Nov 2016 21:36:47 -0500 (EST) Received: (qmail 26929 invoked from network); 20 Nov 2016 02:36:46 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 Nov 2016 02:36:46 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 0FE07EC8FDE; Sat, 19 Nov 2016 18:36:40 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: svn commit: r308817 - head/sys/powerpc/include [Still have pmap_t and struct pmap ppowerpc64 problems as of -r308860] Date: Sat, 19 Nov 2016 18:36:39 -0800 References: <39962D4C-29BA-4AA4-B77D-2344A68FDB54@dsl-only.net> To: Justin Hibbits , svn-src-head@freebsd.org, FreeBSD Current In-Reply-To: <39962D4C-29BA-4AA4-B77D-2344A68FDB54@dsl-only.net> Message-Id: <53258F35-C86E-4DE0-BDF0-5C139E68356D@dsl-only.net> X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 02:36:43 -0000 [Quick top post I'm afraid.] I think that I figured out why there is a problem even earlier --that just did not stop the compiles. lib/libutil/kinfo_getallproc.c is built here as part of buildworld (stage 4.2 "building libraries" instead of buildkernel. It does not have the KERNCONF's AIM vs. BOOKE vs. . . . definitions vs. lack of them). So if it includes machine/pmap.h that binds to sys/powerpc/include/pmap.h which has the structure. . . . . . #if defined(AIM) . . . (definitions here) #elif defined(BOOKE) . . . (definitions here) #endif . . . it gets no definition now. With the older: . . . #if defined(AIM) . . . (definitions here) #else . . . (definitions here) #endif . . . It got a definition, just not necessarily the right one. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Nov-19, at 6:19 PM, Mark Millard wrote: > Author: jhibbits > Date: Fri Nov 18 22:59:33 2016 > New Revision: 308817 > URL: https://svnweb.freebsd.org/changeset/base/308817 >=20 > Log: > Fix buildworld >=20 > Change the pv_tracked flag to an int, just in case userspace decides = to include > this file and defines BOOKE. >=20 > Guard this block from unintentional inclusion with ifdef BOOKE. >=20 > Reported by: emaste . . . (Later quotes are not from the list or from E-mail but from files.) I'm not targeting BOOKE but GENERIC64 (via include, with AIM but not ps3). I'm at head -r308860 yet for TARGET_ARCH=3Dpowerpc64 I get the following that did not happen with my older -r308247 builds: > --- kinfo_getallproc.o --- . . . > In file included from /usr/src/sys/sys/user.h:53:0, > from q:34: > /usr/src/sys/vm/vm_map.h:190:2: error: unknown type name 'pmap_t' > pmap_t pmap; /* (c) Physical map */ > ^ > /usr/src/sys/vm/vm_map.h:250:14: error: field 'vm_pmap' has incomplete = type > struct pmap vm_pmap; /* private physical map */ > ^ > --- kinfo_getfile.o --- > In file included from /usr/src/sys/sys/user.h:53:0, > from /usr/src/lib/libutil/kinfo_getfile.c:5: > /usr/src/sys/vm/vm_map.h:190:2: error: unknown type name 'pmap_t' > pmap_t pmap; /* (c) Physical map */ > ^ > /usr/src/sys/vm/vm_map.h:250:14: error: field 'vm_pmap' has incomplete = type > struct pmap vm_pmap; /* private physical map */ It is almost like a machine/pmap.h include is missing now so that the types are not defined. But I've not yet found where the relevant difference(s) are from -r308247. Showing a compile command (with -v) with its failure. . . > --- kinfo_getallproc.o --- > Using built-in specs. > COLLECT_GCC=3D/usr/local/bin/powerpc64-portbld-freebsd12.0-gcc > Target: powerpc64-portbld-freebsd12.0 > Configured with: = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-5.3.0/configure = --target=3Dpowerpc64-portbld-freebsd12.0 --disable-nls = --enable-languages=3Dc,c++ --without-headers --with-gmp=3D/usr/local = --with-pkgversion=3D'FreeBSD Ports Collection for powerpc64' = --with-system-zlib --with-as=3D/usr/local/bin/powerpc64-freebsd-as = --with-ld=3D/usr/local/bin/powerpc64-freebsd-ld --prefix=3D/usr/local = --localstatedir=3D/var --mandir=3D/usr/local/man = --infodir=3D/usr/local/info/ --build=3Dx86_64-portbld-freebsd12.0 > Thread model: posix > gcc version 5.3.0 (FreeBSD Ports Collection for powerpc64)=20 > COLLECT_GCC_OPTIONS=3D'-isystem' = '/usr/obj/powerpc64vtsc_xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/inclu= de' = '-L/usr/obj/powerpc64vtsc_xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib= ' '-B' = '/usr/obj/powerpc64vtsc_xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib' = '-B' '/usr/local/powerpc64-freebsd/bin/' '-O2' '-pipe' '-D' 'LIBC_SCCS' = '-D' 'INET6' '-I' '/usr/src/lib/libutil' '-I' = '/usr/src/lib/libutil/../libc/gen/' '-std=3Dgnu99' = '-fstack-protector-strong' '-Wsystem-headers' '-Wall' '-Wno-format-y2k' = '-Wextra' '-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' = '-Wno-pointer-sign' '-Wno-error=3Daddress' '-Wno-error=3Darray-bounds' = '-Wno-error=3Dattributes' '-Wno-error=3Dbool-compare' = '-Wno-error=3Dcast-align' '-Wno-error=3Dclobbered' = '-Wno-error=3Denum-compare' '-Wno-error=3Dextra' '-Wno-error=3Dinline' = '-Wno-error=3Dlogical-not-parentheses' '-Wno-error=3Dstrict-aliasing' = '-Wno-error=3Duninitialized' '-Wno-error=3Dunused-but-set-variable' = '-Wno-error=3Dunused-function' '-Wno-error=3Dunused-value' = '-Wno-error=3Dstrict-overflow' '-v' '-c' '-o' 'kinfo_getallproc.o' > /usr/local/libexec/gcc/powerpc64-portbld-freebsd12.0/5.3.0/cc1 -quiet = -v -I /usr/src/lib/libutil -I /usr/src/lib/libutil/../libc/gen/ = -isysroot = /usr/obj/powerpc64vtsc_xtoolchain/powerpc.powerpc64/usr/src/tmp -D = LIBC_SCCS -D INET6 -isystem = /usr/obj/powerpc64vtsc_xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/includ= e /usr/src/lib/libutil/kinfo_getallproc.c -quiet -dumpbase = kinfo_getallproc.c -auxbase-strip kinfo_getallproc.o -O2 = -Wsystem-headers -Wall -Wno-format-y2k -Wextra -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 -Wno-pointer-sign -Wno-error=3Daddress = -Wno-error=3Darray-bounds -Wno-error=3Dattributes = -Wno-error=3Dbool-compare -Wno-error=3Dcast-align -Wno-error=3Dclobbered = -Wno-error=3Denum-compare -Wno-error=3Dextra -Wno-error=3Dinline = -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dstrict-aliasing = -Wno-error=3Duninitialized -Wno-error=3Dunused-but-set-variable = -Wno-error=3Dunused-function -Wno-error=3Dunused-value = -Wno-error=3Dstrict-overflow -std=3Dgnu99 -version = -fstack-protector-strong -o - | > /usr/local/bin/powerpc64-freebsd-as -v -I /usr/src/lib/libutil -I = /usr/src/lib/libutil/../libc/gen/ --traditional-format -a64 -mppc64 = -many -o kinfo_getallproc.o > GNU C99 (FreeBSD Ports Collection for powerpc64) version 5.3.0 = (powerpc64-portbld-freebsd12.0) > compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 3.8.0 = (tags/RELEASE_380/final 262564), GMP version 5.1.3, MPFR version 3.1.5, = MPC version 1.0.3 > GGC heuristics: --param ggc-min-expand=3D100 --param = ggc-min-heapsize=3D131072 > ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd12.0/5.3.0/../../../../powerp= c64-portbld-freebsd12.0/sys-include" > ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd12.0/5.3.0/../../../../powerp= c64-portbld-freebsd12.0/include" > #include "..." search starts here: > #include <...> search starts here: > /usr/src/lib/libutil > /usr/src/lib/libutil/../libc/gen/ > = /usr/obj/powerpc64vtsc_xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/includ= e > /usr/local/lib/gcc/powerpc64-portbld-freebsd12.0/5.3.0/include > /usr/local/lib/gcc/powerpc64-portbld-freebsd12.0/5.3.0/include-fixed > End of search list. > GNU C99 (FreeBSD Ports Collection for powerpc64) version 5.3.0 = (powerpc64-portbld-freebsd12.0) > compiled by GNU C version 4.2.1 Compatible FreeBSD Clang 3.8.0 = (tags/RELEASE_380/final 262564), GMP version 5.1.3, MPFR version 3.1.5, = MPC version 1.0.3 > GGC heuristics: --param ggc-min-expand=3D100 --param = ggc-min-heapsize=3D131072 > GNU assembler version 2.25.1 (powerpc64-freebsd) using BFD version = (GNU Binutils) 2.25.1 > Compiler executable checksum: f075193fe6b42ec6fb8ba336147ebe8e > In file included from /usr/src/sys/sys/user.h:53:0, > from /usr/src/lib/libutil/kinfo_getallproc.c:34: > /usr/src/sys/vm/vm_map.h:190:2: error: unknown type name 'pmap_t' > pmap_t pmap; /* (c) Physical map */ > ^ > /usr/src/sys/vm/vm_map.h:250:14: error: field 'vm_pmap' has incomplete = type > struct pmap vm_pmap; /* private physical map */ > ^ This is a powerpc64-xtoolchain-gcc based cross build: (I build with libc++ capable materials, not with gcc 4.2.1 .) > # uname -apKU > FreeBSD FreeBSDx64 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r308860M: Sat = Nov 19 14:00:24 PST 2016 = markmi@FreeBSDx64:/usr/obj/amd64_clang/amd64_amd64/usr/src/sys/GENERIC-NOD= BG amd64 amd64 1200014 1200014 > # svnlite info /usr/src/ | grep "Re[lpv]" > Relative URL: ^/head > Repository Root: svn://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 308860 > Last Changed Rev: 308860 > # more /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG=20 > # > # GENERIC -- Custom configuration for the powerpc/powerpc64 > # >=20 > include "GENERIC64" >=20 > ident GENERIC64vtsc-NODGB >=20 > makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols >=20 > nooptions PS3 # Sony Playstation 3 = HACK!!! to allow sc >=20 > options KDB # Enable kernel debugger = support >=20 > # For minimum debugger support (stable branch) use: > options KDB_TRACE # Print a stack trace for a = panic > options DDB # Enable the kernel debugger > options GDB # HACK!!! ... >=20 > # Extra stuff: > #options VERBOSE_SYSINIT # Enable verbose sysinit = messages > #options BOOTVERBOSE=3D1 > #options BOOTHOWTO=3DRB_VERBOSE > #options KTR > #options KTR_MASK=3DKTR_TRAP > ##options KTR_CPUMASK=3D0xF > #options KTR_VERBOSE >=20 > # HACK!!! to allow sc for 2560x1440 display on Radeon X1950 that vt = historically mishandled during booting > device sc > #device kbdmux # HACK: already listed by vt > options SC_OFWFB # OFW frame buffer > options SC_DFLT_FONT # compile font in > makeoptions SC_DFLT_FONT=3Dcp437 >=20 >=20 > # Disable any extra checking for. . . > nooptions DEADLKRES # Enable the deadlock resolver > nooptions INVARIANTS # Enable calls of extra sanity = checking > nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS > nooptions WITNESS # Enable checks to detect = deadlocks and cycles > nooptions WITNESS_SKIPSPIN # Don't run witness on = spinlocks for speed > nooptions DIAGNOSTIC > nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones Its SRC_ENV_CONF binding is to. . . > # more ~/src.configs/src.conf.powerpc64-xtoolchain.amd64-host=20 > TO_TYPE=3Dpowerpc64 > TOOLS_TO_TYPE=3D${TO_TYPE} > VERSION_CONTEXT=3D12.0 > # > KERNCONF=3DGENERIC64vtsc-NODBG > TARGET=3Dpowerpc > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > WITHOUT_CROSS_COMPILER=3D > WITHOUT_SYSTEM_COMPILER=3D > # > WITH_LIBCPLUSPLUS=3D > WITHOUT_BINUTILS_BOOTSTRAP=3D > WITHOUT_CLANG_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_CLANG_EXTRAS=3D > WITH_LLDB=3D > # > WITH_BOOT=3D > # powerpc64 LIB32 builds via gcc 4.9 or later variants that I've tried > # but the LIB32 does not work [crtbeginS code problem(s)] > WITHOUT_LIB32=3D > # > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GCC_IS_CC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > #WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_DEBUG_FILES=3D > # > # > # For TO (so-called "cross") stages . . . > # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . > # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . = . > # > CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc > X_COMPILER_TYPE=3Dgcc > CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ > .if ${.MAKE.LEVEL} =3D=3D 0 > = XCC=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-gc= c > = XCXX=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-g= ++ > = XCPP=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-c= pp > .export XCC > .export XCXX > .export XCPP > XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as > XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar > XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld > XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm > XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy > XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump > XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib > XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size > #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings > XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings > .export XAS > .export XAR > .export XLD > .export XNM > .export XOBJCOPY > .export XOBJDUMP > .export XRANLIB > .export XSIZE > .export XSTRINGS > .endif > # > # > # =46rom based on clang (via system). . . > # > .if ${.MAKE.LEVEL} =3D=3D 0 > CC=3D/usr/bin/clang > CXX=3D/usr/bin/clang++ > CPP=3D/usr/bin/clang-cpp > .export CC > .export CXX > .export CPP > .endif > # svnlite status /usr/src/ > M = /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp > M /usr/src/lib/csu/powerpc64/Makefile > ? /usr/src/sys/amd64/conf/GENERIC-DBG > ? /usr/src/sys/amd64/conf/GENERIC-NODBG > ? /usr/src/sys/arm/conf/BPIM3-DBG > ? /usr/src/sys/arm/conf/BPIM3-NODBG > ? /usr/src/sys/arm/conf/RPI2-DBG > ? /usr/src/sys/arm/conf/RPI2-NODBG > ? /usr/src/sys/arm64/conf/GENERIC-DBG > ? /usr/src/sys/arm64/conf/GENERIC-NODBG > M /usr/src/sys/boot/ofw/Makefile.inc > M /usr/src/sys/boot/powerpc/Makefile.inc > M /usr/src/sys/boot/powerpc/kboot/Makefile > M /usr/src/sys/boot/uboot/Makefile.inc > M /usr/src/sys/conf/Makefile.powerpc > M /usr/src/sys/conf/kern.mk > M /usr/src/sys/conf/kmod.mk > M /usr/src/sys/ddb/db_main.c > M /usr/src/sys/ddb/db_script.c > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG > ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG > ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG > M /usr/src/sys/powerpc/ofw/ofw_machdep.c > M /usr/src/sys/powerpc/powerpc/exec_machdep.c =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-current@freebsd.org Sun Nov 20 02:47:18 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A387FC47089; Sun, 20 Nov 2016 02:47:18 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5CDE41CB6; Sun, 20 Nov 2016 02:47:18 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-io0-x243.google.com with SMTP id h133so1684951ioe.2; Sat, 19 Nov 2016 18:47:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:in-reply-to:references :mime-version; bh=cXO3ZoG5MEw5PfglcflCRor4fmuxXlQ/rSS2UHDgsMk=; b=bk618bwvu+Wic9V+3WQG3IE+KPsvN/6Yox5Y3SdpOr5BeqFFCqkcVa3inROzDRvFlS HSKggdY+L1WJoVld7HC3j60O0rR3y6WegiaFulatgW/KXeCZJtJT5mqBhoki3MUmCTIt Y2as0nknSaMZ+ojIWM7cTlfKwKwLbTtvDNGexhDDLPKge+NHYygKdbQknTO/XM1VKSwi WxlnfNNOxz7FgOyyxSv9ZFDnxXBu/F4SWihHPW4GH9yMDa0cn0sw6Afbv5FtvSvFOIgV 5I4i2Ya2mf/7Rd/fWZdbonRCWaMxmDVbKuhgEJnGKNhrO0WQ+stEc55nSomYaw+p0W6+ 29/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :in-reply-to:references:mime-version; bh=cXO3ZoG5MEw5PfglcflCRor4fmuxXlQ/rSS2UHDgsMk=; b=R52nua8eUi464PQs7x3LVT8rMC+/9xLAdODuRSPghwjT33968PjMI66QpLnF1DkCuF KPoHvaetdrFFY7JpQZ+8v1oC0w2Z1qw3zBzH5z4IWvoNMe9saH0KeJO8ID8llWKGf0nB IzJw9dKk5UZi6B8Kd1AfQaUCpU2mOrXbVvjhihnoDtBikFllN6qOQebasmqPtCJBiD+7 /EfVGmt7v2WN7jGKoeOBu6uKr0ODSFymmagouwDCcaBUCk3tCrnER1XaUqHhtMrXmmD9 adKJq7++QrSidm3tVhKaurF/kOS1Mo8A7PRwrI5oWarDfscqHBZrApcn6MFeNcjyT/0f 9wFg== X-Gm-Message-State: AKaTC019ThBJw0tN8vMzq/0AEk1NdQKGTUV2QfJrk+LzPXjRPig1Q0Kg0QN3FYkvURqHZg== X-Received: by 10.107.167.5 with SMTP id q5mr5391258ioe.75.1479610037788; Sat, 19 Nov 2016 18:47:17 -0800 (PST) Received: from zhabar.knownspace (50-80-150-234.client.mchsi.com. [50.80.150.234]) by smtp.gmail.com with ESMTPSA id x74sm3377860ita.22.2016.11.19.18.47.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 19 Nov 2016 18:47:17 -0800 (PST) Sender: Justin Hibbits Date: Sat, 19 Nov 2016 20:47:15 -0600 From: Justin Hibbits To: Mark Millard Cc: svn-src-head@freebsd.org, FreeBSD Current Subject: Re: svn commit: r308817 - head/sys/powerpc/include [Still have pmap_t and struct pmap ppowerpc64 problems as of -r308860] Message-ID: <20161119204715.79632a66@zhabar.knownspace> In-Reply-To: <53258F35-C86E-4DE0-BDF0-5C139E68356D@dsl-only.net> References: <39962D4C-29BA-4AA4-B77D-2344A68FDB54@dsl-only.net> <53258F35-C86E-4DE0-BDF0-5C139E68356D@dsl-only.net> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.29; powerpc64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MP_/eYKnT8u=tt7OZI3sR.Gf6ts" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 02:47:18 -0000 --MP_/eYKnT8u=tt7OZI3sR.Gf6ts Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sat, 19 Nov 2016 18:36:39 -0800 Mark Millard wrote: > [Quick top post I'm afraid.] > > I think that I figured out why there is a problem even earlier > --that just did not stop the compiles. > > lib/libutil/kinfo_getallproc.c is built here as part of buildworld > (stage 4.2 "building libraries" instead of buildkernel. It does not > have the KERNCONF's AIM vs. BOOKE vs. . . . definitions vs. lack of > them). > > So if it includes machine/pmap.h that binds to > sys/powerpc/include/pmap.h which has the structure. . . > > . . . > #if defined(AIM) > . . . (definitions here) > #elif defined(BOOKE) > . . . (definitions here) > #endif > . . . > > it gets no definition now. > > With the older: > > . . . > #if defined(AIM) > . . . (definitions here) > #else > . . . (definitions here) > #endif > . . . > > It got a definition, just not necessarily the right one. > > > === > Mark Millard > markmi at dsl-only.net Can you try the attached patch? There was a subtle ABI issue that r308817 exposed, which is that the pmap structs aren't identical such that the pm_stats are at different locations, and libkvm ends up reading with the Book-E pmap, getting different stats than expected for AIM. This patch fixes that, bumping version to account for this ABI change. - Justin --MP_/eYKnT8u=tt7OZI3sR.Gf6ts Content-Type: text/x-patch Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=fix_pmap.diff Index: sys/sys/param.h =================================================================== --- sys/sys/param.h (revision 308708) +++ sys/sys/param.h (working copy) @@ -58,7 +58,7 @@ * in the range 5 to 9. */ #undef __FreeBSD_version -#define __FreeBSD_version 1200014 /* Master, propagated to newvers */ +#define __FreeBSD_version 1200015 /* Master, propagated to newvers */ /* * __FreeBSD_kernel__ indicates that this system uses the kernel of FreeBSD, Index: sys/powerpc/include/pmap.h =================================================================== --- sys/powerpc/include/pmap.h (revision 308718) +++ sys/powerpc/include/pmap.h (working copy) @@ -74,6 +74,9 @@ #include #include +struct pmap; +typedef struct pmap *pmap_t; + #if defined(AIM) #if !defined(NPMAPS) @@ -81,8 +84,6 @@ #endif /* !defined(NPMAPS) */ struct slbtnode; -struct pmap; -typedef struct pmap *pmap_t; struct pvo_entry { LIST_ENTRY(pvo_entry) pvo_vlink; /* Link to common virt page */ @@ -131,6 +132,7 @@ #define PVO_VSID(pvo) ((pvo)->pvo_vpn >> 16) struct pmap { + struct pmap_statistics pm_stats; struct mtx pm_mtx; #ifdef __powerpc64__ @@ -143,7 +145,6 @@ cpuset_t pm_active; struct pmap *pmap_phys; - struct pmap_statistics pm_stats; struct pvo_tree pmap_pvo; }; @@ -179,13 +180,13 @@ struct slb **slb_alloc_user_cache(void); void slb_free_user_cache(struct slb **); -#else +#elif defined(BOOKE) struct pmap { + struct pmap_statistics pm_stats; /* pmap statistics */ struct mtx pm_mtx; /* pmap mutex */ tlbtid_t pm_tid[MAXCPU]; /* TID to identify this pmap entries in TLB */ cpuset_t pm_active; /* active on cpus */ - struct pmap_statistics pm_stats; /* pmap statistics */ /* Page table directory, array of pointers to page tables. */ pte_t *pm_pdir[PDIR_NENTRIES]; @@ -193,7 +194,6 @@ /* List of allocated ptbl bufs (ptbl kva regions). */ TAILQ_HEAD(, ptbl_buf) pm_ptbl_list; }; -typedef struct pmap *pmap_t; struct pv_entry { pmap_t pv_pmap; @@ -210,6 +210,16 @@ #define pmap_page_get_memattr(m) VM_MEMATTR_DEFAULT #define pmap_page_is_mapped(m) (!TAILQ_EMPTY(&(m)->md.pv_list)) +#else +/* + * Common pmap members between AIM and BOOKE. + * libkvm needs pm_stats at the same location between both, as it doesn't define + * AIM nor BOOKE, and is expected to work across all. + */ +struct pmap { + struct pmap_statistics pm_stats; /* pmap statistics */ + struct mtx pm_mtx; /* pmap mutex */ +}; #endif /* AIM */ extern struct pmap kernel_pmap_store; Index: UPDATING =================================================================== --- UPDATING (revision 308708) +++ UPDATING (working copy) @@ -51,6 +51,11 @@ ****************************** SPECIAL WARNING: ****************************** +20161119: + The layout of the pmap structure has changed for powerpc to put the pmap + statistics at the front for all CPU variations. libkvm(3) and all tools + that link against it need to be recompiled. + 20161030: isl(4) and cyapa(4) drivers now require a new driver, chromebook_platform(4), to work properly on Chromebook-class hardware. --MP_/eYKnT8u=tt7OZI3sR.Gf6ts-- From owner-freebsd-current@freebsd.org Sun Nov 20 02:48:37 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6072C471DE for ; Sun, 20 Nov 2016 02:48:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-30.reflexion.net [208.70.210.30]) (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 755B21E1F for ; Sun, 20 Nov 2016 02:48:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31709 invoked from network); 20 Nov 2016 02:48:36 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 20 Nov 2016 02:48:36 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Sat, 19 Nov 2016 21:48:46 -0500 (EST) Received: (qmail 18135 invoked from network); 20 Nov 2016 02:48:45 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 Nov 2016 02:48:45 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 2760DEC903D; Sat, 19 Nov 2016 18:48:35 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: svn commit: r308817 - head/sys/powerpc/include [Still have pmap_t and struct pmap ppowerpc64 problems as of -r308860] From: Mark Millard In-Reply-To: <20161119203128.2ac46708@zhabar.knownspace> Date: Sat, 19 Nov 2016 18:48:34 -0800 Cc: svn-src-head@freebsd.org, FreeBSD Current Content-Transfer-Encoding: 7bit Message-Id: References: <39962D4C-29BA-4AA4-B77D-2344A68FDB54@dsl-only.net> <20161119203128.2ac46708@zhabar.knownspace> To: Justin Hibbits , Alan Cox X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 02:48:37 -0000 On 2016-Nov-19, at 6:31 PM, Justin Hibbits wrote: > On Sat, 19 Nov 2016 18:19:37 -0800 > Mark Millard wrote: > >>> Author: jhibbits >>> Date: Fri Nov 18 22:59:33 2016 >>> New Revision: 308817 >>> URL: https://svnweb.freebsd.org/changeset/base/308817 >>> >>> Log: >>> Fix buildworld >>> >>> Change the pv_tracked flag to an int, just in case userspace >>> decides to include this file and defines BOOKE. >>> >>> Guard this block from unintentional inclusion with ifdef BOOKE. >>> >>> Reported by: emaste >> . . . >> >> (Later quotes are not from the list or from E-mail but from files.) >> >> I'm not targeting BOOKE but GENERIC64 (via include, with AIM but not >> ps3). I'm at head -r308860 yet for TARGET_ARCH=powerpc64 I get the >> following that did not happen with my older -r308247 builds: >> >>> --- kinfo_getallproc.o --- >> . . . >>> In file included from /usr/src/sys/sys/user.h:53:0, >>> from q:34: >>> /usr/src/sys/vm/vm_map.h:190:2: error: unknown type name 'pmap_t' >>> pmap_t pmap; /* (c) Physical map */ >>> ^ >>> /usr/src/sys/vm/vm_map.h:250:14: error: field 'vm_pmap' has >>> incomplete type struct pmap vm_pmap; /* private physical map */ >>> ^ >>> --- kinfo_getfile.o --- >>> In file included from /usr/src/sys/sys/user.h:53:0, >>> from /usr/src/lib/libutil/kinfo_getfile.c:5: >>> /usr/src/sys/vm/vm_map.h:190:2: error: unknown type name 'pmap_t' >>> pmap_t pmap; /* (c) Physical map */ >>> ^ >>> /usr/src/sys/vm/vm_map.h:250:14: error: field 'vm_pmap' has >>> incomplete type struct pmap vm_pmap; /* private physical map */ >> >> >> It is almost like a machine/pmap.h include is missing now so that the >> types are not defined. But I've not yet found where the relevant >> difference(s) are from -r308247. >> >> Showing a compile command (with -v) with its failure. . . >> > > The change is the "#elif defined(BOOKE)". Since userspace doesn't > define either AIM nor BOOKE, struct pmap no longer exists. > > Alan, do you know if vmspace *needs* struct pmap to exist when read > from userspace (in libprocstat and libkvm, from what I grepped)? If > not, I can add a simple '#else struct pmap {};' to quiet the build. > > - Justin pmap_t (the pointer type) would also be needed. So far as I can tell when . . . . . . #if defined(AIM) . . . (definitions here) #elif defined(BOOKE) . . . (definitions here) #endif . . . was instead the older: . . . #if defined(AIM) . . . (definitions here) #else . . . (definitions here) #endif . . . kinfo_getallproc.c and kinfo_getfile.c and the like got a pmap definition, just not necessarily the right one (when AIM was defined for build kernel). In my context AIM is defined for buildkernel (PowerMac G5 via GENERIC64 use, although I turn off ps3 and have both vt and sc). (I've still not tracked down where kinfo_getallproc.c and kinfo_getfile.c end up with a machine/pmap.h include happening.) From owner-freebsd-current@freebsd.org Sun Nov 20 03:01:00 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F24A7C475D5 for ; Sun, 20 Nov 2016 03:01:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-32.reflexion.net [208.70.210.32]) (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 8EE02690 for ; Sun, 20 Nov 2016 03:01:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14273 invoked from network); 20 Nov 2016 03:00:44 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 20 Nov 2016 03:00:44 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Sat, 19 Nov 2016 22:00:44 -0500 (EST) Received: (qmail 2747 invoked from network); 20 Nov 2016 03:00:44 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 Nov 2016 03:00:44 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 2F3CCEC91C5; Sat, 19 Nov 2016 19:00:58 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: svn commit: r308817 - head/sys/powerpc/include [Still have pmap_t and struct pmap ppowerpc64 problems as of -r308860] From: Mark Millard In-Reply-To: <20161119204715.79632a66@zhabar.knownspace> Date: Sat, 19 Nov 2016 19:00:57 -0800 Cc: svn-src-head@freebsd.org, FreeBSD Current Content-Transfer-Encoding: 7bit Message-Id: References: <39962D4C-29BA-4AA4-B77D-2344A68FDB54@dsl-only.net> <53258F35-C86E-4DE0-BDF0-5C139E68356D@dsl-only.net> <20161119204715.79632a66@zhabar.knownspace> To: Justin Hibbits X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 03:01:01 -0000 It may take a little bit but I'll try the patch. It looks like sys/powerpc/include/pmap.h from -r176700 from 2088-Mar-3 is when the BOOKE/E500 split started with the preprocessor use of AIM and #else . This predates PowerMac G5 support. This is definitely not new for the general structure on the powerpc side of things. Any place that did not have the AIM vs. not status available was subject to problems of possibly mismatched definitions. === Mark Millard markmi at dsl-only.net On 2016-Nov-19, at 6:47 PM, Justin Hibbits wrote: On Sat, 19 Nov 2016 18:36:39 -0800 Mark Millard wrote: > [Quick top post I'm afraid.] > > I think that I figured out why there is a problem even earlier > --that just did not stop the compiles. > > lib/libutil/kinfo_getallproc.c is built here as part of buildworld > (stage 4.2 "building libraries" instead of buildkernel. It does not > have the KERNCONF's AIM vs. BOOKE vs. . . . definitions vs. lack of > them). > > So if it includes machine/pmap.h that binds to > sys/powerpc/include/pmap.h which has the structure. . . > > . . . > #if defined(AIM) > . . . (definitions here) > #elif defined(BOOKE) > . . . (definitions here) > #endif > . . . > > it gets no definition now. > > With the older: > > . . . > #if defined(AIM) > . . . (definitions here) > #else > . . . (definitions here) > #endif > . . . > > It got a definition, just not necessarily the right one. > > > === > Mark Millard > markmi at dsl-only.net Can you try the attached patch? There was a subtle ABI issue that r308817 exposed, which is that the pmap structs aren't identical such that the pm_stats are at different locations, and libkvm ends up reading with the Book-E pmap, getting different stats than expected for AIM. This patch fixes that, bumping version to account for this ABI change. - Justin From owner-freebsd-current@freebsd.org Sun Nov 20 03:27:09 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A689C47F61 for ; Sun, 20 Nov 2016 03:27:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-35.reflexion.net [208.70.210.35]) (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 DF75215FF for ; Sun, 20 Nov 2016 03:27:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7647 invoked from network); 20 Nov 2016 03:27:07 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 20 Nov 2016 03:27:07 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Sat, 19 Nov 2016 22:27:12 -0500 (EST) Received: (qmail 1819 invoked from network); 20 Nov 2016 03:27:12 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 Nov 2016 03:27:12 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 59815EC901D; Sat, 19 Nov 2016 19:27:05 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: svn commit: r308817 - head/sys/powerpc/include [Still have pmap_t and struct pmap ppowerpc64 problems as of -r308860] From: Mark Millard In-Reply-To: Date: Sat, 19 Nov 2016 19:27:04 -0800 Cc: svn-src-head@freebsd.org, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <3D338DB4-9FAF-46A8-96FF-4F77B01871E2@dsl-only.net> References: <39962D4C-29BA-4AA4-B77D-2344A68FDB54@dsl-only.net> <53258F35-C86E-4DE0-BDF0-5C139E68356D@dsl-only.net> <20161119204715.79632a66@zhabar.knownspace> To: Justin Hibbits X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 03:27:09 -0000 [Top post about patch issues.] Looking at the patch it seems to be designed for when #else was in use: > -#else > +#elif defined(BOOKE) but -r308817 already has the 2nd line (BOOKE). Your patch shows: > Index: sys/powerpc/include/pmap.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/powerpc/include/pmap.h (revision 308718) > +++ sys/powerpc/include/pmap.h (working copy) So it looks like you started from before -r308817 . Trying it (I'm at -r308860): > Patching file sys/powerpc/include/pmap.h using Plan A... > Hunk #1 succeeded at 74. > Hunk #2 succeeded at 84. > Hunk #3 succeeded at 132. > Hunk #4 succeeded at 145. > Hunk #5 failed at 180. > Hunk #6 succeeded at 194. > Hunk #7 succeeded at 210. > 1 out of 7 hunks failed--saving rejects to = sys/powerpc/include/pmap.h.rej > # more sys/powerpc/include/pmap.h.rej > @@ -179,13 +180,13 @@ > struct slb **slb_alloc_user_cache(void); > void slb_free_user_cache(struct slb **); > =20 > -#else > +#elif defined(BOOKE) > =20 > struct pmap { > + struct pmap_statistics pm_stats; /* pmap statistics */ > struct mtx pm_mtx; /* pmap mutex */ > tlbtid_t pm_tid[MAXCPU]; /* TID to identify = this pmap entries in TLB */ > cpuset_t pm_active; /* active on cpus */ > - struct pmap_statistics pm_stats; /* pmap statistics */ > =20 > /* Page table directory, array of pointers to page tables. */ > pte_t *pm_pdir[PDIR_NENTRIES]; =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Nov-19, at 7:00 PM, Mark Millard wrote: It may take a little bit but I'll try the patch. It looks like sys/powerpc/include/pmap.h from -r176700 from 2088-Mar-3 is when the BOOKE/E500 split started with the preprocessor use of AIM and #else . This predates PowerMac G5 support. This is definitely not new for the general structure on the powerpc side of things. Any place that did not have the AIM vs. not status available was subject to problems of possibly mismatched definitions. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Nov-19, at 6:47 PM, Justin Hibbits = wrote: On Sat, 19 Nov 2016 18:36:39 -0800 Mark Millard wrote: > [Quick top post I'm afraid.] >=20 > I think that I figured out why there is a problem even earlier > --that just did not stop the compiles. >=20 > lib/libutil/kinfo_getallproc.c is built here as part of buildworld > (stage 4.2 "building libraries" instead of buildkernel. It does not > have the KERNCONF's AIM vs. BOOKE vs. . . . definitions vs. lack of > them). >=20 > So if it includes machine/pmap.h that binds to > sys/powerpc/include/pmap.h which has the structure. . . >=20 > . . . > #if defined(AIM) > . . . (definitions here) > #elif defined(BOOKE) > . . . (definitions here) > #endif > . . . >=20 > it gets no definition now. >=20 > With the older: >=20 > . . . > #if defined(AIM) > . . . (definitions here) > #else > . . . (definitions here) > #endif > . . . >=20 > It got a definition, just not necessarily the right one. >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net Can you try the attached patch? There was a subtle ABI issue that r308817 exposed, which is that the pmap structs aren't identical such that the pm_stats are at different locations, and libkvm ends up reading with the Book-E pmap, getting different stats than expected for AIM. This patch fixes that, bumping version to account for this ABI change. - Justin From owner-freebsd-current@freebsd.org Sun Nov 20 03:32:49 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 56502C3E235; Sun, 20 Nov 2016 03:32:49 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-ua0-x244.google.com (mail-ua0-x244.google.com [IPv6:2607:f8b0:400c:c08::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B39A1B66; Sun, 20 Nov 2016 03:32:49 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-ua0-x244.google.com with SMTP id b35so21986677uaa.1; Sat, 19 Nov 2016 19:32:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=qNKNmklHlKbaCmehOfmM3JPjpN2lrAeph0Ex76VSFkY=; b=uRFFIaa2t8txV0b5eYyQ2JYLdgpXGVzxosoUhrMi3vri99HiHB1RQc1EoP2/HJtEWH nE0GXYADhesb5wTaT+fJ/uIdlaWjh3HBNx4+IxpHUNPDq4j4E/IgU8i/D8vHixynEF9G 2afEhD8sc4BVmUVI6J1hkgfO1aEPCGFP+on5I4q2tCMCEmvQ5fLmmuT/VEG9LBNVY6g4 s99htDPLxKWN1XUpJdEa1vmNMtAnoEhdReX342occHk5RjBG8J2BXHnDGyl3myVJoBbv Yn1mSI6495aFw9gDtYwqJZKWMIoSHvHWLwmtTvUQQqoqc3VwFhEJUtA1PZpvWm42f8/b YcRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=qNKNmklHlKbaCmehOfmM3JPjpN2lrAeph0Ex76VSFkY=; b=Mq++jj9iJljq2uN5h9RwwAPJ7e8pVhgs2tIGPyp4ta1Pot4knTOV/U6iTwkXuO9MVg 1nfq2sQeB0wnWWYISH6XoiHOTSKaCDT0vHo+zHdlJvk9UFNKY2CZxsMi31pVkLTfVsvG njtmEB28qWh2UpVsIXq5tXSYMzl/M7CRMJzNsD0yv0TxP9SB0sdpdnVb2Y1iutjTEHz7 qmTwvkvkPPGjFbuyHDWibDiwlCEroErBRR7Pl1uG/nn5cOP5XbRi59LlNB4vlFhh8y5T /LqFsV3zYPBzI+z0GpYjQ4GGXehj539hE8l6agcpg0nU3vpVuScuaOXO4rPlYTMjrKxZ EKFg== X-Gm-Message-State: AKaTC01KsY8yoSpC1ZywiZdBR/Cz+RaGPpIM3fOvHd5ugnyk/RlfC2LMvezLyIxdSTBDuD3dyVL9V7W1vFUF5Q== X-Received: by 10.176.80.46 with SMTP id b43mr3978132uaa.135.1479612768097; Sat, 19 Nov 2016 19:32:48 -0800 (PST) MIME-Version: 1.0 Sender: chmeeedalf@gmail.com Received: by 10.103.150.66 with HTTP; Sat, 19 Nov 2016 19:32:47 -0800 (PST) Received: by 10.103.150.66 with HTTP; Sat, 19 Nov 2016 19:32:47 -0800 (PST) In-Reply-To: <3D338DB4-9FAF-46A8-96FF-4F77B01871E2@dsl-only.net> References: <39962D4C-29BA-4AA4-B77D-2344A68FDB54@dsl-only.net> <53258F35-C86E-4DE0-BDF0-5C139E68356D@dsl-only.net> <20161119204715.79632a66@zhabar.knownspace> <3D338DB4-9FAF-46A8-96FF-4F77B01871E2@dsl-only.net> From: Justin Hibbits Date: Sat, 19 Nov 2016 21:32:47 -0600 X-Google-Sender-Auth: hJUhpIz5GPzFTX-rTAHWerZAWTc Message-ID: Subject: Re: svn commit: r308817 - head/sys/powerpc/include [Still have pmap_t and struct pmap ppowerpc64 problems as of -r308860] To: Mark Millard Cc: svn-src-head@freebsd.org, FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 03:32:49 -0000 Sorry, I generated the diff from a different tree that wasn't synced to head (had the same change in both trees originally). If that is the only problem, you can ignore it and try the rest. I can generate another diff later too. - Justin On Nov 19, 2016 21:27, "Mark Millard" wrote: > [Top post about patch issues.] > > Looking at the patch it seems to be designed for when #else was in use: > > > -#else > > +#elif defined(BOOKE) > > but -r308817 already has the 2nd line (BOOKE). Your patch shows: > > > Index: sys/powerpc/include/pmap.h > > =================================================================== > > --- sys/powerpc/include/pmap.h (revision 308718) > > +++ sys/powerpc/include/pmap.h (working copy) > > So it looks like you started from before -r308817 . > > Trying it (I'm at -r308860): > > > Patching file sys/powerpc/include/pmap.h using Plan A... > > Hunk #1 succeeded at 74. > > Hunk #2 succeeded at 84. > > Hunk #3 succeeded at 132. > > Hunk #4 succeeded at 145. > > Hunk #5 failed at 180. > > Hunk #6 succeeded at 194. > > Hunk #7 succeeded at 210. > > 1 out of 7 hunks failed--saving rejects to sys/powerpc/include/pmap.h.rej > > > # more sys/powerpc/include/pmap.h.rej > > @@ -179,13 +180,13 @@ > > struct slb **slb_alloc_user_cache(void); > > void slb_free_user_cache(struct slb **); > > > > -#else > > +#elif defined(BOOKE) > > > > struct pmap { > > + struct pmap_statistics pm_stats; /* pmap statistics */ > > struct mtx pm_mtx; /* pmap mutex */ > > tlbtid_t pm_tid[MAXCPU]; /* TID to identify this > pmap entries in TLB */ > > cpuset_t pm_active; /* active on cpus */ > > - struct pmap_statistics pm_stats; /* pmap statistics */ > > > > /* Page table directory, array of pointers to page tables. */ > > pte_t *pm_pdir[PDIR_NENTRIES]; > > > === > Mark Millard > markmi at dsl-only.net > > On 2016-Nov-19, at 7:00 PM, Mark Millard wrote: > > It may take a little bit but I'll try the patch. > > It looks like sys/powerpc/include/pmap.h from -r176700 from 2088-Mar-3 > is when the BOOKE/E500 split started with the preprocessor use of AIM > and #else . This predates PowerMac G5 support. > > This is definitely not new for the general structure on the powerpc > side of things. Any place that did not have the AIM vs. not status > available was subject to problems of possibly mismatched definitions. > > === > Mark Millard > markmi at dsl-only.net > > On 2016-Nov-19, at 6:47 PM, Justin Hibbits > wrote: > > On Sat, 19 Nov 2016 18:36:39 -0800 > Mark Millard wrote: > > > [Quick top post I'm afraid.] > > > > I think that I figured out why there is a problem even earlier > > --that just did not stop the compiles. > > > > lib/libutil/kinfo_getallproc.c is built here as part of buildworld > > (stage 4.2 "building libraries" instead of buildkernel. It does not > > have the KERNCONF's AIM vs. BOOKE vs. . . . definitions vs. lack of > > them). > > > > So if it includes machine/pmap.h that binds to > > sys/powerpc/include/pmap.h which has the structure. . . > > > > . . . > > #if defined(AIM) > > . . . (definitions here) > > #elif defined(BOOKE) > > . . . (definitions here) > > #endif > > . . . > > > > it gets no definition now. > > > > With the older: > > > > . . . > > #if defined(AIM) > > . . . (definitions here) > > #else > > . . . (definitions here) > > #endif > > . . . > > > > It got a definition, just not necessarily the right one. > > > > > > === > > Mark Millard > > markmi at dsl-only.net > > Can you try the attached patch? There was a subtle ABI issue that > r308817 exposed, which is that the pmap structs aren't identical such > that the pm_stats are at different locations, and libkvm ends up > reading with the Book-E pmap, getting different stats than expected for > AIM. This patch fixes that, bumping version to account for this ABI > change. > > - Justin > > > From owner-freebsd-current@freebsd.org Sun Nov 20 03:36:28 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C833EC3E326 for ; Sun, 20 Nov 2016 03:36:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-30.reflexion.net [208.70.210.30]) (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 88FD11D2B for ; Sun, 20 Nov 2016 03:36:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31064 invoked from network); 20 Nov 2016 03:36:12 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 20 Nov 2016 03:36:12 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Sat, 19 Nov 2016 22:36:36 -0500 (EST) Received: (qmail 10124 invoked from network); 20 Nov 2016 03:36:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 Nov 2016 03:36:36 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id ACA0EEC902D; Sat, 19 Nov 2016 19:36:25 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: svn commit: r308817 - head/sys/powerpc/include [Still have pmap_t and struct pmap ppowerpc64 problems as of -r308860] From: Mark Millard In-Reply-To: Date: Sat, 19 Nov 2016 19:36:25 -0800 Cc: svn-src-head@freebsd.org, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <39962D4C-29BA-4AA4-B77D-2344A68FDB54@dsl-only.net> <53258F35-C86E-4DE0-BDF0-5C139E68356D@dsl-only.net> <20161119204715.79632a66@zhabar.knownspace> <3D338DB4-9FAF-46A8-96FF-4F77B01871E2@dsl-only.net> To: Justin Hibbits X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 03:36:28 -0000 On 2016-Nov-19, at 7:32 PM, Justin Hibbits wrote: > Sorry, I generated the diff from a different tree that wasn't synced = to head (had the same change in both trees originally). If that is the = only problem, you can ignore it and try the rest. I can generate another = diff later too. > - Justin Yep: I manually did the move of the pm_stats line and am building. =3D=3D=3D Mark Millard markmi at dsl-only.net On Nov 19, 2016 21:27, "Mark Millard" wrote: > [Top post about patch issues.] >=20 > Looking at the patch it seems to be designed for when #else was in = use: >=20 > > -#else > > +#elif defined(BOOKE) >=20 > but -r308817 already has the 2nd line (BOOKE). Your patch shows: >=20 > > Index: sys/powerpc/include/pmap.h > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- sys/powerpc/include/pmap.h (revision 308718) > > +++ sys/powerpc/include/pmap.h (working copy) >=20 > So it looks like you started from before -r308817 . >=20 > Trying it (I'm at -r308860): >=20 > > Patching file sys/powerpc/include/pmap.h using Plan A... > > Hunk #1 succeeded at 74. > > Hunk #2 succeeded at 84. > > Hunk #3 succeeded at 132. > > Hunk #4 succeeded at 145. > > Hunk #5 failed at 180. > > Hunk #6 succeeded at 194. > > Hunk #7 succeeded at 210. > > 1 out of 7 hunks failed--saving rejects to = sys/powerpc/include/pmap.h.rej >=20 > > # more sys/powerpc/include/pmap.h.rej > > @@ -179,13 +180,13 @@ > > struct slb **slb_alloc_user_cache(void); > > void slb_free_user_cache(struct slb **); > > > > -#else > > +#elif defined(BOOKE) > > > > struct pmap { > > + struct pmap_statistics pm_stats; /* pmap statistics = */ > > struct mtx pm_mtx; /* pmap mutex */ > > tlbtid_t pm_tid[MAXCPU]; /* TID to identify = this pmap entries in TLB */ > > cpuset_t pm_active; /* active on cpus */ > > - struct pmap_statistics pm_stats; /* pmap statistics = */ > > > > /* Page table directory, array of pointers to page tables. = */ > > pte_t *pm_pdir[PDIR_NENTRIES]; >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Nov-19, at 7:00 PM, Mark Millard wrote: >=20 > It may take a little bit but I'll try the patch. >=20 > It looks like sys/powerpc/include/pmap.h from -r176700 from 2088-Mar-3 > is when the BOOKE/E500 split started with the preprocessor use of AIM > and #else . This predates PowerMac G5 support. >=20 > This is definitely not new for the general structure on the powerpc > side of things. Any place that did not have the AIM vs. not status > available was subject to problems of possibly mismatched definitions. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Nov-19, at 6:47 PM, Justin Hibbits = wrote: >=20 > On Sat, 19 Nov 2016 18:36:39 -0800 > Mark Millard wrote: >=20 > > [Quick top post I'm afraid.] > > > > I think that I figured out why there is a problem even earlier > > --that just did not stop the compiles. > > > > lib/libutil/kinfo_getallproc.c is built here as part of buildworld > > (stage 4.2 "building libraries" instead of buildkernel. It does not > > have the KERNCONF's AIM vs. BOOKE vs. . . . definitions vs. lack of > > them). > > > > So if it includes machine/pmap.h that binds to > > sys/powerpc/include/pmap.h which has the structure. . . > > > > . . . > > #if defined(AIM) > > . . . (definitions here) > > #elif defined(BOOKE) > > . . . (definitions here) > > #endif > > . . . > > > > it gets no definition now. > > > > With the older: > > > > . . . > > #if defined(AIM) > > . . . (definitions here) > > #else > > . . . (definitions here) > > #endif > > . . . > > > > It got a definition, just not necessarily the right one. > > > > > > =3D=3D=3D > > Mark Millard > > markmi at dsl-only.net >=20 > Can you try the attached patch? There was a subtle ABI issue that > r308817 exposed, which is that the pmap structs aren't identical such > that the pm_stats are at different locations, and libkvm ends up > reading with the Book-E pmap, getting different stats than expected = for > AIM. This patch fixes that, bumping version to account for this ABI > change. >=20 > - Justin From owner-freebsd-current@freebsd.org Sun Nov 20 03:42:30 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 72DB9C3E5FE for ; Sun, 20 Nov 2016 03:42:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-30.reflexion.net [208.70.210.30]) (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 377C31D4 for ; Sun, 20 Nov 2016 03:42:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 20857 invoked from network); 20 Nov 2016 03:42:29 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 20 Nov 2016 03:42:29 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Sat, 19 Nov 2016 22:42:38 -0500 (EST) Received: (qmail 19248 invoked from network); 20 Nov 2016 03:42:38 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 Nov 2016 03:42:38 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 83430EC901D; Sat, 19 Nov 2016 19:42:27 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: svn commit: r308817 - head/sys/powerpc/include [Still have pmap_t and struct pmap ppowerpc64 problems as of -r308860] From: Mark Millard In-Reply-To: Date: Sat, 19 Nov 2016 19:42:27 -0800 Cc: svn-src-head@freebsd.org, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <1EC92166-7DF3-42DC-9AAD-AED1BA9D5CC1@dsl-only.net> References: <39962D4C-29BA-4AA4-B77D-2344A68FDB54@dsl-only.net> <53258F35-C86E-4DE0-BDF0-5C139E68356D@dsl-only.net> <20161119204715.79632a66@zhabar.knownspace> <3D338DB4-9FAF-46A8-96FF-4F77B01871E2@dsl-only.net> To: Justin Hibbits X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 03:42:30 -0000 On 2016-Nov-19, at 7:36 PM, Mark Millard wrote: > On 2016-Nov-19, at 7:32 PM, Justin Hibbits = wrote: >=20 >> Sorry, I generated the diff from a different tree that wasn't synced = to head (had the same change in both trees originally). If that is the = only problem, you can ignore it and try the rest. I can generate another = diff later too. >> - Justin >=20 > Yep: I manually did the move of the pm_stats line and am building. If it builds and I install it on a PowerMac G5 and it boots, what do I do to test if pm_stats and pm_mtx seems to be working well/right for the out of kernel code? Do you know of a reasonable test? =3D=3D=3D Mark Millard markmi at dsl-only.net On Nov 19, 2016 21:27, "Mark Millard" wrote: > [Top post about patch issues.] >=20 > Looking at the patch it seems to be designed for when #else was in = use: >=20 >> -#else >> +#elif defined(BOOKE) >=20 > but -r308817 already has the 2nd line (BOOKE). Your patch shows: >=20 >> Index: sys/powerpc/include/pmap.h >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- sys/powerpc/include/pmap.h (revision 308718) >> +++ sys/powerpc/include/pmap.h (working copy) >=20 > So it looks like you started from before -r308817 . >=20 > Trying it (I'm at -r308860): >=20 >> Patching file sys/powerpc/include/pmap.h using Plan A... >> Hunk #1 succeeded at 74. >> Hunk #2 succeeded at 84. >> Hunk #3 succeeded at 132. >> Hunk #4 succeeded at 145. >> Hunk #5 failed at 180. >> Hunk #6 succeeded at 194. >> Hunk #7 succeeded at 210. >> 1 out of 7 hunks failed--saving rejects to = sys/powerpc/include/pmap.h.rej >=20 >> # more sys/powerpc/include/pmap.h.rej >> @@ -179,13 +180,13 @@ >> struct slb **slb_alloc_user_cache(void); >> void slb_free_user_cache(struct slb **); >>=20 >> -#else >> +#elif defined(BOOKE) >>=20 >> struct pmap { >> + struct pmap_statistics pm_stats; /* pmap statistics */ >> struct mtx pm_mtx; /* pmap mutex */ >> tlbtid_t pm_tid[MAXCPU]; /* TID to identify = this pmap entries in TLB */ >> cpuset_t pm_active; /* active on cpus */ >> - struct pmap_statistics pm_stats; /* pmap statistics */ >>=20 >> /* Page table directory, array of pointers to page tables. */ >> pte_t *pm_pdir[PDIR_NENTRIES]; >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Nov-19, at 7:00 PM, Mark Millard = wrote: >=20 > It may take a little bit but I'll try the patch. >=20 > It looks like sys/powerpc/include/pmap.h from -r176700 from 2088-Mar-3 > is when the BOOKE/E500 split started with the preprocessor use of AIM > and #else . This predates PowerMac G5 support. >=20 > This is definitely not new for the general structure on the powerpc > side of things. Any place that did not have the AIM vs. not status > available was subject to problems of possibly mismatched definitions. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Nov-19, at 6:47 PM, Justin Hibbits = wrote: >=20 > On Sat, 19 Nov 2016 18:36:39 -0800 > Mark Millard wrote: >=20 >> [Quick top post I'm afraid.] >>=20 >> I think that I figured out why there is a problem even earlier >> --that just did not stop the compiles. >>=20 >> lib/libutil/kinfo_getallproc.c is built here as part of buildworld >> (stage 4.2 "building libraries" instead of buildkernel. It does not >> have the KERNCONF's AIM vs. BOOKE vs. . . . definitions vs. lack of >> them). >>=20 >> So if it includes machine/pmap.h that binds to >> sys/powerpc/include/pmap.h which has the structure. . . >>=20 >> . . . >> #if defined(AIM) >> . . . (definitions here) >> #elif defined(BOOKE) >> . . . (definitions here) >> #endif >> . . . >>=20 >> it gets no definition now. >>=20 >> With the older: >>=20 >> . . . >> #if defined(AIM) >> . . . (definitions here) >> #else >> . . . (definitions here) >> #endif >> . . . >>=20 >> It got a definition, just not necessarily the right one. >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > Can you try the attached patch? There was a subtle ABI issue that > r308817 exposed, which is that the pmap structs aren't identical such > that the pm_stats are at different locations, and libkvm ends up > reading with the Book-E pmap, getting different stats than expected = for > AIM. This patch fixes that, bumping version to account for this ABI > change. >=20 > - Justin From owner-freebsd-current@freebsd.org Sun Nov 20 03:47:14 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E338AC3E779; Sun, 20 Nov 2016 03:47:14 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-ua0-x244.google.com (mail-ua0-x244.google.com [IPv6:2607:f8b0:400c:c08::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8F1273E3; Sun, 20 Nov 2016 03:47:14 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-ua0-x244.google.com with SMTP id 12so21930386uas.3; Sat, 19 Nov 2016 19:47:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=mI9MRGFIKXmuxE1f8S5aMkI5pTnI7wcygirI2MBqFSY=; b=vKELH3mz0+SeQf/ZwVcIa/WNbTc2RIhliFSkXdjcmLLiGg6nDFSYrW8bpoXpWj+anf JKq57bF4Nzy2+ofjbJTFX0goy82X+DfB0Ru2jc+YboJ1FjhNXjK4eGdNa/opo+ASUC2F i49GojtjilBs/jthMhLAs7Po1/KYNORk5XTAAtbjmD2keenk6crPEsSI78acTY4qO1bn X+WrZ+wxmFXjTzjT5fz3z3TdwoUP2qW2eJ76wb3uoZgH8wIxadTJXTgX5tlhWRpykL0S 4uMyzt7shGePpI74hw+W2OGFvwZJvY0CIxk+/1HlOnaKvGntS0cHFfs92ww6uESPT7qb o80Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=mI9MRGFIKXmuxE1f8S5aMkI5pTnI7wcygirI2MBqFSY=; b=MExBhu4jB30SfHyT3nPMt4NBT2A+M9879yRhDL6i19yTSRNZHI+4WQ/lZZ+ZqhcIiA hRzrXgK6XK7Ple6XAWzGmu5AZkHRMvjsimFo5hWwHTJFH0dy4QrimElARAeOGhNjYObK Vyp7qE4/s0+691899G4oaG62VWoCPPCYMOUK8i09jRp0vblEW8Ehw5J755RNBstp2WMA RrJVV1F6AYMgfAq5tB5j0LrjMQhRxNCGYXl86IgsGToZ7aPbchZCacfBGK9wfGF75X+D wSJ3ymdFzWbm8wXOxoqbHh5uH6OoVoXJISZHiLVT28wSy/ZuqSycYY5+rmsOl6pxg234 KA8w== X-Gm-Message-State: AKaTC03XfoFiBFbo3sv4zGtkq30RCcHiF0+daPuKqb8BNhOb4vOMyzrn0XK9TimSPqAnGD86NL5xu0AO8X3mfg== X-Received: by 10.176.80.101 with SMTP id z34mr4117623uaz.140.1479613633752; Sat, 19 Nov 2016 19:47:13 -0800 (PST) MIME-Version: 1.0 Sender: chmeeedalf@gmail.com Received: by 10.103.150.66 with HTTP; Sat, 19 Nov 2016 19:47:12 -0800 (PST) Received: by 10.103.150.66 with HTTP; Sat, 19 Nov 2016 19:47:12 -0800 (PST) In-Reply-To: <1EC92166-7DF3-42DC-9AAD-AED1BA9D5CC1@dsl-only.net> References: <39962D4C-29BA-4AA4-B77D-2344A68FDB54@dsl-only.net> <53258F35-C86E-4DE0-BDF0-5C139E68356D@dsl-only.net> <20161119204715.79632a66@zhabar.knownspace> <3D338DB4-9FAF-46A8-96FF-4F77B01871E2@dsl-only.net> <1EC92166-7DF3-42DC-9AAD-AED1BA9D5CC1@dsl-only.net> From: Justin Hibbits Date: Sat, 19 Nov 2016 21:47:12 -0600 X-Google-Sender-Auth: p41Qez5AmZlmwwexVot_DeMQGvQ Message-ID: Subject: Re: svn commit: r308817 - head/sys/powerpc/include [Still have pmap_t and struct pmap ppowerpc64 problems as of -r308860] To: Mark Millard Cc: svn-src-head@freebsd.org, FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 03:47:15 -0000 On Nov 19, 2016 21:42, "Mark Millard" wrote: > > On 2016-Nov-19, at 7:36 PM, Mark Millard wrote: > > > On 2016-Nov-19, at 7:32 PM, Justin Hibbits wrote: > > > >> Sorry, I generated the diff from a different tree that wasn't synced to head (had the same change in both trees originally). If that is the only problem, you can ignore it and try the rest. I can generate another diff later too. > >> - Justin > > > > Yep: I manually did the move of the pm_stats line and am building. > > If it builds and I install it on a PowerMac G5 and it boots, what do I > do to test if pm_stats and pm_mtx seems to be working well/right for > the out of kernel code? Do you know of a reasonable test? > > === > Mark Millard > markmi at dsl-only.net I think using procstat should work. Not at my machine right now so can't really check the man page, but libprocstat and libkvm both read vmspace, so that's a likely candidate. - Justin From owner-freebsd-current@freebsd.org Sun Nov 20 03:47:33 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5658C3E7CC for ; Sun, 20 Nov 2016 03:47:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-30.reflexion.net [208.70.210.30]) (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 7940775C for ; Sun, 20 Nov 2016 03:47:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24732 invoked from network); 20 Nov 2016 03:47:33 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 20 Nov 2016 03:47:33 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Sat, 19 Nov 2016 22:47:38 -0500 (EST) Received: (qmail 7780 invoked from network); 20 Nov 2016 03:47:38 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 Nov 2016 03:47:38 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 880F2EC903D; Sat, 19 Nov 2016 19:47:31 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: svn commit: r308817 - head/sys/powerpc/include [Still have pmap_t and struct pmap ppowerpc64 problems as of -r308860] From: Mark Millard In-Reply-To: <1EC92166-7DF3-42DC-9AAD-AED1BA9D5CC1@dsl-only.net> Date: Sat, 19 Nov 2016 19:47:31 -0800 Cc: svn-src-head@freebsd.org, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <59613CEF-BA2D-4010-996C-6FB8F9D126C6@dsl-only.net> References: <39962D4C-29BA-4AA4-B77D-2344A68FDB54@dsl-only.net> <53258F35-C86E-4DE0-BDF0-5C139E68356D@dsl-only.net> <20161119204715.79632a66@zhabar.knownspace> <3D338DB4-9FAF-46A8-96FF-4F77B01871E2@dsl-only.net> <1EC92166-7DF3-42DC-9AAD-AED1BA9D5CC1@dsl-only.net> To: Justin Hibbits X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 03:47:33 -0000 [Top post of bad news.] With the patch I get a different incomplete type used in libmemstat: struct md_page --- all_subdir_lib/libmemstat --- In file included from /usr/src/lib/libmemstat/memstat_uma.c:34:0: /usr/src/sys/vm/vm_page.h:144:17: error: field 'md' has incomplete type struct md_page md; /* machine dependent stuff */ ^ *** [memstat_uma.o] Error code 1 make[5]: stopped in /usr/src/lib/libmemstat =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Nov-19, at 7:42 PM, Mark Millard wrote: > On 2016-Nov-19, at 7:36 PM, Mark Millard = wrote: >=20 >> On 2016-Nov-19, at 7:32 PM, Justin Hibbits = wrote: >>=20 >>> Sorry, I generated the diff from a different tree that wasn't synced = to head (had the same change in both trees originally). If that is the = only problem, you can ignore it and try the rest. I can generate another = diff later too. >>> - Justin >>=20 >> Yep: I manually did the move of the pm_stats line and am building. >=20 > If it builds and I install it on a PowerMac G5 and it boots, what do I > do to test if pm_stats and pm_mtx seems to be working well/right for > the out of kernel code? Do you know of a reasonable test? >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 On Nov 19, 2016 21:27, "Mark Millard" wrote: > [Top post about patch issues.] >=20 > Looking at the patch it seems to be designed for when #else was in = use: >=20 >> -#else >> +#elif defined(BOOKE) >=20 > but -r308817 already has the 2nd line (BOOKE). Your patch shows: >=20 >> Index: sys/powerpc/include/pmap.h >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- sys/powerpc/include/pmap.h (revision 308718) >> +++ sys/powerpc/include/pmap.h (working copy) >=20 > So it looks like you started from before -r308817 . >=20 > Trying it (I'm at -r308860): >=20 >> Patching file sys/powerpc/include/pmap.h using Plan A... >> Hunk #1 succeeded at 74. >> Hunk #2 succeeded at 84. >> Hunk #3 succeeded at 132. >> Hunk #4 succeeded at 145. >> Hunk #5 failed at 180. >> Hunk #6 succeeded at 194. >> Hunk #7 succeeded at 210. >> 1 out of 7 hunks failed--saving rejects to = sys/powerpc/include/pmap.h.rej >=20 >> # more sys/powerpc/include/pmap.h.rej >> @@ -179,13 +180,13 @@ >> struct slb **slb_alloc_user_cache(void); >> void slb_free_user_cache(struct slb **); >>=20 >> -#else >> +#elif defined(BOOKE) >>=20 >> struct pmap { >> + struct pmap_statistics pm_stats; /* pmap statistics */ >> struct mtx pm_mtx; /* pmap mutex */ >> tlbtid_t pm_tid[MAXCPU]; /* TID to identify this = pmap entries in TLB */ >> cpuset_t pm_active; /* active on cpus */ >> - struct pmap_statistics pm_stats; /* pmap statistics */ >>=20 >> /* Page table directory, array of pointers to page tables. */ >> pte_t *pm_pdir[PDIR_NENTRIES]; >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Nov-19, at 7:00 PM, Mark Millard = wrote: >=20 > It may take a little bit but I'll try the patch. >=20 > It looks like sys/powerpc/include/pmap.h from -r176700 from 2088-Mar-3 > is when the BOOKE/E500 split started with the preprocessor use of AIM > and #else . This predates PowerMac G5 support. >=20 > This is definitely not new for the general structure on the powerpc > side of things. Any place that did not have the AIM vs. not status > available was subject to problems of possibly mismatched definitions. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Nov-19, at 6:47 PM, Justin Hibbits = wrote: >=20 > On Sat, 19 Nov 2016 18:36:39 -0800 > Mark Millard wrote: >=20 >> [Quick top post I'm afraid.] >>=20 >> I think that I figured out why there is a problem even earlier >> --that just did not stop the compiles. >>=20 >> lib/libutil/kinfo_getallproc.c is built here as part of buildworld >> (stage 4.2 "building libraries" instead of buildkernel. It does not >> have the KERNCONF's AIM vs. BOOKE vs. . . . definitions vs. lack of >> them). >>=20 >> So if it includes machine/pmap.h that binds to >> sys/powerpc/include/pmap.h which has the structure. . . >>=20 >> . . . >> #if defined(AIM) >> . . . (definitions here) >> #elif defined(BOOKE) >> . . . (definitions here) >> #endif >> . . . >>=20 >> it gets no definition now. >>=20 >> With the older: >>=20 >> . . . >> #if defined(AIM) >> . . . (definitions here) >> #else >> . . . (definitions here) >> #endif >> . . . >>=20 >> It got a definition, just not necessarily the right one. >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > Can you try the attached patch? There was a subtle ABI issue that > r308817 exposed, which is that the pmap structs aren't identical such > that the pm_stats are at different locations, and libkvm ends up > reading with the Book-E pmap, getting different stats than expected = for > AIM. This patch fixes that, bumping version to account for this ABI > change. >=20 > - Justin From owner-freebsd-current@freebsd.org Sun Nov 20 04:06:42 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0792CC3EDAA; Sun, 20 Nov 2016 04:06:42 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BE973105F; Sun, 20 Nov 2016 04:06:41 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-it0-x242.google.com with SMTP id o1so11063147ito.1; Sat, 19 Nov 2016 20:06:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:cc:message-id:from:to:in-reply-to:content-transfer-encoding :mime-version:subject:date:references; bh=rqgZhIfxVvcVfRGWagbCvcWgqV9GSyZanKf98ksIl4M=; b=HGMhI3XOM1MpPLxTG5mp34oNpzAFVN4pZWP4LwO4pE8PFhEOWBduF6j6WwJ9Gk6FOi dWF0WKvw4CjbJajO9Ob7UZ9BfrvFQAvi/LwfmY4no9IIgaJZdAHfxyUjCUQWs3HOBuSE jHtv59eDKMg3IhQgNPiUu6RiDji8ab91V7c+1FO2hI++GIhzGCnl/cb+j1RPok64E0EK w5kekCBgG20y9646i57Y21Q2IL7IrEQUKITpCKw5lM8Dd2xNKlJpsOSRSJ8XA4kk7h1O 53RjrpySRcG6kNahxZEqQ3y8fCOlo3K2wG6toEWMesrOiIIDQPFD952412PYQCjmW4/J IqRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:cc:message-id:from:to:in-reply-to :content-transfer-encoding:mime-version:subject:date:references; bh=rqgZhIfxVvcVfRGWagbCvcWgqV9GSyZanKf98ksIl4M=; b=adpU/JoBeU+ctiuIEeSTgcUk7WvLyPbELqA/OMrd/vZKwaYabqjXbmyaryURg8dnn/ 4cfRA96M811yjVYAg+xlNjUIaYHSI8jHgGlk1OMz96jLj6i4imphnCu79J4xjYadDFY3 yrYwf9AD0DLlqcljyHN+rFWwk2vh8wGH+yPInRIzHtvsbadCecgqhWk4lcLo1F1D7qJA XHvlCL5FyeqHeiy7CpmtqlbYy8SVO82dGLiCnIiO4d4XZdavpRlhYeHRZU9kLEkRkzjj oJFizMcoGgqr57H6nh9JazZhHhxG2o8NkEiiocRunpP9tjoOAuv9E4DmfHKNxI13SZ8I JkFQ== X-Gm-Message-State: AKaTC00YL0NUdLT1xLTndFECvAGETmhmP/dYZ8pGJcA5f3nrByI+5eVilu27R2vKD/ZXJw== X-Received: by 10.36.159.193 with SMTP id c184mr5035938ite.72.1479614800915; Sat, 19 Nov 2016 20:06:40 -0800 (PST) Received: from blackstar.knownspace (50-80-150-234.client.mchsi.com. [50.80.150.234]) by smtp.gmail.com with ESMTPSA id p20sm3855502itc.8.2016.11.19.20.06.39 (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 19 Nov 2016 20:06:40 -0800 (PST) Sender: Justin Hibbits Cc: svn-src-head@freebsd.org, FreeBSD Current Message-Id: From: Justin Hibbits To: Mark Millard In-Reply-To: <59613CEF-BA2D-4010-996C-6FB8F9D126C6@dsl-only.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: svn commit: r308817 - head/sys/powerpc/include [Still have pmap_t and struct pmap ppowerpc64 problems as of -r308860] Date: Wed, 16 Nov 2016 22:33:28 -0600 References: <39962D4C-29BA-4AA4-B77D-2344A68FDB54@dsl-only.net> <53258F35-C86E-4DE0-BDF0-5C139E68356D@dsl-only.net> <20161119204715.79632a66@zhabar.knownspace> <3D338DB4-9FAF-46A8-96FF-4F77B01871E2@dsl-only.net> <1EC92166-7DF3-42DC-9AAD-AED1BA9D5CC1@dsl-only.net> <59613CEF-BA2D-4010-996C-6FB8F9D126C6@dsl-only.net> X-Mailer: Apple Mail (2.936) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 04:06:42 -0000 *sigh* okay, thanks. I just tested, and vm/vm_page.h, and vm/vm.h can both be removed from memstat_uma.c for it to compile. I'm kicking off a buildworld myself now, too, and hope to have it ready to commit tomorrow (takes a couple hours to buildworld on my G5). - Justin On Nov 19, 2016, at 9:47 PM, Mark Millard wrote: > [Top post of bad news.] > > With the patch I get a different incomplete type used in libmemstat: > > struct md_page > > --- all_subdir_lib/libmemstat --- > In file included from /usr/src/lib/libmemstat/memstat_uma.c:34:0: > /usr/src/sys/vm/vm_page.h:144:17: error: field 'md' has incomplete > type > struct md_page md; /* machine dependent stuff */ > ^ > *** [memstat_uma.o] Error code 1 > > make[5]: stopped in /usr/src/lib/libmemstat > > > === > Mark Millard > markmi at dsl-only.net > > On 2016-Nov-19, at 7:42 PM, Mark Millard > wrote: > >> On 2016-Nov-19, at 7:36 PM, Mark Millard >> wrote: >> >>> On 2016-Nov-19, at 7:32 PM, Justin Hibbits >> freebsd.org> wrote: >>> >>>> Sorry, I generated the diff from a different tree that wasn't >>>> synced to head (had the same change in both trees originally). If >>>> that is the only problem, you can ignore it and try the rest. I >>>> can generate another diff later too. >>>> - Justin >>> >>> Yep: I manually did the move of the pm_stats line and am building. >> >> If it builds and I install it on a PowerMac G5 and it boots, what >> do I >> do to test if pm_stats and pm_mtx seems to be working well/right for >> the out of kernel code? Do you know of a reasonable test? >> >> === >> Mark Millard >> markmi at dsl-only.net >> > On Nov 19, 2016 21:27, "Mark Millard" wrote: >> [Top post about patch issues.] >> >> Looking at the patch it seems to be designed for when #else was in >> use: >> >>> -#else >>> +#elif defined(BOOKE) >> >> but -r308817 already has the 2nd line (BOOKE). Your patch shows: >> >>> Index: sys/powerpc/include/pmap.h >>> =================================================================== >>> --- sys/powerpc/include/pmap.h (revision 308718) >>> +++ sys/powerpc/include/pmap.h (working copy) >> >> So it looks like you started from before -r308817 . >> >> Trying it (I'm at -r308860): >> >>> Patching file sys/powerpc/include/pmap.h using Plan A... >>> Hunk #1 succeeded at 74. >>> Hunk #2 succeeded at 84. >>> Hunk #3 succeeded at 132. >>> Hunk #4 succeeded at 145. >>> Hunk #5 failed at 180. >>> Hunk #6 succeeded at 194. >>> Hunk #7 succeeded at 210. >>> 1 out of 7 hunks failed--saving rejects to sys/powerpc/include/ >>> pmap.h.rej >> >>> # more sys/powerpc/include/pmap.h.rej >>> @@ -179,13 +180,13 @@ >>> struct slb **slb_alloc_user_cache(void); >>> void slb_free_user_cache(struct slb **); >>> >>> -#else >>> +#elif defined(BOOKE) >>> >>> struct pmap { >>> + struct pmap_statistics pm_stats; /* pmap statistics >>> */ >>> struct mtx pm_mtx; /* pmap mutex */ >>> tlbtid_t pm_tid[MAXCPU]; /* TID to identify >>> this pmap entries in TLB */ >>> cpuset_t pm_active; /* active on cpus */ >>> - struct pmap_statistics pm_stats; /* pmap statistics >>> */ >>> >>> /* Page table directory, array of pointers to page tables. */ >>> pte_t *pm_pdir[PDIR_NENTRIES]; >> >> >> === >> Mark Millard >> markmi at dsl-only.net >> >> On 2016-Nov-19, at 7:00 PM, Mark Millard >> wrote: >> >> It may take a little bit but I'll try the patch. >> >> It looks like sys/powerpc/include/pmap.h from -r176700 from 2088- >> Mar-3 >> is when the BOOKE/E500 split started with the preprocessor use of AIM >> and #else . This predates PowerMac G5 support. >> >> This is definitely not new for the general structure on the powerpc >> side of things. Any place that did not have the AIM vs. not status >> available was subject to problems of possibly mismatched definitions. >> >> === >> Mark Millard >> markmi at dsl-only.net >> >> On 2016-Nov-19, at 6:47 PM, Justin Hibbits > freebsd.org> wrote: >> >> On Sat, 19 Nov 2016 18:36:39 -0800 >> Mark Millard wrote: >> >>> [Quick top post I'm afraid.] >>> >>> I think that I figured out why there is a problem even earlier >>> --that just did not stop the compiles. >>> >>> lib/libutil/kinfo_getallproc.c is built here as part of buildworld >>> (stage 4.2 "building libraries" instead of buildkernel. It does not >>> have the KERNCONF's AIM vs. BOOKE vs. . . . definitions vs. lack of >>> them). >>> >>> So if it includes machine/pmap.h that binds to >>> sys/powerpc/include/pmap.h which has the structure. . . >>> >>> . . . >>> #if defined(AIM) >>> . . . (definitions here) >>> #elif defined(BOOKE) >>> . . . (definitions here) >>> #endif >>> . . . >>> >>> it gets no definition now. >>> >>> With the older: >>> >>> . . . >>> #if defined(AIM) >>> . . . (definitions here) >>> #else >>> . . . (definitions here) >>> #endif >>> . . . >>> >>> It got a definition, just not necessarily the right one. >>> >>> >>> === >>> Mark Millard >>> markmi at dsl-only.net >> >> Can you try the attached patch? There was a subtle ABI issue that >> r308817 exposed, which is that the pmap structs aren't identical such >> that the pm_stats are at different locations, and libkvm ends up >> reading with the Book-E pmap, getting different stats than expected >> for >> AIM. This patch fixes that, bumping version to account for this ABI >> change. >> >> - Justin > > > From owner-freebsd-current@freebsd.org Sun Nov 20 04:22:12 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46DC4C484BB for ; Sun, 20 Nov 2016 04:22:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-36.reflexion.net [208.70.210.36]) (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 0887A18E0 for ; Sun, 20 Nov 2016 04:22:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14278 invoked from network); 20 Nov 2016 04:21:56 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 20 Nov 2016 04:21:56 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Sat, 19 Nov 2016 23:22:20 -0500 (EST) Received: (qmail 28663 invoked from network); 20 Nov 2016 04:22:20 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 Nov 2016 04:22:20 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 5B3BBEC9142; Sat, 19 Nov 2016 20:22:09 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: svn commit: r308817 - head/sys/powerpc/include [Still have pmap_t and struct pmap ppowerpc64 problems as of -r308860] From: Mark Millard In-Reply-To: Date: Sat, 19 Nov 2016 20:22:08 -0800 Cc: svn-src-head@freebsd.org, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <9CDAF14D-2953-4914-BD3D-C91F591DE7DD@dsl-only.net> References: <39962D4C-29BA-4AA4-B77D-2344A68FDB54@dsl-only.net> <53258F35-C86E-4DE0-BDF0-5C139E68356D@dsl-only.net> <20161119204715.79632a66@zhabar.knownspace> <3D338DB4-9FAF-46A8-96FF-4F77B01871E2@dsl-only.net> <1EC92166-7DF3-42DC-9AAD-AED1BA9D5CC1@dsl-only.net> <59613CEF-BA2D-4010-996C-6FB8F9D126C6@dsl-only.net> To: Justin Hibbits X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 04:22:12 -0000 On 2016-Nov-16, at 8:33 PM, Justin Hibbits wrote: > *sigh* okay, thanks. I just tested, and vm/vm_page.h, and vm/vm.h can = both be removed from memstat_uma.c for it to compile. I'm kicking off a = buildworld myself now, too, and hope to have it ready to commit tomorrow = (takes a couple hours to buildworld on my G5). >=20 > - Justin That will not be the only potential place: umastat.c in = tools/tools/umastat/ also has a include of vm/vm_page.h: > # find /usr/src/ -name .svn -prune -o -name sys -prune -o -name man = -prune -o -exec grep "vm_page[.]h" {} \; -print | more > #include > /usr/src/lib/libmemstat/memstat_uma.c > #define LIBMEMSTAT /* Cause vm_page.h not to include opt_vmpage.h = */ > #include > /usr/src/tools/tools/umastat/umastat.c =3D=3D=3D Mark Millard markmi at dsl-only.net On Nov 19, 2016, at 9:47 PM, Mark Millard wrote: > [Top post of bad news.] >=20 > With the patch I get a different incomplete type used in libmemstat: >=20 > struct md_page >=20 > --- all_subdir_lib/libmemstat --- > In file included from /usr/src/lib/libmemstat/memstat_uma.c:34:0: > /usr/src/sys/vm/vm_page.h:144:17: error: field 'md' has incomplete = type > struct md_page md; /* machine dependent stuff */ > ^ > *** [memstat_uma.o] Error code 1 >=20 > make[5]: stopped in /usr/src/lib/libmemstat >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Nov-19, at 7:42 PM, Mark Millard = wrote: >=20 >> On 2016-Nov-19, at 7:36 PM, Mark Millard = wrote: >>=20 >>> On 2016-Nov-19, at 7:32 PM, Justin Hibbits = wrote: >>>=20 >>>> Sorry, I generated the diff from a different tree that wasn't = synced to head (had the same change in both trees originally). If that = is the only problem, you can ignore it and try the rest. I can generate = another diff later too. >>>> - Justin >>>=20 >>> Yep: I manually did the move of the pm_stats line and am building. >>=20 >> If it builds and I install it on a PowerMac G5 and it boots, what do = I >> do to test if pm_stats and pm_mtx seems to be working well/right for >> the out of kernel code? Do you know of a reasonable test? >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 > On Nov 19, 2016 21:27, "Mark Millard" wrote: >> [Top post about patch issues.] >>=20 >> Looking at the patch it seems to be designed for when #else was in = use: >>=20 >>> -#else >>> +#elif defined(BOOKE) >>=20 >> but -r308817 already has the 2nd line (BOOKE). Your patch shows: >>=20 >>> Index: sys/powerpc/include/pmap.h >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- sys/powerpc/include/pmap.h (revision 308718) >>> +++ sys/powerpc/include/pmap.h (working copy) >>=20 >> So it looks like you started from before -r308817 . >>=20 >> Trying it (I'm at -r308860): >>=20 >>> Patching file sys/powerpc/include/pmap.h using Plan A... >>> Hunk #1 succeeded at 74. >>> Hunk #2 succeeded at 84. >>> Hunk #3 succeeded at 132. >>> Hunk #4 succeeded at 145. >>> Hunk #5 failed at 180. >>> Hunk #6 succeeded at 194. >>> Hunk #7 succeeded at 210. >>> 1 out of 7 hunks failed--saving rejects to = sys/powerpc/include/pmap.h.rej >>=20 >>> # more sys/powerpc/include/pmap.h.rej >>> @@ -179,13 +180,13 @@ >>> struct slb **slb_alloc_user_cache(void); >>> void slb_free_user_cache(struct slb **); >>>=20 >>> -#else >>> +#elif defined(BOOKE) >>>=20 >>> struct pmap { >>> + struct pmap_statistics pm_stats; /* pmap statistics = */ >>> struct mtx pm_mtx; /* pmap mutex */ >>> tlbtid_t pm_tid[MAXCPU]; /* TID to identify this = pmap entries in TLB */ >>> cpuset_t pm_active; /* active on cpus */ >>> - struct pmap_statistics pm_stats; /* pmap statistics = */ >>>=20 >>> /* Page table directory, array of pointers to page tables. */ >>> pte_t *pm_pdir[PDIR_NENTRIES]; >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> On 2016-Nov-19, at 7:00 PM, Mark Millard = wrote: >>=20 >> It may take a little bit but I'll try the patch. >>=20 >> It looks like sys/powerpc/include/pmap.h from -r176700 from = 2088-Mar-3 >> is when the BOOKE/E500 split started with the preprocessor use of AIM >> and #else . This predates PowerMac G5 support. >>=20 >> This is definitely not new for the general structure on the powerpc >> side of things. Any place that did not have the AIM vs. not status >> available was subject to problems of possibly mismatched definitions. >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> On 2016-Nov-19, at 6:47 PM, Justin Hibbits = wrote: >>=20 >> On Sat, 19 Nov 2016 18:36:39 -0800 >> Mark Millard wrote: >>=20 >>> [Quick top post I'm afraid.] >>>=20 >>> I think that I figured out why there is a problem even earlier >>> --that just did not stop the compiles. >>>=20 >>> lib/libutil/kinfo_getallproc.c is built here as part of buildworld >>> (stage 4.2 "building libraries" instead of buildkernel. It does not >>> have the KERNCONF's AIM vs. BOOKE vs. . . . definitions vs. lack of >>> them). >>>=20 >>> So if it includes machine/pmap.h that binds to >>> sys/powerpc/include/pmap.h which has the structure. . . >>>=20 >>> . . . >>> #if defined(AIM) >>> . . . (definitions here) >>> #elif defined(BOOKE) >>> . . . (definitions here) >>> #endif >>> . . . >>>=20 >>> it gets no definition now. >>>=20 >>> With the older: >>>=20 >>> . . . >>> #if defined(AIM) >>> . . . (definitions here) >>> #else >>> . . . (definitions here) >>> #endif >>> . . . >>>=20 >>> It got a definition, just not necessarily the right one. >>>=20 >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net >>=20 >> Can you try the attached patch? There was a subtle ABI issue that >> r308817 exposed, which is that the pmap structs aren't identical such >> that the pm_stats are at different locations, and libkvm ends up >> reading with the Book-E pmap, getting different stats than expected = for >> AIM. This patch fixes that, bumping version to account for this ABI >> change. >>=20 >> - Justin >=20 >=20 >=20 From owner-freebsd-current@freebsd.org Sun Nov 20 04:29:24 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB005C485EC; Sun, 20 Nov 2016 04:29:24 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6EE521A89; Sun, 20 Nov 2016 04:29:24 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-io0-x244.google.com with SMTP id n13so2666942ioe.1; Sat, 19 Nov 2016 20:29:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:cc:message-id:from:to:in-reply-to:content-transfer-encoding :mime-version:subject:date:references; bh=UDdf3YkqEFON3x4jEaBjk5xBxdMUyE8zlWxw7ZtcEgI=; b=eYp+VFtNfln0bZKxl2qRoI3lGWAiHtURTX8pfAiFZW53NYAxd5mIcF/pyiLgkSJSyk eZAWWBO+vY+MOL3fjY1pTn2BGhX5lvk3S3Qpwg7gXoDKDu4oE5n8DlTpol5864A1Wlb6 ntcVwGEOg7L52Bzyk4cMtcXelx4dRmFr+lXy5tDLc3PGK6QNenPI3PGayjeG4ZPq2hzY rI5maG+OL+Eljc4Gb4lUrTzm01KaqPtEldmzXlM4IHRr8OeG93XHM9M9AGalEiibOFAe gtaSOPWKap4ek+UcmkEfF/J8FL2WaL2DNJbixixLP6RCQ8TZlWwmc2VAH6r/9VNq4Y/L RKTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:cc:message-id:from:to:in-reply-to :content-transfer-encoding:mime-version:subject:date:references; bh=UDdf3YkqEFON3x4jEaBjk5xBxdMUyE8zlWxw7ZtcEgI=; b=lPzh/slkNlo3pfKdRxQBqlaZ0CAwvDutwrR9MTPVe4oHm0sdCNjhVlrrObgkSsTAcA bzaa7gbwjY4jeZ4IZVfF4uGJIZbIDbnwuosQJslx1RGd9bPc9NRO2hIQCh1VeOxGkd5O lQqKG9qsAK3BnsXXYZQ44Yel5MSlAQXCB2tleChC+28X1ZTQXG6XVAps2cFh97P0cJqp qacL6Y4PTkm9K0uXF5oOtA43/kGUzmOVpqIwm0urrjiPaN+a78JH6fNXInZ+sts0Dv5K 0BPTvhzBKTksAwbG08Bca/tq2ZqbORkWeH7pgin3s1cSta+0b8VqIZNkw7UYKwiVCR6q LY0Q== X-Gm-Message-State: AKaTC018o9HpkCfCojVSUSyTnv+lUIxBHynmOpWcXyyrVcSIs/MDh5e0CYbIS9RDcBZOow== X-Received: by 10.107.9.82 with SMTP id j79mr5664802ioi.197.1479616163552; Sat, 19 Nov 2016 20:29:23 -0800 (PST) Received: from blackstar.knownspace (50-80-150-234.client.mchsi.com. [50.80.150.234]) by smtp.gmail.com with ESMTPSA id i75sm3890736itf.10.2016.11.19.20.29.21 (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 19 Nov 2016 20:29:22 -0800 (PST) Sender: Justin Hibbits Cc: svn-src-head@freebsd.org, FreeBSD Current Message-Id: From: Justin Hibbits To: Mark Millard In-Reply-To: <9CDAF14D-2953-4914-BD3D-C91F591DE7DD@dsl-only.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: svn commit: r308817 - head/sys/powerpc/include [Still have pmap_t and struct pmap ppowerpc64 problems as of -r308860] Date: Sat, 19 Nov 2016 22:29:19 -0600 References: <39962D4C-29BA-4AA4-B77D-2344A68FDB54@dsl-only.net> <53258F35-C86E-4DE0-BDF0-5C139E68356D@dsl-only.net> <20161119204715.79632a66@zhabar.knownspace> <3D338DB4-9FAF-46A8-96FF-4F77B01871E2@dsl-only.net> <1EC92166-7DF3-42DC-9AAD-AED1BA9D5CC1@dsl-only.net> <59613CEF-BA2D-4010-996C-6FB8F9D126C6@dsl-only.net> <9CDAF14D-2953-4914-BD3D-C91F591DE7DD@dsl-only.net> X-Mailer: Apple Mail (2.936) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 04:29:24 -0000 umastat doesn't even build right now anyway. I just tried: [chmeee@zhabar:pts/29]:~...tools/umastat> make echo umastat.full: /usr/lib/libc.a /usr/lib/libkvm.a >> .depend Warning: Object directory not changed from original /home/chmeee/ freebsd/head/tools/tools/umastat cc -O2 -pipe -g -MD -MF.depend.umastat.o -MTumastat.o -std=gnu99 - fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes - Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c umastat.c - o umastat.o umastat.c:136: error: 'UMA_ZONE_REFCNT' undeclared here (not in a function) *** Error code 1 - Justin On Nov 19, 2016, at 10:22 PM, Mark Millard wrote: > On 2016-Nov-16, at 8:33 PM, Justin Hibbits > wrote: > >> *sigh* okay, thanks. I just tested, and vm/vm_page.h, and vm/vm.h >> can both be removed from memstat_uma.c for it to compile. I'm >> kicking off a buildworld myself now, too, and hope to have it ready >> to commit tomorrow (takes a couple hours to buildworld on my G5). >> >> - Justin > > That will not be the only potential place: umastat.c in tools/tools/ > umastat/ > also has a include of vm/vm_page.h: > >> # find /usr/src/ -name .svn -prune -o -name sys -prune -o -name man >> -prune -o -exec grep "vm_page[.]h" {} \; -print | more >> #include >> /usr/src/lib/libmemstat/memstat_uma.c >> #define LIBMEMSTAT /* Cause vm_page.h not to include >> opt_vmpage.h */ >> #include >> /usr/src/tools/tools/umastat/umastat.c > > > === > Mark Millard > markmi at dsl-only.net > > On Nov 19, 2016, at 9:47 PM, Mark Millard wrote: > >> [Top post of bad news.] >> >> With the patch I get a different incomplete type used in libmemstat: >> >> struct md_page >> >> --- all_subdir_lib/libmemstat --- >> In file included from /usr/src/lib/libmemstat/memstat_uma.c:34:0: >> /usr/src/sys/vm/vm_page.h:144:17: error: field 'md' has incomplete >> type >> struct md_page md; /* machine dependent stuff */ >> ^ >> *** [memstat_uma.o] Error code 1 >> >> make[5]: stopped in /usr/src/lib/libmemstat >> >> >> === >> Mark Millard >> markmi at dsl-only.net >> >> On 2016-Nov-19, at 7:42 PM, Mark Millard >> wrote: >> >>> On 2016-Nov-19, at 7:36 PM, Mark Millard >>> wrote: >>> >>>> On 2016-Nov-19, at 7:32 PM, Justin Hibbits >>> freebsd.org> wrote: >>>> >>>>> Sorry, I generated the diff from a different tree that wasn't >>>>> synced to head (had the same change in both trees originally). >>>>> If that is the only problem, you can ignore it and try the rest. >>>>> I can generate another diff later too. >>>>> - Justin >>>> >>>> Yep: I manually did the move of the pm_stats line and am building. >>> >>> If it builds and I install it on a PowerMac G5 and it boots, what >>> do I >>> do to test if pm_stats and pm_mtx seems to be working well/right for >>> the out of kernel code? Do you know of a reasonable test? >>> >>> === >>> Mark Millard >>> markmi at dsl-only.net >>> >> On Nov 19, 2016 21:27, "Mark Millard" wrote: >>> [Top post about patch issues.] >>> >>> Looking at the patch it seems to be designed for when #else was in >>> use: >>> >>>> -#else >>>> +#elif defined(BOOKE) >>> >>> but -r308817 already has the 2nd line (BOOKE). Your patch shows: >>> >>>> Index: sys/powerpc/include/pmap.h >>>> =================================================================== >>>> --- sys/powerpc/include/pmap.h (revision 308718) >>>> +++ sys/powerpc/include/pmap.h (working copy) >>> >>> So it looks like you started from before -r308817 . >>> >>> Trying it (I'm at -r308860): >>> >>>> Patching file sys/powerpc/include/pmap.h using Plan A... >>>> Hunk #1 succeeded at 74. >>>> Hunk #2 succeeded at 84. >>>> Hunk #3 succeeded at 132. >>>> Hunk #4 succeeded at 145. >>>> Hunk #5 failed at 180. >>>> Hunk #6 succeeded at 194. >>>> Hunk #7 succeeded at 210. >>>> 1 out of 7 hunks failed--saving rejects to sys/powerpc/include/ >>>> pmap.h.rej >>> >>>> # more sys/powerpc/include/pmap.h.rej >>>> @@ -179,13 +180,13 @@ >>>> struct slb **slb_alloc_user_cache(void); >>>> void slb_free_user_cache(struct slb **); >>>> >>>> -#else >>>> +#elif defined(BOOKE) >>>> >>>> struct pmap { >>>> + struct pmap_statistics pm_stats; /* pmap >>>> statistics */ >>>> struct mtx pm_mtx; /* pmap mutex */ >>>> tlbtid_t pm_tid[MAXCPU]; /* TID to identify >>>> this pmap entries in TLB */ >>>> cpuset_t pm_active; /* active on cpus */ >>>> - struct pmap_statistics pm_stats; /* pmap >>>> statistics */ >>>> >>>> /* Page table directory, array of pointers to page tables. */ >>>> pte_t *pm_pdir[PDIR_NENTRIES]; >>> >>> >>> === >>> Mark Millard >>> markmi at dsl-only.net >>> >>> On 2016-Nov-19, at 7:00 PM, Mark Millard >>> wrote: >>> >>> It may take a little bit but I'll try the patch. >>> >>> It looks like sys/powerpc/include/pmap.h from -r176700 from 2088- >>> Mar-3 >>> is when the BOOKE/E500 split started with the preprocessor use of >>> AIM >>> and #else . This predates PowerMac G5 support. >>> >>> This is definitely not new for the general structure on the powerpc >>> side of things. Any place that did not have the AIM vs. not status >>> available was subject to problems of possibly mismatched >>> definitions. >>> >>> === >>> Mark Millard >>> markmi at dsl-only.net >>> >>> On 2016-Nov-19, at 6:47 PM, Justin Hibbits >> freebsd.org> wrote: >>> >>> On Sat, 19 Nov 2016 18:36:39 -0800 >>> Mark Millard wrote: >>> >>>> [Quick top post I'm afraid.] >>>> >>>> I think that I figured out why there is a problem even earlier >>>> --that just did not stop the compiles. >>>> >>>> lib/libutil/kinfo_getallproc.c is built here as part of buildworld >>>> (stage 4.2 "building libraries" instead of buildkernel. It does not >>>> have the KERNCONF's AIM vs. BOOKE vs. . . . definitions vs. lack of >>>> them). >>>> >>>> So if it includes machine/pmap.h that binds to >>>> sys/powerpc/include/pmap.h which has the structure. . . >>>> >>>> . . . >>>> #if defined(AIM) >>>> . . . (definitions here) >>>> #elif defined(BOOKE) >>>> . . . (definitions here) >>>> #endif >>>> . . . >>>> >>>> it gets no definition now. >>>> >>>> With the older: >>>> >>>> . . . >>>> #if defined(AIM) >>>> . . . (definitions here) >>>> #else >>>> . . . (definitions here) >>>> #endif >>>> . . . >>>> >>>> It got a definition, just not necessarily the right one. >>>> >>>> >>>> === >>>> Mark Millard >>>> markmi at dsl-only.net >>> >>> Can you try the attached patch? There was a subtle ABI issue that >>> r308817 exposed, which is that the pmap structs aren't identical >>> such >>> that the pm_stats are at different locations, and libkvm ends up >>> reading with the Book-E pmap, getting different stats than >>> expected for >>> AIM. This patch fixes that, bumping version to account for this ABI >>> change. >>> >>> - Justin >> >> >> > > From owner-freebsd-current@freebsd.org Sun Nov 20 06:12:33 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC34AC4A060; Sun, 20 Nov 2016 06:12:33 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8DEE21C0F; Sun, 20 Nov 2016 06:12:33 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-it0-x244.google.com with SMTP id o1so11217819ito.1; Sat, 19 Nov 2016 22:12:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:cc:message-id:from:to:in-reply-to:content-transfer-encoding :mime-version:subject:date:references; bh=hDzG7Q5nGYFYHxDze8EHgQtsSAiZphx+dWvSGO3wM7U=; b=dlISsmsC+Ue2O32koLqMVVbnIXhzZO0n3SGOKfqGdejS4IZiV/k3g9OReDHh9fZEg4 2ulvqn2ktYpCvPNIeEZ1Ke/ZNun8QpL2pq5o19OI72q9j+nWYHmG/GARbLh0liXBCgNW zVzTR4X+1Lo/ahYNd+a+K3rwY3utCeAXT0VLiWGWFXmsL9yhpAp2GU2c7SJvjrdwsr/F cY5pQRjgMTVEI28KTisjhK0CzcrLoCc9T2v6z2m8FuKvJhXkTEWlIIiOGOhunztop/mc evxOPjOZG9GNS2iuJjisbuUcVua3V3ogucQbHXUdmHCwVd8xjynItaI9ctksdoaRRXDz O13g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:cc:message-id:from:to:in-reply-to :content-transfer-encoding:mime-version:subject:date:references; bh=hDzG7Q5nGYFYHxDze8EHgQtsSAiZphx+dWvSGO3wM7U=; b=jXZB+XxiIh6zcCIfb3y9IhvgOPrVW2cgSX76ZOIS1BiXM/iVEd15TKHBo5ZoXDu+Hj CN0aS1jQC8ilEHDq5hViPE6xgH0Z+Rs77DkYf+iOeWaf+4QmG55hkmPN3a4JPT0HcKEB y5SS73rtqNjiv06P35Se5gqXaTggi8S3wIMTOCTR/cRPaU6OP/ikEHNoy0wj9Sq47YgT BRnEukaeFZXYGhKjiPdIT+PRwysqhj3xM86HkE62pfHSOim0OB7KFnTSDWaejuO3rp3r zod7+0KNZqMUz8MSrdfluRoNayA5m9x0+2tbLEQOEfv+EcCsrSw4cUF9sVUQYnnJzaaS XFSg== X-Gm-Message-State: AKaTC02H7J6/pZvgnUB8v3EaG1PFkCMhmc+FBIE+xdjAaJJdboI19zk5qK/M5vpzYD+JhQ== X-Received: by 10.36.43.193 with SMTP id h184mr4803124ita.29.1479622352655; Sat, 19 Nov 2016 22:12:32 -0800 (PST) Received: from blackstar.knownspace (50-80-150-234.client.mchsi.com. [50.80.150.234]) by smtp.gmail.com with ESMTPSA id x190sm4006268ite.14.2016.11.19.22.12.31 (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 19 Nov 2016 22:12:31 -0800 (PST) Sender: Justin Hibbits Cc: svn-src-head@freebsd.org, FreeBSD Current Message-Id: From: Justin Hibbits To: Mark Millard In-Reply-To: <9CDAF14D-2953-4914-BD3D-C91F591DE7DD@dsl-only.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: svn commit: r308817 - head/sys/powerpc/include [Still have pmap_t and struct pmap ppowerpc64 problems as of -r308860] Date: Sun, 20 Nov 2016 00:12:30 -0600 References: <39962D4C-29BA-4AA4-B77D-2344A68FDB54@dsl-only.net> <53258F35-C86E-4DE0-BDF0-5C139E68356D@dsl-only.net> <20161119204715.79632a66@zhabar.knownspace> <3D338DB4-9FAF-46A8-96FF-4F77B01871E2@dsl-only.net> <1EC92166-7DF3-42DC-9AAD-AED1BA9D5CC1@dsl-only.net> <59613CEF-BA2D-4010-996C-6FB8F9D126C6@dsl-only.net> <9CDAF14D-2953-4914-BD3D-C91F591DE7DD@dsl-only.net> X-Mailer: Apple Mail (2.936) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 06:12:33 -0000 My buildworld completed successfully, so it's been fixed in r308873/ r308874. Thanks for your testing. I often build just kernel, so wouldn't have seen the fallout until it was far too late. - Justin On Nov 19, 2016, at 10:22 PM, Mark Millard wrote: > On 2016-Nov-16, at 8:33 PM, Justin Hibbits > wrote: > >> *sigh* okay, thanks. I just tested, and vm/vm_page.h, and vm/vm.h >> can both be removed from memstat_uma.c for it to compile. I'm >> kicking off a buildworld myself now, too, and hope to have it ready >> to commit tomorrow (takes a couple hours to buildworld on my G5). >> >> - Justin > > That will not be the only potential place: umastat.c in tools/tools/ > umastat/ > also has a include of vm/vm_page.h: > >> # find /usr/src/ -name .svn -prune -o -name sys -prune -o -name man >> -prune -o -exec grep "vm_page[.]h" {} \; -print | more >> #include >> /usr/src/lib/libmemstat/memstat_uma.c >> #define LIBMEMSTAT /* Cause vm_page.h not to include >> opt_vmpage.h */ >> #include >> /usr/src/tools/tools/umastat/umastat.c > > > === > Mark Millard > markmi at dsl-only.net > > On Nov 19, 2016, at 9:47 PM, Mark Millard wrote: > >> [Top post of bad news.] >> >> With the patch I get a different incomplete type used in libmemstat: >> >> struct md_page >> >> --- all_subdir_lib/libmemstat --- >> In file included from /usr/src/lib/libmemstat/memstat_uma.c:34:0: >> /usr/src/sys/vm/vm_page.h:144:17: error: field 'md' has incomplete >> type >> struct md_page md; /* machine dependent stuff */ >> ^ >> *** [memstat_uma.o] Error code 1 >> >> make[5]: stopped in /usr/src/lib/libmemstat >> >> >> === >> Mark Millard >> markmi at dsl-only.net >> >> On 2016-Nov-19, at 7:42 PM, Mark Millard >> wrote: >> >>> On 2016-Nov-19, at 7:36 PM, Mark Millard >>> wrote: >>> >>>> On 2016-Nov-19, at 7:32 PM, Justin Hibbits >>> freebsd.org> wrote: >>>> >>>>> Sorry, I generated the diff from a different tree that wasn't >>>>> synced to head (had the same change in both trees originally). >>>>> If that is the only problem, you can ignore it and try the rest. >>>>> I can generate another diff later too. >>>>> - Justin >>>> >>>> Yep: I manually did the move of the pm_stats line and am building. >>> >>> If it builds and I install it on a PowerMac G5 and it boots, what >>> do I >>> do to test if pm_stats and pm_mtx seems to be working well/right for >>> the out of kernel code? Do you know of a reasonable test? >>> >>> === >>> Mark Millard >>> markmi at dsl-only.net >>> >> On Nov 19, 2016 21:27, "Mark Millard" wrote: >>> [Top post about patch issues.] >>> >>> Looking at the patch it seems to be designed for when #else was in >>> use: >>> >>>> -#else >>>> +#elif defined(BOOKE) >>> >>> but -r308817 already has the 2nd line (BOOKE). Your patch shows: >>> >>>> Index: sys/powerpc/include/pmap.h >>>> =================================================================== >>>> --- sys/powerpc/include/pmap.h (revision 308718) >>>> +++ sys/powerpc/include/pmap.h (working copy) >>> >>> So it looks like you started from before -r308817 . >>> >>> Trying it (I'm at -r308860): >>> >>>> Patching file sys/powerpc/include/pmap.h using Plan A... >>>> Hunk #1 succeeded at 74. >>>> Hunk #2 succeeded at 84. >>>> Hunk #3 succeeded at 132. >>>> Hunk #4 succeeded at 145. >>>> Hunk #5 failed at 180. >>>> Hunk #6 succeeded at 194. >>>> Hunk #7 succeeded at 210. >>>> 1 out of 7 hunks failed--saving rejects to sys/powerpc/include/ >>>> pmap.h.rej >>> >>>> # more sys/powerpc/include/pmap.h.rej >>>> @@ -179,13 +180,13 @@ >>>> struct slb **slb_alloc_user_cache(void); >>>> void slb_free_user_cache(struct slb **); >>>> >>>> -#else >>>> +#elif defined(BOOKE) >>>> >>>> struct pmap { >>>> + struct pmap_statistics pm_stats; /* pmap >>>> statistics */ >>>> struct mtx pm_mtx; /* pmap mutex */ >>>> tlbtid_t pm_tid[MAXCPU]; /* TID to identify >>>> this pmap entries in TLB */ >>>> cpuset_t pm_active; /* active on cpus */ >>>> - struct pmap_statistics pm_stats; /* pmap >>>> statistics */ >>>> >>>> /* Page table directory, array of pointers to page tables. */ >>>> pte_t *pm_pdir[PDIR_NENTRIES]; >>> >>> >>> === >>> Mark Millard >>> markmi at dsl-only.net >>> >>> On 2016-Nov-19, at 7:00 PM, Mark Millard >>> wrote: >>> >>> It may take a little bit but I'll try the patch. >>> >>> It looks like sys/powerpc/include/pmap.h from -r176700 from 2088- >>> Mar-3 >>> is when the BOOKE/E500 split started with the preprocessor use of >>> AIM >>> and #else . This predates PowerMac G5 support. >>> >>> This is definitely not new for the general structure on the powerpc >>> side of things. Any place that did not have the AIM vs. not status >>> available was subject to problems of possibly mismatched >>> definitions. >>> >>> === >>> Mark Millard >>> markmi at dsl-only.net >>> >>> On 2016-Nov-19, at 6:47 PM, Justin Hibbits >> freebsd.org> wrote: >>> >>> On Sat, 19 Nov 2016 18:36:39 -0800 >>> Mark Millard wrote: >>> >>>> [Quick top post I'm afraid.] >>>> >>>> I think that I figured out why there is a problem even earlier >>>> --that just did not stop the compiles. >>>> >>>> lib/libutil/kinfo_getallproc.c is built here as part of buildworld >>>> (stage 4.2 "building libraries" instead of buildkernel. It does not >>>> have the KERNCONF's AIM vs. BOOKE vs. . . . definitions vs. lack of >>>> them). >>>> >>>> So if it includes machine/pmap.h that binds to >>>> sys/powerpc/include/pmap.h which has the structure. . . >>>> >>>> . . . >>>> #if defined(AIM) >>>> . . . (definitions here) >>>> #elif defined(BOOKE) >>>> . . . (definitions here) >>>> #endif >>>> . . . >>>> >>>> it gets no definition now. >>>> >>>> With the older: >>>> >>>> . . . >>>> #if defined(AIM) >>>> . . . (definitions here) >>>> #else >>>> . . . (definitions here) >>>> #endif >>>> . . . >>>> >>>> It got a definition, just not necessarily the right one. >>>> >>>> >>>> === >>>> Mark Millard >>>> markmi at dsl-only.net >>> >>> Can you try the attached patch? There was a subtle ABI issue that >>> r308817 exposed, which is that the pmap structs aren't identical >>> such >>> that the pm_stats are at different locations, and libkvm ends up >>> reading with the Book-E pmap, getting different stats than >>> expected for >>> AIM. This patch fixes that, bumping version to account for this ABI >>> change. >>> >>> - Justin >> >> >> > > From owner-freebsd-current@freebsd.org Sun Nov 20 07:44:01 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 21DFAC4B588 for ; Sun, 20 Nov 2016 07:44:01 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E91F6106E; Sun, 20 Nov 2016 07:44:00 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by mail-pf0-x241.google.com with SMTP id i88so16179800pfk.2; Sat, 19 Nov 2016 23:44:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-disposition:in-reply-to:user-agent; bh=LSsf/2ckLwE7srLGB9kppuHB9TKjHbUmW103JWE2D5Q=; b=wxZI8HMrXA9JUiKp/HTBy8sZfZEjqARTBf1SI+vtRzN1BtdYaaMs+6BgmbWymtOeKZ Bf/UMyXErVO/oDjoC06440JmdkbgSfDX+4G4KfDGA3GYqb9MD+5hey57/4Nx3yWttCVw hQZ26PKlnk6fzJD6V6QzJX3oBJAjPgu6YkyMMXCRQgzrj+HyqFpTZTM6VJkL5EJ2Izas GrKX8NIdW22EY9K8bly4YxdDvUDDGozaXh46HYuP30GH/UDsMBAXM6xA6nw3Fl+L4k1m A7KckuPxeXK4KtJjZvY4d4fxYN2by7rhJswQxUnbqreslhyuFqImmKDfniq5ZYXfM47c jmGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=LSsf/2ckLwE7srLGB9kppuHB9TKjHbUmW103JWE2D5Q=; b=VJkXI1bIgifLqaLyv1W72RB48A7qLkeEhpzoILOQ3Qspivl4blM7YcbJKVanAjuxzp xxp0MPk4TcdF08IgaMM60A9ar5r268fSmYTO7Kqk+qx/Zbzfj+2MHgl+COsyqLJQ4Y9m qhyCMh6bhs4VXPUG0/ZbpCVselVyxFqIGRsiu8EjGT5KlLpyax0jbzp+OqhHCVgoY0mR B4jvZM8dWrWNtNRawWyVVEF7qCGOeZUfek2C5CH/fkNb1YPCbOObblO5y/B1iAcskn6N 48Y+kFyw7nGvNcIGxw5FJZWpmXHq4NUI1rlQdNF8oAfA/CgGG7at5grZVpx7vZVaF+Oa b2Uw== X-Gm-Message-State: AKaTC00WTU5NY+3/qkMxM6bP4NMX6a47Uck917i1lXqZTyIL0KPrOAGJgVcG1lVrRUePig== X-Received: by 10.99.170.79 with SMTP id x15mr18204568pgo.14.1479627840425; Sat, 19 Nov 2016 23:44:00 -0800 (PST) Received: from localhost ([221.148.3.207]) by smtp.gmail.com with ESMTPSA id i11sm10859223pgn.17.2016.11.19.23.43.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Nov 2016 23:43:58 -0800 (PST) From: YongHyeon PYUN X-Google-Original-From: "YongHyeon PYUN" Received: by localhost (sSMTP sendmail emulation); Sun, 20 Nov 2016 16:43:53 +0900 Date: Sun, 20 Nov 2016 16:43:52 +0900 To: "O. Hartmann" Cc: FreeBSD CURRENT , gnn@FreeBSD.org, "Andrey V. Elsukov" , glebius@FreeBSD.org, melifaro@FreeBSD.org Subject: Re: CURRENT: re(4) crashing system Message-ID: <20161120074351.GA1090@michelle.fasterthan.co.kr> Reply-To: pyunyh@gmail.com References: <20161024051359.GA1185@michelle.fasterthan.co.kr> <20161024140337.47af924e@freyja.zeit4.iv.bundesimmobilien.de> <20161025020538.GA1238@michelle.fasterthan.co.kr> <20161025070338.76ad6711@hermann> <20161027010004.GA1215@michelle.fasterthan.co.kr> <20161028212113.5c4a2ca2@hermann> <20161031021222.GA1252@michelle.fasterthan.co.kr> <20161106132036.06add6ca@hermann> <20161107021623.GA1557@michelle.fasterthan.co.kr> <20161119194424.6335338a@thor.walstatt.dynvpn.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161119194424.6335338a@thor.walstatt.dynvpn.de> User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 07:44:01 -0000 On Sat, Nov 19, 2016 at 07:44:35PM +0100, O. Hartmann wrote: > Am Mon, 7 Nov 2016 11:16:23 +0900 > YongHyeon PYUN schrieb: > > > On Sun, Nov 06, 2016 at 01:20:36PM +0100, Hartmann, O. wrote: > > > On Mon, 31 Oct 2016 11:12:22 +0900 > > > YongHyeon PYUN wrote: > > > > > > > On Fri, Oct 28, 2016 at 09:21:13PM +0200, Hartmann, O. wrote: > > > > > On Thu, 27 Oct 2016 10:00:04 +0900 > > > > > YongHyeon PYUN wrote: > > > > > > > > > > > On Tue, Oct 25, 2016 at 07:03:38AM +0200, Hartmann, O. wrote: > > > > > > > On Tue, 25 Oct 2016 11:05:38 +0900 > > > > > > > YongHyeon PYUN wrote: > > > > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > I'm not sure but it's likely the issue is related with > > > > > > > > EEE/Green Ethernet handling. EEE is negotiated feature with > > > > > > > > link partner. If you directly connect your laptop to non-EEE > > > > > > > > capable link partner like other re(4) box without switches > > > > > > > > you may be able to tell whether the issue is EEE/Green > > > > > > > > Ethernet related one or not. > > > > > > > > > > > > > > Me either since when I discovered a problem the first time with > > > > > > > CURRENT, that was the Friday before last week's Friday, there > > > > > > > was a unlucky coicidence: I got the new switch, FreeBSD > > > > > > > introduced a serious bug and I changed the NICs. > > > > > > > > > > > > > > The laptop, the last in the row of re(4) equipted systems on > > > > > > > which I use the Realtek NIC, does well now with Green IT > > > > > > > technology, but crashes on plugging/unplugging - not on each > > > > > > > event, but at least in one of ten. > > > > > > > > > > > > Hmm, it seems you know how to trigger the issue. When you unplug > > > > > > UTP cable was there active network traffic on re(4) device? > > > > > > It would be helpful to know which event triggers the crash(e.g. > > > > > > unplugging or plugging). And would you show me backtrace of > > > > > > panic? > > > > > > > I guess the Green IT issue is more a unlucky guess of mine and > > > > > > > went hand in hand with the problem I face with CURRENT right > > > > > > > now on some older, Non UEFI machines. > > > > > > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > [...] > > > > > > > > > > > > > > As requested the informations about re0 and rgephy0 on the > > > > > > > laptop (Lenovo E540) > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > rgephy0: PHY 1 on miibus0 > > > > > > > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, > > > > > > > 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, > > > > > > > 1000baseT-FDX-master, 1000baseT-FDX-flow, > > > > > > > 1000baseT-FDX-flow-master, auto, auto-flow > > > > > > > > > > > > > > re0: > > > > > > > port 0x3000-0x30ff mem > > > > > > > 0xf0d04000-0xf0d04fff,0xf0d00000-0xf0d03fff at device 0.0 on > > > > > > > pci2 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip > > > > > > > rev. 0x50800000 re0: MAC rev. 0x00100000 > > > > > > > > > > > > This looks like 8168GU controller. > > > > > > > > > > > > [...] > > > > > > > > > > > > > I use options netmap in kernel config, but the problem is also > > > > > > > present without this option - just for the record. > > > > > > > > > > > > > > > > > > > Yup, netmap(4) has nothing to do with the crash. > > > > > > > > > > > > Thanks. > > > > > > > > > > Attached, you'll find the backtrace of the crash. This time it was > > > > > really easy - just one pull of the LAN cabling - and we are > > > > > happy :-/ > > > > > > > > > > Please let me know if you need something else. I will return to > > > > > normal operations (disabling debugging) due to CURRENT is very > > > > > unstable at the moment on other hosts beyond r307157. > > > > > > > > > > > > > It seems the attachment was stripped. > > > > > > This time I hope I got it right! > > > > > > Attached you'll find the latest CURRENT's backtrace on the provoked > > > crash (plug and unplug). > > > > > > I also saved the kernel and coredump, so if you need me to do further > > > investigations,please let me know. > > > > > > > Thanks a lot for the backtrace. This backtrace is not the one I > > expected and I guess the issue is related with cached route removal > > on interface down. Quick looking over the code didn't reveal the > > cause of crash(I'm not familiar with that part code). Probably > > gnn@ may have better idea what's going on here(CCed). > > > > Thanks. > > In another thread I complained about permanent crashes on several "older" Intel > architectures (IvyBridge and down). It has been revealed, that > > option FLOWTABLE > > in the kernel, which is part of my custom kernels a long time for now, has been > identified as the culprit on those systems. Commenting out that special option solved the > problem! > > Interestingly, also commenting out this option from the kernel config of the laptop in > question of this thread, I wasn't able - as of this writing - to reproduce the crashes, > so it might be that the same issue with FLOWTABLE has been triggered by pluggin and/or > unpluggin the LAN cord. > I'm not sure whether it's triggered by FLOWTABLE yet since it had been there for a log time. I suspected r297225, r301217 which re-added route caching for TCP. The panic you encountered indicates invalid access against destroyed lock which in turn suggests reference counting problem in lltable. I've CCed glebius@ and melifaro@ who are more familiar with routing code than me. > Usually I was able to trigger the coredump after two or three rounds, this time I tried > it over ten times with no effect. > > But on the contrary, the NIC of the laptop doesn't negotiate for 1 GBit/s with my switch, > it remains with 100 MBit/s. The switch is a Netgear GS110TP V2. > This would be a re(4) driver problem. When you see it negotiated 100Mbps after unplugging/plugging, would you try to negotiate with link partner again like below and let me know the result? #ifconfig re0 media auto Does the behavior change if you physically unplug/plug UTP cable on laptop rather than forcing port down/up on the switch? Thanks. From owner-freebsd-current@freebsd.org Sun Nov 20 08:05:20 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3A493C4BD63 for ; Sun, 20 Nov 2016 08:05:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-31.reflexion.net [208.70.210.31]) (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 EFF2C1931 for ; Sun, 20 Nov 2016 08:05:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 16193 invoked from network); 20 Nov 2016 08:05:46 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 20 Nov 2016 08:05:46 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Sun, 20 Nov 2016 03:04:58 -0500 (EST) Received: (qmail 23055 invoked from network); 20 Nov 2016 08:04:58 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 20 Nov 2016 08:04:58 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 87588EC8FDE; Sun, 20 Nov 2016 00:05:12 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: svn commit: r308817 - head/sys/powerpc/include [Still have pmap_t and struct pmap ppowerpc64 problems as of -r308860] From: Mark Millard In-Reply-To: Date: Sun, 20 Nov 2016 00:05:11 -0800 Cc: svn-src-head@freebsd.org, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <469C6A73-67F3-4CB5-90BD-C8092210CDDD@dsl-only.net> References: <39962D4C-29BA-4AA4-B77D-2344A68FDB54@dsl-only.net> <53258F35-C86E-4DE0-BDF0-5C139E68356D@dsl-only.net> <20161119204715.79632a66@zhabar.knownspace> <3D338DB4-9FAF-46A8-96FF-4F77B01871E2@dsl-only.net> <1EC92166-7DF3-42DC-9AAD-AED1BA9D5CC1@dsl-only.net> <59613CEF-BA2D-4010-996C-6FB8F9D126C6@dsl-only.net> <9CDAF14D-2953-4914-BD3D-C91F591DE7DD@dsl-only.net> To: Justin Hibbits X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 08:05:20 -0000 Glad to help. Going in another direction: What of stable/11 ? (And possibly stable/10 = .) Changing the BROOKE kernel ABI in stable/11 is a no-no. Similarly for = AIM. Is there a reason to prefer which context actually works correctly for 11.0 default builds for accessing pm_stats in pmap? My guess is that GENERIC64 and GENERIC for powerpc64 and powerpc should by default work. Needing to have something special for 11.x BOOKE to build correctly in seems less of a problem overall: BOOKE likely has a more tailored 11.x build context anyway and there are no ftp 11.0 snapshots or releases for KERNCONF=3DMPC85XX . TARGET_ARCH=3Dpowerpcspe (KERNCONF=3DMPC85XXSPE) = does not exist until head (12.0-CURRENT) from what I can tell. This might suggest for stable/11 something like: (notation picked for emphasis) #if defined(AIM) || !defined(BOOKE) . . . struct pmap { struct mtx pm_mtx; =20 #ifdef __powerpc64__ struct slbtnode *pm_slb_tree_root; struct slb **pm_slb; int pm_slb_len; #else register_t pm_sr[16]; #endif cpuset_t pm_active; struct pmap *pmap_phys; struct pmap_statistics pm_stats;. . . . . . (the unchanged order above) . . . #elif defined(BOOKE) struct pmap { struct mtx pm_mtx; /* pmap mutex */ tlbtid_t pm_tid[MAXCPU]; /* TID to identify this = pmap entries in TLB */ cpuset_t pm_active; /* active on cpus */ struct pmap_statistics pm_stats; /* pmap statistics */ . . . (the unchanged order above) . . . #endif with some means used for defining BOOKE outside buildkernel for the BOOKE builds, such as for KERNCONF=3DMPC85XX . Then at least GENERIC and GENERIC64 would build correctly for this subject area by default. In particular GENERIC64 actually has no MPC85XX (BOOKE) alternative so far as I know. That makes it too bad that it is always broken for the issue in stable/11 (and in stable/10 ). I choose the above to also cover GENERIC. If only GENERIC64 was to be made to work right by default there are alternatives that involve __powerpc64__ in at least one more place, such as: #if defined(AIM) || defined(__powerpc64__) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Nov-19, at 10:12 PM, Justin Hibbits = wrote: > My buildworld completed successfully, so it's been fixed in = r308873/r308874. >=20 > Thanks for your testing. I often build just kernel, so wouldn't have = seen the fallout until it was far too late. >=20 > - Justin On Nov 19, 2016, at 10:22 PM, Mark Millard wrote: > On 2016-Nov-16, at 8:33 PM, Justin Hibbits = wrote: >=20 >> *sigh* okay, thanks. I just tested, and vm/vm_page.h, and vm/vm.h = can both be removed from memstat_uma.c for it to compile. I'm kicking = off a buildworld myself now, too, and hope to have it ready to commit = tomorrow (takes a couple hours to buildworld on my G5). >>=20 >> - Justin >=20 > That will not be the only potential place: umastat.c in = tools/tools/umastat/ > also has a include of vm/vm_page.h: >=20 >> # find /usr/src/ -name .svn -prune -o -name sys -prune -o -name man = -prune -o -exec grep "vm_page[.]h" {} \; -print | more >> #include >> /usr/src/lib/libmemstat/memstat_uma.c >> #define LIBMEMSTAT /* Cause vm_page.h not to include = opt_vmpage.h */ >> #include >> /usr/src/tools/tools/umastat/umastat.c >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On Nov 19, 2016, at 9:47 PM, Mark Millard wrote: >=20 >> [Top post of bad news.] >>=20 >> With the patch I get a different incomplete type used in libmemstat: >>=20 >> struct md_page >>=20 >> --- all_subdir_lib/libmemstat --- >> In file included from /usr/src/lib/libmemstat/memstat_uma.c:34:0: >> /usr/src/sys/vm/vm_page.h:144:17: error: field 'md' has incomplete = type >> struct md_page md; /* machine dependent stuff */ >> ^ >> *** [memstat_uma.o] Error code 1 >>=20 >> make[5]: stopped in /usr/src/lib/libmemstat >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> On 2016-Nov-19, at 7:42 PM, Mark Millard = wrote: >>=20 >>> On 2016-Nov-19, at 7:36 PM, Mark Millard = wrote: >>>=20 >>>> On 2016-Nov-19, at 7:32 PM, Justin Hibbits wrote: >>>>=20 >>>>> Sorry, I generated the diff from a different tree that wasn't = synced to head (had the same change in both trees originally). If that = is the only problem, you can ignore it and try the rest. I can generate = another diff later too. >>>>> - Justin >>>>=20 >>>> Yep: I manually did the move of the pm_stats line and am building. >>>=20 >>> If it builds and I install it on a PowerMac G5 and it boots, what do = I >>> do to test if pm_stats and pm_mtx seems to be working well/right for >>> the out of kernel code? Do you know of a reasonable test? >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net >>>=20 >> On Nov 19, 2016 21:27, "Mark Millard" wrote: >>> [Top post about patch issues.] >>>=20 >>> Looking at the patch it seems to be designed for when #else was in = use: >>>=20 >>>> -#else >>>> +#elif defined(BOOKE) >>>=20 >>> but -r308817 already has the 2nd line (BOOKE). Your patch shows: >>>=20 >>>> Index: sys/powerpc/include/pmap.h >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> --- sys/powerpc/include/pmap.h (revision 308718) >>>> +++ sys/powerpc/include/pmap.h (working copy) >>>=20 >>> So it looks like you started from before -r308817 . >>>=20 >>> Trying it (I'm at -r308860): >>>=20 >>>> Patching file sys/powerpc/include/pmap.h using Plan A... >>>> Hunk #1 succeeded at 74. >>>> Hunk #2 succeeded at 84. >>>> Hunk #3 succeeded at 132. >>>> Hunk #4 succeeded at 145. >>>> Hunk #5 failed at 180. >>>> Hunk #6 succeeded at 194. >>>> Hunk #7 succeeded at 210. >>>> 1 out of 7 hunks failed--saving rejects to = sys/powerpc/include/pmap.h.rej >>>=20 >>>> # more sys/powerpc/include/pmap.h.rej >>>> @@ -179,13 +180,13 @@ >>>> struct slb **slb_alloc_user_cache(void); >>>> void slb_free_user_cache(struct slb **); >>>>=20 >>>> -#else >>>> +#elif defined(BOOKE) >>>>=20 >>>> struct pmap { >>>> + struct pmap_statistics pm_stats; /* pmap statistics = */ >>>> struct mtx pm_mtx; /* pmap mutex */ >>>> tlbtid_t pm_tid[MAXCPU]; /* TID to identify this = pmap entries in TLB */ >>>> cpuset_t pm_active; /* active on cpus */ >>>> - struct pmap_statistics pm_stats; /* pmap statistics = */ >>>>=20 >>>> /* Page table directory, array of pointers to page tables. */ >>>> pte_t *pm_pdir[PDIR_NENTRIES]; >>>=20 >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net >>>=20 >>> On 2016-Nov-19, at 7:00 PM, Mark Millard = wrote: >>>=20 >>> It may take a little bit but I'll try the patch. >>>=20 >>> It looks like sys/powerpc/include/pmap.h from -r176700 from = 2088-Mar-3 >>> is when the BOOKE/E500 split started with the preprocessor use of = AIM >>> and #else . This predates PowerMac G5 support. >>>=20 >>> This is definitely not new for the general structure on the powerpc >>> side of things. Any place that did not have the AIM vs. not status >>> available was subject to problems of possibly mismatched = definitions. >>>=20 >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net >>>=20 >>> On 2016-Nov-19, at 6:47 PM, Justin Hibbits = wrote: >>>=20 >>> On Sat, 19 Nov 2016 18:36:39 -0800 >>> Mark Millard wrote: >>>=20 >>>> [Quick top post I'm afraid.] >>>>=20 >>>> I think that I figured out why there is a problem even earlier >>>> --that just did not stop the compiles. >>>>=20 >>>> lib/libutil/kinfo_getallproc.c is built here as part of buildworld >>>> (stage 4.2 "building libraries" instead of buildkernel. It does not >>>> have the KERNCONF's AIM vs. BOOKE vs. . . . definitions vs. lack of >>>> them). >>>>=20 >>>> So if it includes machine/pmap.h that binds to >>>> sys/powerpc/include/pmap.h which has the structure. . . >>>>=20 >>>> . . . >>>> #if defined(AIM) >>>> . . . (definitions here) >>>> #elif defined(BOOKE) >>>> . . . (definitions here) >>>> #endif >>>> . . . >>>>=20 >>>> it gets no definition now. >>>>=20 >>>> With the older: >>>>=20 >>>> . . . >>>> #if defined(AIM) >>>> . . . (definitions here) >>>> #else >>>> . . . (definitions here) >>>> #endif >>>> . . . >>>>=20 >>>> It got a definition, just not necessarily the right one. >>>>=20 >>>>=20 >>>> =3D=3D=3D >>>> Mark Millard >>>> markmi at dsl-only.net >>>=20 >>> Can you try the attached patch? There was a subtle ABI issue that >>> r308817 exposed, which is that the pmap structs aren't identical = such >>> that the pm_stats are at different locations, and libkvm ends up >>> reading with the Book-E pmap, getting different stats than expected = for >>> AIM. This patch fixes that, bumping version to account for this ABI >>> change. >>>=20 >>> - Justin >>=20 >>=20 >>=20 >=20 >=20 From owner-freebsd-current@freebsd.org Sun Nov 20 09:03:40 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 198CCC48E74 for ; Sun, 20 Nov 2016 09:03:40 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 C4DE41346; Sun, 20 Nov 2016 09:03:39 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1c8O2C-0044bF-Pk>; Sun, 20 Nov 2016 10:03:36 +0100 Received: from x55b385d5.dyn.telefonica.de ([85.179.133.213] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1c8O2C-000MG0-FP>; Sun, 20 Nov 2016 10:03:36 +0100 Date: Sun, 20 Nov 2016 10:03:35 +0100 From: "O. Hartmann" To: YongHyeon PYUN Cc: FreeBSD CURRENT , gnn@FreeBSD.org, "Andrey V. Elsukov" , glebius@FreeBSD.org, melifaro@FreeBSD.org Subject: Re: CURRENT: re(4) crashing system Message-ID: <20161120100335.3ad66f4f@thor.walstatt.dynvpn.de> In-Reply-To: <20161120074351.GA1090@michelle.fasterthan.co.kr> References: <20161024051359.GA1185@michelle.fasterthan.co.kr> <20161024140337.47af924e@freyja.zeit4.iv.bundesimmobilien.de> <20161025020538.GA1238@michelle.fasterthan.co.kr> <20161025070338.76ad6711@hermann> <20161027010004.GA1215@michelle.fasterthan.co.kr> <20161028212113.5c4a2ca2@hermann> <20161031021222.GA1252@michelle.fasterthan.co.kr> <20161106132036.06add6ca@hermann> <20161107021623.GA1557@michelle.fasterthan.co.kr> <20161119194424.6335338a@thor.walstatt.dynvpn.de> <20161120074351.GA1090@michelle.fasterthan.co.kr> Organization: FU Berlin MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Originating-IP: 85.179.133.213 X-Mailman-Approved-At: Sun, 20 Nov 2016 12:41:16 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 09:03:40 -0000 Am Sun, 20 Nov 2016 16:43:52 +0900 YongHyeon PYUN schrieb: > On Sat, Nov 19, 2016 at 07:44:35PM +0100, O. Hartmann wrote: > > Am Mon, 7 Nov 2016 11:16:23 +0900 > > YongHyeon PYUN schrieb: > > > > > On Sun, Nov 06, 2016 at 01:20:36PM +0100, Hartmann, O. wrote: > > > > On Mon, 31 Oct 2016 11:12:22 +0900 > > > > YongHyeon PYUN wrote: > > > > > > > > > On Fri, Oct 28, 2016 at 09:21:13PM +0200, Hartmann, O. wrote: > > > > > > On Thu, 27 Oct 2016 10:00:04 +0900 > > > > > > YongHyeon PYUN wrote: > > > > > > > > > > > > > On Tue, Oct 25, 2016 at 07:03:38AM +0200, Hartmann, O. wrote: > > > > > > > > On Tue, 25 Oct 2016 11:05:38 +0900 > > > > > > > > YongHyeon PYUN wrote: > > > > > > > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > > I'm not sure but it's likely the issue is related with > > > > > > > > > EEE/Green Ethernet handling. EEE is negotiated feature with > > > > > > > > > link partner. If you directly connect your laptop to non-EEE > > > > > > > > > capable link partner like other re(4) box without switches > > > > > > > > > you may be able to tell whether the issue is EEE/Green > > > > > > > > > Ethernet related one or not. > > > > > > > > > > > > > > > > Me either since when I discovered a problem the first time with > > > > > > > > CURRENT, that was the Friday before last week's Friday, there > > > > > > > > was a unlucky coicidence: I got the new switch, FreeBSD > > > > > > > > introduced a serious bug and I changed the NICs. > > > > > > > > > > > > > > > > The laptop, the last in the row of re(4) equipted systems on > > > > > > > > which I use the Realtek NIC, does well now with Green IT > > > > > > > > technology, but crashes on plugging/unplugging - not on each > > > > > > > > event, but at least in one of ten. > > > > > > > > > > > > > > Hmm, it seems you know how to trigger the issue. When you unplug > > > > > > > UTP cable was there active network traffic on re(4) device? > > > > > > > It would be helpful to know which event triggers the crash(e.g. > > > > > > > unplugging or plugging). And would you show me backtrace of > > > > > > > panic? > > > > > > > > I guess the Green IT issue is more a unlucky guess of mine and > > > > > > > > went hand in hand with the problem I face with CURRENT right > > > > > > > > now on some older, Non UEFI machines. > > > > > > > > > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > > As requested the informations about re0 and rgephy0 on the > > > > > > > > laptop (Lenovo E540) > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > > rgephy0: PHY 1 on miibus0 > > > > > > > > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, > > > > > > > > 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, > > > > > > > > 1000baseT-FDX-master, 1000baseT-FDX-flow, > > > > > > > > 1000baseT-FDX-flow-master, auto, auto-flow > > > > > > > > > > > > > > > > re0: > > > > > > > > port 0x3000-0x30ff mem > > > > > > > > 0xf0d04000-0xf0d04fff,0xf0d00000-0xf0d03fff at device 0.0 on > > > > > > > > pci2 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip > > > > > > > > rev. 0x50800000 re0: MAC rev. 0x00100000 > > > > > > > > > > > > > > This looks like 8168GU controller. > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > I use options netmap in kernel config, but the problem is also > > > > > > > > present without this option - just for the record. > > > > > > > > > > > > > > > > > > > > > > Yup, netmap(4) has nothing to do with the crash. > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > Attached, you'll find the backtrace of the crash. This time it was > > > > > > really easy - just one pull of the LAN cabling - and we are > > > > > > happy :-/ > > > > > > > > > > > > Please let me know if you need something else. I will return to > > > > > > normal operations (disabling debugging) due to CURRENT is very > > > > > > unstable at the moment on other hosts beyond r307157. > > > > > > > > > > > > > > > > It seems the attachment was stripped. > > > > > > > > This time I hope I got it right! > > > > > > > > Attached you'll find the latest CURRENT's backtrace on the provoked > > > > crash (plug and unplug). > > > > > > > > I also saved the kernel and coredump, so if you need me to do further > > > > investigations,please let me know. > > > > > > > > > > Thanks a lot for the backtrace. This backtrace is not the one I > > > expected and I guess the issue is related with cached route removal > > > on interface down. Quick looking over the code didn't reveal the > > > cause of crash(I'm not familiar with that part code). Probably > > > gnn@ may have better idea what's going on here(CCed). > > > > > > Thanks. > > > > In another thread I complained about permanent crashes on several "older" Intel > > architectures (IvyBridge and down). It has been revealed, that > > > > option FLOWTABLE > > > > in the kernel, which is part of my custom kernels a long time for now, has been > > identified as the culprit on those systems. Commenting out that special option solved > > the problem! > > > > Interestingly, also commenting out this option from the kernel config of the laptop in > > question of this thread, I wasn't able - as of this writing - to reproduce the > > crashes, so it might be that the same issue with FLOWTABLE has been triggered by > > pluggin and/or unpluggin the LAN cord. > > > > I'm not sure whether it's triggered by FLOWTABLE yet since it had > been there for a log time. I suspected r297225, r301217 which > re-added route caching for TCP. The panic you encountered > indicates invalid access against destroyed lock which in turn > suggests reference counting problem in lltable. > I've CCed glebius@ and melifaro@ who are more familiar with routing > code than me. I understand. The problem with FLOWTABLE occured with r307234, r307233 was all right, everything beyond on a certain type of our computers crashed then. I got this "hint" from ae@ and disabled FLOWTABLE - and eveything was all right then, on ALL systems. And as I reported: the laptop I have this plugging-unplugging problem is seemingly also reliefed of this problem now. Maybe I misunderstand and option FLOWTABLE is only the point of trigger of another problem. Just for the report. > > > Usually I was able to trigger the coredump after two or three rounds, this time I > > tried it over ten times with no effect. > > > > But on the contrary, the NIC of the laptop doesn't negotiate for 1 GBit/s with my > > switch, it remains with 100 MBit/s. The switch is a Netgear GS110TP V2. > > > > This would be a re(4) driver problem. When you see it negotiated > 100Mbps after unplugging/plugging, would you try to negotiate with > link partner again like below and let me know the result? > > #ifconfig re0 media auto > > Does the behavior change if you physically unplug/plug UTP cable on > laptop rather than forcing port down/up on the switch? I physically plug and unplug the LAN cord to test it. I use on that specific port/laptop/switchport one of these new fancy flat ribbon cables, supposedly to be capable of GBit/CAT6. Well, using a usual on (stiff, traditional) seems to solve this "problem" - physics and fancy seems to be mutual exclusive ;-) > > Thanks. Kind regards, Oliver [...] From owner-freebsd-current@freebsd.org Sun Nov 20 16:00:01 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92884C4C40D for ; Sun, 20 Nov 2016 16:00:01 +0000 (UTC) (envelope-from setun.90@gmail.com) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D507126B for ; Sun, 20 Nov 2016 16:00:01 +0000 (UTC) (envelope-from setun.90@gmail.com) Received: by mail-oi0-x233.google.com with SMTP id b126so99930925oia.2 for ; Sun, 20 Nov 2016 08:00:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=Xvmr2GiPP9/d8Yg72pgjZqRdf7d6EAQsquHK14W/6Fg=; b=Ookj0C7oYECCdtIDN9aKBCg/e+zDZ2nEU5WjV6Qz47WIeqYA5HU6BJKgPv5R6FLaE9 IgUQG/Ne2LK8X5EP3awguAWi8VH0TaUqJck7KUEP7hAnHvV2l1uT1y9baTO+JmRpkTHW OWP6uj720Z4DSI8oU/qiSEYX6YFN4g9UEg08blUVk8pqFOECIighsjmLv/hi04U7GeW1 Xqu8+vxK9/hrBg4TW8uXKj6CpD4jOVQ3o9FWv/yEjs7CXmJ4y4mwY1/rAWlmQF6CWMzC iPe+nwNHbz+Mnzi9h8yKcYw+eEO5HQLxsyKYqyHQO6Lu6KuwZK3EmyiSps4lztp6z91E 6+vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Xvmr2GiPP9/d8Yg72pgjZqRdf7d6EAQsquHK14W/6Fg=; b=C9gi5vczLlp4OtIQo+ct9Hujhh6csr9ZSvBTAkAY+YXng/7ZA2e12ikamqXR5qjKcI ykAOjFhpn9olHNJu4jEYVXRx5caMimB/YSNT+QdfGibyszElKt3NPlESRlkHUkK2sgMD BxY6OFgXKTQqnl2fKvw8BPt+ceOh97VZcF0S+G2cpSXUgiyzBdRitSBM/LlbMR9nsiDm f1x9uUdh40BedLU3C3gbpOOfej+dzOkd4Y7xnPg44gyu/6XO0/Cv+bwHhs92b8kszMm+ rjyqwq40mAX9dAi3O3JznB1gor6KNdreQJdedtK+CIfBC5ZS2P+fbDIiGGIYf7vDN0oN bOsw== X-Gm-Message-State: AKaTC03NwFLZtyu7vfKsxDPkzfM7vlPorZDmKI6JBegL7VzhBW1I99K+e+pO3a61Aab7/5Z/tGD6i1LsMUg+rw== X-Received: by 10.157.11.14 with SMTP id a14mr6264516ota.185.1479657600518; Sun, 20 Nov 2016 08:00:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.28.167 with HTTP; Sun, 20 Nov 2016 08:00:00 -0800 (PST) From: Daniel Campos do Nascimento Date: Sun, 20 Nov 2016 17:00:00 +0100 Message-ID: Subject: DRM-4.7 branch: buildkernel failed To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 16:00:01 -0000 Hello, I tried building the 'drm-next-4.7' branch of the FreeBSDDesktop fork of 12.0-CURRENT, but clang fails to find required headers: [log truncated to failing source file] --- ati_pcigart.o --- /usr/local/bin/clang38 -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/current/freebsd-base-graphics/tmp -B/usr/obj/usr/src/current/freebsd-base-graphics/tmp/usr/bin -c -O2 -pipe -fno-strict-aliasing -march=native -g -nostdinc -I. -I/usr/src/current/freebsd-base-graphics/sys -I/usr/src/current/freebsd-base-graphics/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.ati_pcigart.o -MTati_pcigart.o -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -mno-aes -mno-avx -std=iso9899:1999 -Werror /usr/src/current/freebsd-base-graphics/sys/dev/drm/ati_pcigart.c /usr/src/current/freebsd-base-graphics/sys/dev/drm/ati_pcigart.c:34:10: fatal error: 'linux/export.h' file not found #include ^ 1 error generated. *** [ati_pcigart.o] Error code 1 make[2]: stopped in /usr/obj/usr/src/current/freebsd-base-graphics/sys/LOCAL --- modules-all --- --- fm.o --- ctfconvert -L VERSION -g fm.o --- inffast.o --- ctfconvert -L VERSION -g inffast.o --- deflate.o --- ctfconvert -L VERSION -g deflate.o A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/current/freebsd-base-graphics/sys/modules/zfs *** [all_subdir_zfs] Error code 2 make[3]: stopped in /usr/src/current/freebsd-base-graphics/sys/modules 1 error make[3]: stopped in /usr/src/current/freebsd-base-graphics/sys/modules *** [modules-all] Error code 2 make[2]: stopped in /usr/obj/usr/src/current/freebsd-base-graphics/sys/LOCAL 2 errors make[2]: stopped in /usr/obj/usr/src/current/freebsd-base-graphics/sys/LOCAL *** [buildkernel] Error code 2 make[1]: stopped in /usr/src/current/freebsd-base-graphics 1 error make[1]: stopped in /usr/src/current/freebsd-base-graphics *** [buildkernel] Error code 2 make: stopped in /usr/src/current/freebsd-base-graphics 1 error make: stopped in /usr/src/current/freebsd-base-graphics [EOF] where LOCAL is my KERNCONF. I had attempted a previous build of this branch, and it failed in exactly the same way. Should I see with the maintainers of the branch? uname -a: FreeBSD setun-90 11.0-STABLE FreeBSD 11.0-STABLE #0 r308484: Thu Nov 10 23:22:53 CET 2016 root@setun-90:/usr/obj/usr/src/stable/sys/LOCAL amd64 dmesg | grep CPU: CPU: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz (2592.09-MHz K8-class CPU) Cheers, From owner-freebsd-current@freebsd.org Sun Nov 20 18:14:41 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 29BE2C4C7B8 for ; Sun, 20 Nov 2016 18:14:41 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 1903D1F2 for ; Sun, 20 Nov 2016 18:14:41 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: by mailman.ysv.freebsd.org (Postfix) id 15733C4C7B6; Sun, 20 Nov 2016 18:14:41 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1520AC4C7B5 for ; Sun, 20 Nov 2016 18:14:41 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id D4D7E1F1 for ; Sun, 20 Nov 2016 18:14:40 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 3641F273CD for ; Sun, 20 Nov 2016 18:14:34 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id uAKIEXiD080832 for ; Sun, 20 Nov 2016 18:14:33 GMT (envelope-from phk@phk.freebsd.dk) To: current@freebsd.org Subject: a dirty trick: i386 nanobsd ports on amd64 From: Poul-Henning Kamp MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <80830.1479665673.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sun, 20 Nov 2016 18:14:33 +0000 Message-ID: <80831.1479665673@critter.freebsd.dk> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 18:14:41 -0000 I ran into a interesting problem, and want to share the solution, in case anybody else can use it. I'm upgrading a system which used to be i386 to amd64, but part of its job is to compile i386 nanobsd images. That's a solved problem, but I also needed a couple of ports installed, which for reasons of paperwork, must be compiled from source. Cross-compiling ports is not something I wanted to get into, but happily amd64 cpus can run in i386 mode these days: phk_ports () ( set -e cd ${NANO_WORLDDIR} mkdir -p usr/ports trap "umount ${NANO_WORLDDIR}/usr/ports ; umount ${NANO_WORLDDIR}/= dev" 1 2 15 EXIT mount -t nullfs -o readonly /usr/ports ${NANO_WORLDDIR}/usr/ports mount -t devfs devfs ${NANO_WORLDDIR}/dev echo ' ldconfig -elf for i in ports-mgmt/pkg sysutils/smartmontools net/trafshow do cd /usr/ports/${i} make \ WRKDIRPREFIX=3D/tmp \ BATCH=3DYES \ OPTIONS_UNSET=3D"DOCS NLS" \ all install clean done ' > ${NANO_WORLDDIR}/tmp/_job.sh chroot ${NANO_WORLDDIR} /bin/sh /tmp/_job.sh umount ${NANO_WORLDDIR}/usr/ports umount ${NANO_WORLDDIR}/dev trap - 1 2 15 EXIT ) customize_cmd phk_ports The same basic trick can of course be be used for any i386 software which must be compiled from source. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-current@freebsd.org Mon Nov 21 08:23:11 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CFC8CC4D21A for ; Mon, 21 Nov 2016 08:23:11 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id BF5822E3 for ; Mon, 21 Nov 2016 08:23:11 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: by mailman.ysv.freebsd.org (Postfix) id BB893C4D219; Mon, 21 Nov 2016 08:23:11 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB35EC4D218 for ; Mon, 21 Nov 2016 08:23:11 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by mx1.freebsd.org (Postfix) with ESMTP id 47CDE2E2 for ; Mon, 21 Nov 2016 08:23:10 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ppp121-45-17-13.bras1.adl2.internode.on.net (HELO leader.local) ([121.45.17.13]) by ipmail06.adl2.internode.on.net with ESMTP; 21 Nov 2016 18:48:01 +1030 Subject: Re: a dirty trick: i386 nanobsd ports on amd64 To: Poul-Henning Kamp , current@freebsd.org References: <80831.1479665673@critter.freebsd.dk> From: Shane Ambler Message-ID: <9843926e-e4c1-2e91-b1d3-0aca93fd709b@ShaneWare.Biz> Date: Mon, 21 Nov 2016 18:47:58 +1030 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <80831.1479665673@critter.freebsd.dk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 08:23:11 -0000 On 21/11/2016 04:44, Poul-Henning Kamp wrote: > I ran into a interesting problem, and want to share the solution, in > case anybody else can use it. > > I'm upgrading a system which used to be i386 to amd64, but part of > its job is to compile i386 nanobsd images. > > That's a solved problem, but I also needed a couple of ports installed, > which for reasons of paperwork, must be compiled from source. > > Cross-compiling ports is not something I wanted to get into, but > happily amd64 cpus can run in i386 mode these days: That is something poudriere is designed to do. i386 on amd64 is straight forward, you can also use qemu to cross compile for other archs Using poudriere you can also setup a pkg repo with the ports you build, just setup a http server then set pkg on your nano machine to use something like http://mypkgbuilder/packages/11i386 as the url for it's packages. -- FreeBSD - the place to B...Software Developing Shane Ambler From owner-freebsd-current@freebsd.org Mon Nov 21 16:11:41 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8AB2C4CC27 for ; Mon, 21 Nov 2016 16:11:41 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AF6C71EB7 for ; Mon, 21 Nov 2016 16:11:41 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-226-236.lns20.per1.internode.on.net [121.45.226.236]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id uALFsG9s013159 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 21 Nov 2016 07:54:19 -0800 (PST) (envelope-from julian@freebsd.org) To: freebsd-current From: Julian Elischer Subject: tput failing on 10 and 12 systems? Message-ID: <834855a9-adcd-71b3-2422-e9eb97258486@freebsd.org> Date: Mon, 21 Nov 2016 23:54:10 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 16:11:42 -0000 example on freefall (FreeBSD 12.0-CURRENT #0 r306376) julian@freefall:tput setaf 4|od -c 0000000 033 [ m 0000003 so nothing happens, and tput returns 1. but on a FreeBSD 8 system: [jelischer@alpha ~]$ tput setaf 4|od -c 0000000 033 [ 3 4 m 0000005 which make the text change color. similarly all the related tput color commands I can think of fail on 10,11,12 but programs such as vim can use color just fine. So I suspect tput itself. anyone have experience with this? seems easy to reproduce. From owner-freebsd-current@freebsd.org Mon Nov 21 16:49:11 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D7432C4DCA1 for ; Mon, 21 Nov 2016 16:49:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A32FA1B8F; Mon, 21 Nov 2016 16:49:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-it0-x229.google.com with SMTP id c20so90514784itb.0; Mon, 21 Nov 2016 08:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XSOPOkk545l6imQuaNNrPTcsmL/uvPT5F/CgxwTKqow=; b=IVB4ou6pLRcBOZrLxoXSd4w7hIuTfFNaJZ3YE0eY+/lIyMCYp5n+ZcDDN0yf5fEg22 1V6uFv961UpE6pN/jcAgGY9wZzJX38Yg/SpxwJbZsD/cqz5BhGAM10b7fqh8TMAAKgZs J+euVs1Kd4ti6qVLgceN1vAf4ihShs6eY71alEP2CiDOFLm5QzwTLAZvnbXovVFlJHeb SAGlK/ksri2AQ9yOIIaFV3ePii9iXaNCKZmMOGKzL39IdVUonZpdRdW3iDjXFjVrgamf BO+/zovuUF1yc2YEFDIP0/oNRDL0RAJKro6xm1ZjfraPWlikgLL31Zj3eU2pzCxu4jMU S4xw== 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; bh=XSOPOkk545l6imQuaNNrPTcsmL/uvPT5F/CgxwTKqow=; b=PqiYZkTITbA+xWE1O3NfIZg6KvBx+WQvOG3vUF37GMA/6HFi0ehX07bP7kZKbSHS6n BHfRsYxW5j8z9YOFXHV1QKxhznmzlN/WN3NQtwDdRRxZsdvbOR3AEZ+IN1SiF0/jl+5K fPB9UkV9rlmJ+0uUWsqEs9t/Ed7EnJ/o7uks/Fp21oLqQ+XxXJa9hh/d33TxDKsYv+w0 zbkOybTeFDcMS7XmctBauz4sptwaZDcz3XtcEHK70buOQm9ObDy4udVToBqLlCfY9dRf CfczpNEYw03wV4/duUCJZFiJ7KELogSAgbkeZ/ZopJae9ogA9smEpX1DmycJBlqQ+/oN HdzA== X-Gm-Message-State: AKaTC02vK9J3QRaDORbLrLaXWgbSrFl7MK0AxqxinkBaKfIozs+iSOld1UBYaQnbAFTTvHhnpJXSo4DsCMWwvA== X-Received: by 10.36.91.134 with SMTP id g128mr7651835itb.78.1479746950858; Mon, 21 Nov 2016 08:49:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.39.134 with HTTP; Mon, 21 Nov 2016 08:49:10 -0800 (PST) In-Reply-To: <834855a9-adcd-71b3-2422-e9eb97258486@freebsd.org> References: <834855a9-adcd-71b3-2422-e9eb97258486@freebsd.org> From: Adrian Chadd Date: Mon, 21 Nov 2016 08:49:10 -0800 Message-ID: Subject: Re: tput failing on 10 and 12 systems? To: Julian Elischer Cc: freebsd-current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 16:49:11 -0000 Hiya, Just to follow through - part of tput is to decode command args, but it then just requests it from the ncurses tputs() call. So it could be tput, but it could also be the BSD ncurses work. -adrian On 21 November 2016 at 07:54, Julian Elischer wrote: > example on freefall (FreeBSD 12.0-CURRENT #0 r306376) > > julian@freefall:tput setaf 4|od -c > 0000000 033 [ m > 0000003 > > so nothing happens, and tput returns 1. > > but on a FreeBSD 8 system: > > [jelischer@alpha ~]$ tput setaf 4|od -c > 0000000 033 [ 3 4 m > 0000005 > > which make the text change color. > > > similarly all the related tput color commands I can think of fail on > 10,11,12 > > but programs such as vim can use color just fine. So I suspect tput itself. > > > anyone have experience with this? seems easy to reproduce. > > > > > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon Nov 21 17:02:24 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 428E6C4D15E for ; Mon, 21 Nov 2016 17:02:24 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1FAED7FD for ; Mon, 21 Nov 2016 17:02:23 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-226-236.lns20.per1.internode.on.net [121.45.226.236]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id uALH2J8b013419 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 21 Nov 2016 09:02:22 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: tput failing on 10 and 12 systems? To: Adrian Chadd References: <834855a9-adcd-71b3-2422-e9eb97258486@freebsd.org> Cc: freebsd-current From: Julian Elischer Message-ID: Date: Tue, 22 Nov 2016 01:02:13 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 17:02:24 -0000 On 22/11/2016 12:49 AM, Adrian Chadd wrote: > Hiya, > > Just to follow through - part of tput is to decode command args, but > it then just requests it from the ncurses tputs() call. > > So it could be tput, but it could also be the BSD ncurses work. but the ncurses stuff works for things like vim > > > -adrian > > > On 21 November 2016 at 07:54, Julian Elischer wrote: >> example on freefall (FreeBSD 12.0-CURRENT #0 r306376) >> >> julian@freefall:tput setaf 4|od -c >> 0000000 033 [ m >> 0000003 >> >> so nothing happens, and tput returns 1. >> >> but on a FreeBSD 8 system: >> >> [jelischer@alpha ~]$ tput setaf 4|od -c >> 0000000 033 [ 3 4 m >> 0000005 >> >> which make the text change color. >> >> >> similarly all the related tput color commands I can think of fail on >> 10,11,12 >> >> but programs such as vim can use color just fine. So I suspect tput itself. >> >> >> anyone have experience with this? seems easy to reproduce. >> >> >> >> >> >> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Mon Nov 21 17:03:10 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85158C4D1D0 for ; Mon, 21 Nov 2016 17:03:10 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 62F12947 for ; Mon, 21 Nov 2016 17:03:10 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-226-236.lns20.per1.internode.on.net [121.45.226.236]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id uALH357r013428 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 21 Nov 2016 09:03:09 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: tput failing on 10 and 12 systems? To: Adrian Chadd References: <834855a9-adcd-71b3-2422-e9eb97258486@freebsd.org> Cc: freebsd-current From: Julian Elischer Message-ID: <1b096f08-a63b-7254-58ba-9ee1ceb2ff5a@freebsd.org> Date: Tue, 22 Nov 2016 01:03:00 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 17:03:10 -0000 On 22/11/2016 12:49 AM, Adrian Chadd wrote: > Hiya, > > Just to follow through - part of tput is to decode command args, but > it then just requests it from the ncurses tputs() call. > > So it could be tput, but it could also be the BSD ncurses work. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214709 > > > -adrian > > > On 21 November 2016 at 07:54, Julian Elischer wrote: >> example on freefall (FreeBSD 12.0-CURRENT #0 r306376) >> >> julian@freefall:tput setaf 4|od -c >> 0000000 033 [ m >> 0000003 >> >> so nothing happens, and tput returns 1. >> >> but on a FreeBSD 8 system: >> >> [jelischer@alpha ~]$ tput setaf 4|od -c >> 0000000 033 [ 3 4 m >> 0000005 >> >> which make the text change color. >> >> >> similarly all the related tput color commands I can think of fail on >> 10,11,12 >> >> but programs such as vim can use color just fine. So I suspect tput itself. >> >> >> anyone have experience with this? seems easy to reproduce. >> >> >> >> >> >> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Tue Nov 22 07:42:00 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F0ECC4F2F1 for ; Tue, 22 Nov 2016 07:42:00 +0000 (UTC) (envelope-from kiri@kx.openedu.org) Received: from kx.openedu.org (flets-sg1027.kamome.or.jp [202.216.24.27]) (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 E22CBD80 for ; Tue, 22 Nov 2016 07:41:59 +0000 (UTC) (envelope-from kiri@kx.openedu.org) Received: from kx.openedu.org (kx.openedu.org [103.15.187.19]) by kx.openedu.org (8.14.5/8.14.5) with ESMTP id uAM7bMSY072062; Tue, 22 Nov 2016 16:37:22 +0900 (JST) (envelope-from kiri@kx.openedu.org) Message-Id: <201611220737.uAM7bMSY072062@kx.openedu.org> Date: Tue, 22 Nov 2016 16:37:22 +0900 From: KIRIYAMA Kazuhiko To: freebsd-current Cc: kiri@kx.openedu.org Subject: fatal: Fssh_packet_write_poll: Connection from xxx.xxx.xx.xx port yyyyy: Permission denied User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.6 MULE XEmacs/21.4 (patch 22) (Instant Classic) (amd64--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 07:42:00 -0000 Hi, all I've updated to HEAD(r308871) at 2 days ago, and also ports too(r426562). Then all stuffs including applications have been updated and tried to slogin to this host,but can't connect with the message `userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]' in /var/log/auth.log. I found new OpenSSH-7.* has not been supported DSA and to connect from client with old ssh(lower than OpenSSH-7.0),set `ssh-dss' or some values set to relevant variables in /etc/ssh/sshd_config. According to [1] and [2] I've set these variables as below: PubkeyAcceptedKeyTypes=+ssh-dss HostKeyAlgorithms=+ssh-dss KexAlgorithms=+diffie-hellman-group-exchange-sha256 and successfully slogined: kiri@kazu:~[998]% slogin -v tfc OpenSSH_6.2p2, OpenSSL 0.9.8y 5 Feb 2013 debug1: Reading configuration data /home/kiri/.ssh/config debug1: /home/kiri/.ssh/config line 13: Applying options for tfc debug1: Reading configuration data /etc/ssh/ssh_config debug1: Connecting to xx.xxxxxx.xxx [yyy.yyy.yy.yy] port zzzzz. debug1: Connection established. debug1: identity file /home/kiri/.ssh/id_rsa type -1 debug1: identity file /home/kiri/.ssh/id_rsa-cert type -1 debug1: identity file /home/kiri/.ssh/id_dsa type 2 debug1: identity file /home/kiri/.ssh/id_dsa-cert type -1 debug1: identity file /home/kiri/.ssh/id_ecdsa type -1 debug1: identity file /home/kiri/.ssh/id_ecdsa-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.2_hpn13v11 FreeBSD-20130515 debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2 FreeBSD-20160310 debug1: match: OpenSSH_7.2 FreeBSD-20160310 pat OpenSSH* debug1: Remote is not HPN-aware debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-sha1-etm@openssh.com none debug1: kex: client->server aes128-ctr hmac-sha1-etm@openssh.com none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA 41:61:5e:8c:03:c7:70:c4:e7:d8:52:56:2a:36:86:21 debug1: Host '[xx.xxxxxx.xxx]:zzzzz' is known and matches the ECDSA host key. debug1: Found key in /home/kiri/.ssh/known_hosts:172 debug1: ssh_ecdsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Next authentication method: publickey debug1: Trying private key: /home/kiri/.ssh/id_rsa debug1: Offering DSA public key: /home/kiri/.ssh/id_dsa debug1: Server accepts key: pkalg ssh-dss blen 434 debug1: read PEM private key done: type DSA debug1: Authentication succeeded (publickey). Authenticated to xx.xxxxxx.xxx ([yyy.yyy.yy.yy]:zzzzz). debug1: HPN to Non-HPN Connection debug1: Final hpn_buffer_size = 2097152 debug1: HPN Disabled: 0, HPN Buffer Size: 2097152 debug1: channel 0: new [client-session] debug1: Enabled Dynamic Window Scaling debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0 Last login: Tue Nov 22 16:21:34 2016 from flets-sg1027.kamome.or.jp FreeBSD 12.0-CURRENT (XIJ) #13 r308871M: Sun Nov 20 15:51:21 JST 2016 Welcome to FreeBSD! Release Notes, Errata: https://www.FreeBSD.org/releases/ Security Advisories: https://www.FreeBSD.org/security/ FreeBSD Handbook: https://www.FreeBSD.org/handbook/ FreeBSD FAQ: https://www.FreeBSD.org/faq/ Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/ FreeBSD Forums: https://forums.FreeBSD.org/ Documents installed with the system are in the /usr/local/share/doc/freebsd/ directory, or can be installed later with: pkg install en-freebsd-doc For other languages, replace "en" with a language code like de or fr. Show the version of FreeBSD installed: freebsd-version ; uname -a Please include that output and any error messages when posting questions. Introduction to manual pages: man man FreeBSD directory layout: man hier Edit /etc/motd to change this login announcement. To see the output from when your computer started, run dmesg(8). If it has been replaced with other messages, look at /var/run/dmesg.boot. -- Francisco Reyes admin@kx:~ % And so try to scp files from this host,then failed as below: kiri@kazu:~[1028]% scp -vvv tfc:/jails/desktop/commonjail/home/kiri/projects/xemacs/xemacs-packages/sdoc-mode-1.10-pkg.tar.gz ~/projects/xemacs/xemacs-packages/sdoc-mode-1.10-pkg.tar.gz Executing: program /usr/bin/ssh host tfc, user (unspecified), command scp -v -f /jails/desktop/commonjail/home/kiri/projects/xemacs/xemacs-packages/sdoc-mode-1.10-pkg.tar.gz OpenSSH_6.2p2, OpenSSL 0.9.8y 5 Feb 2013 debug1: Reading configuration data /home/kiri/.ssh/config debug1: /home/kiri/.ssh/config line 13: Applying options for tfc debug1: Reading configuration data /etc/ssh/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to xx.xxxxxx.xxx [yyy.yyy.yy.yy] port zzzzz. debug1: Connection established. debug1: identity file /home/kiri/.ssh/id_rsa type -1 debug1: identity file /home/kiri/.ssh/id_rsa-cert type -1 debug3: Incorrect RSA1 identifier debug3: Could not load "/home/kiri/.ssh/id_dsa" as a RSA1 public key debug1: identity file /home/kiri/.ssh/id_dsa type 2 debug1: identity file /home/kiri/.ssh/id_dsa-cert type -1 debug1: identity file /home/kiri/.ssh/id_ecdsa type -1 debug1: identity file /home/kiri/.ssh/id_ecdsa-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.2_hpn13v11 FreeBSD-20130515 debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2 FreeBSD-20160310 debug1: match: OpenSSH_7.2 FreeBSD-20160310 pat OpenSSH* debug1: Remote is not HPN-aware debug2: fd 3 setting O_NONBLOCK debug3: put_host_port: [xx.xxxxxx.xxx]:zzzzz debug3: ssh_load_hostkeys: loading entries for host "[xx.xxxxxx.xxx]:zzzzz" from file "/home/kiri/.ssh/known_hosts" debug3: ssh_load_hostkeys: found key type ECDSA in file /home/kiri/.ssh/known_hosts:172 debug3: ssh_load_hostkeys: loaded 1 keys debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1 debug2: kex_parse_kexinit: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-sha1-etm@openssh.com debug1: kex: server->client aes128-ctr hmac-sha1-etm@openssh.com none debug2: mac_setup: found hmac-sha1-etm@openssh.com debug1: kex: client->server aes128-ctr hmac-sha1-etm@openssh.com none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA 41:61:5e:8c:03:c7:70:c4:e7:d8:52:56:2a:36:86:21 debug3: put_host_port: [yyy.yyy.yy.yy]:zzzzz debug3: put_host_port: [xx.xxxxxx.xxx]:zzzzz debug3: ssh_load_hostkeys: loading entries for host "[xx.xxxxxx.xxx]:zzzzz" from file "/home/kiri/.ssh/known_hosts" debug3: ssh_load_hostkeys: found key type ECDSA in file /home/kiri/.ssh/known_hosts:172 debug3: ssh_load_hostkeys: loaded 1 keys debug1: Host '[xx.xxxxxx.xxx]:zzzzz' is known and matches the ECDSA host key. debug1: Found key in /home/kiri/.ssh/known_hosts:172 debug1: ssh_ecdsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/kiri/.ssh/id_rsa (0x0), debug2: key: /home/kiri/.ssh/id_dsa (0x8028540d0), debug2: key: /home/kiri/.ssh/id_ecdsa (0x0), debug1: Authentications that can continue: publickey,keyboard-interactive debug3: start over, passed a different list publickey,keyboard-interactive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /home/kiri/.ssh/id_rsa debug3: no such identity: /home/kiri/.ssh/id_rsa: No such file or directory debug1: Offering DSA public key: /home/kiri/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-dss blen 434 debug2: input_userauth_pk_ok: fp a6:95:cd:c1:9f:46:9b:8d:de:2a:30:bf:bd:f7:12:0a debug3: sign_and_send_pubkey: DSA a6:95:cd:c1:9f:46:9b:8d:de:2a:30:bf:bd:f7:12:0a debug1: read PEM private key done: type DSA debug1: Authentication succeeded (publickey). Authenticated to xx.xxxxxx.xxx ([yyy.yyy.yy.yy]:zzzzz). debug2: fd 4 setting O_NONBLOCK debug2: fd 5 setting O_NONBLOCK debug1: HPN to Non-HPN Connection debug1: Final hpn_buffer_size = 2097152 debug1: HPN Disabled: 0, HPN Buffer Size: 2097152 debug1: channel 0: new [client-session] debug1: Enabled Dynamic Window Scaling debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0 debug2: callback start debug2: fd 3 setting TCP_NODELAY debug3: packet_set_tos: set IP_TOS 0x08 debug2: client_session2_setup: id 0 debug1: Sending command: scp -v -f /jails/desktop/commonjail/home/kiri/projects/xemacs/xemacs-packages/sdoc-mode-1.10-pkg.tar.gz debug2: channel 0: request exec confirm 1 debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: channel 0: rcvd adjust 2097152 debug2: channel_input_status_confirm: type 99 id 0 debug2: exec request accepted on channel 0 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: channel 0: rcvd ext data 58 debug2: tcpwinsz: 65894 for connection: 3 Sending file modes: C0644 16580 sdoc-mode-1.10-pkg.tar.gz debug2: channel 0: written 58 to efd 6 debug2: tcpwinsz: 65894 for connection: 3 Sink: C0644 16580 sdoc-mode-1.10-pkg.tar.gz debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 sdoc-mode-1.10-pkg.tar.gz 0% 0 0.0KB/s --:-- ETAdebug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 sdoc-mode-1.10-pkg.tar.gz 0% 0 0.0KB/s --:-- ETAdebug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 sdoc-mode-1.10-pkg.tar.gz 0% 0 0.0KB/s --:-- ETAdebug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cc -1) debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK Connection to xx.xxxxxx.xxx closed by remote host. Transferred: sent 3392, received 19492 bytes, in 2.6 seconds Bytes per second: sent 1308.6, received 7520.0 debug1: Exit status -1 lost connection kiri@kazu:~[1029]% And with the message `fatal: Fssh_packet_write_poll: Connection from xxx.xxx.xx.xx port yyyyy: Permission denied' in /var/log/auth.log: Nov 22 16:07:51 kx sshd[73878]: Accepted publickey for admin from xxx.xxx.xx.xx port 64147 ssh2: DSA SHA256:6uPsONRWeNkYjlj9BU4GZYUUeH60ZbUCB25jolvrvj8 Nov 22 16:07:51 kx sshd[73880]: fatal: Fssh_packet_write_poll: Connection from xxx.xxx.xx.xx port 64147: Permission denied Is there any suggesions? My environments are as follows: - Server: admin@kx:~ % uname -a FreeBSD kx.truefc.org 12.0-CURRENT FreeBSD 12.0-CURRENT #13 r308871M: Sun Nov 20 15:51:21 JST 2016 admin@kx.truefc.org:/usr/obj/usr/src/sys/XIJ amd64 admin@kx:~ % ssh -V OpenSSH_7.2p2, OpenSSL 1.0.2j-freebsd 26 Sep 2016 admin@kx:~ % - Client: kiri@kazu:~[995]% uname -a FreeBSD kazu.pis 9.2-STABLE FreeBSD 9.2-STABLE #5 r259404M: Mon Dec 16 00:12:52 JST 2013 admin@kazu.pis:/usr/obj/usr/src/sys/GENERIC amd64 kiri@kazu:~[996]% ssh -V OpenSSH_6.2p2, OpenSSL 0.9.8y 5 Feb 2013 kiri@kazu:~[997]% Best regards. [1] https://www.gentoo.org/support/news-items/2015-08-13-openssh-weak-keys.html [2] https://lists.freebsd.org/pipermail/freebsd-current/2016-August/062853.html --- KIRIYAMA Kazuhiko From owner-freebsd-current@freebsd.org Tue Nov 22 15:47:23 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B35DC4C428 for ; Tue, 22 Nov 2016 15:47:23 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (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 600611020 for ; Tue, 22 Nov 2016 15:47:22 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 1D5ECDC50 for ; Tue, 22 Nov 2016 15:47:21 +0000 (UTC) Subject: Re: fatal: Fssh_packet_write_poll: Connection from xxx.xxx.xx.xx port yyyyy: Permission denied To: freebsd-current@freebsd.org References: <201611220737.uAM7bMSY072062@kx.openedu.org> From: Allan Jude Message-ID: <2b9b6473-fc17-3aad-ee1a-4c20b340ec00@freebsd.org> Date: Tue, 22 Nov 2016 10:47:17 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <201611220737.uAM7bMSY072062@kx.openedu.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CXdVfMotnbxOCoC2X88lnEMiI1ncQONlt" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 15:47:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CXdVfMotnbxOCoC2X88lnEMiI1ncQONlt Content-Type: multipart/mixed; boundary="oPpWlJaaXNbqBW8tJLlJMgqekJtn2cvH1"; protected-headers="v1" From: Allan Jude To: freebsd-current@freebsd.org Message-ID: <2b9b6473-fc17-3aad-ee1a-4c20b340ec00@freebsd.org> Subject: Re: fatal: Fssh_packet_write_poll: Connection from xxx.xxx.xx.xx port yyyyy: Permission denied References: <201611220737.uAM7bMSY072062@kx.openedu.org> In-Reply-To: <201611220737.uAM7bMSY072062@kx.openedu.org> --oPpWlJaaXNbqBW8tJLlJMgqekJtn2cvH1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2016-11-22 02:37, KIRIYAMA Kazuhiko wrote: > Hi, all >=20 > I've updated to HEAD(r308871) at 2 days ago, and also ports > too(r426562). Then all stuffs including applications have > been updated and tried to slogin to this host,but can't > connect with the message `userauth_pubkey: key type ssh-dss > not in PubkeyAcceptedKeyTypes [preauth]' in > /var/log/auth.log. I found new OpenSSH-7.* has not been > supported DSA and to connect from client with old ssh(lower > than OpenSSH-7.0),set `ssh-dss' or some values set to > relevant variables in /etc/ssh/sshd_config. According to [1] > and [2] I've set these variables as below: >=20 > PubkeyAcceptedKeyTypes=3D+ssh-dss > HostKeyAlgorithms=3D+ssh-dss > KexAlgorithms=3D+diffie-hellman-group-exchange-sha256 >=20 > and successfully slogined: >=20 snip >=20 > And with the message `fatal: Fssh_packet_write_poll: > Connection from xxx.xxx.xx.xx port yyyyy: Permission denied' > in /var/log/auth.log: >=20 >=20 > Nov 22 16:07:51 kx sshd[73878]: Accepted publickey for admin from xxx.x= xx.xx.xx port 64147 ssh2: DSA SHA256:6uPsONRWeNkYjlj9BU4GZYUUeH60ZbUCB25j= olvrvj8 > Nov 22 16:07:51 kx sshd[73880]: fatal: Fssh_packet_write_poll: Connecti= on from xxx.xxx.xx.xx port 64147: Permission denied >=20 >=20 > Is there any suggesions? > My environments are as follows: >=20 > - Server: >=20 > admin@kx:~ % uname -a > FreeBSD kx.truefc.org 12.0-CURRENT FreeBSD 12.0-CURRENT #13 r308871M: S= un Nov 20 15:51:21 JST 2016 admin@kx.truefc.org:/usr/obj/usr/src/sys/= XIJ amd64 > admin@kx:~ % ssh -V > OpenSSH_7.2p2, OpenSSL 1.0.2j-freebsd 26 Sep 2016 > admin@kx:~ %=20 >=20 > - Client: >=20 > kiri@kazu:~[995]% uname -a > FreeBSD kazu.pis 9.2-STABLE FreeBSD 9.2-STABLE #5 r259404M: Mon Dec 16 = 00:12:52 JST 2013 admin@kazu.pis:/usr/obj/usr/src/sys/GENERIC amd64 > kiri@kazu:~[996]% ssh -V > OpenSSH_6.2p2, OpenSSL 0.9.8y 5 Feb 2013 > kiri@kazu:~[997]%=20 >=20 >=20 > Best regards. >=20 >=20 > [1] https://www.gentoo.org/support/news-items/2015-08-13-openssh-weak-k= eys.html > [2] https://lists.freebsd.org/pipermail/freebsd-current/2016-August/062= 853.html >=20 > --- > KIRIYAMA Kazuhiko > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 Newer versions of OpenSSH, like the one shipped in 11.0 and 12-current, do not accept DSA keys anymore. You will need to use RSA keys, or the newer ECDSA or ED25519 key types. --=20 Allan Jude --oPpWlJaaXNbqBW8tJLlJMgqekJtn2cvH1-- --CXdVfMotnbxOCoC2X88lnEMiI1ncQONlt 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.22 (MingW32) iQIcBAEBAgAGBQJYNGiIAAoJEBmVNT4SmAt+5z8P/jdheApIM57VbOWurVh283ih qT1QlNDFSlikYGGD3SuDi38HtehRaIzNi8035EmlbNpAtyl8blM+VXIPCX+KfffR OH4rcnloQtXOcFDct1Yh5H8dQp6hbbm1XQoz+2s9v+W4VXFoUC0diQ6dZLqqqoIL fUbfit6Yf0+t8qpJ9EcGOfDnpN/fwPKgdcYpWzacxGcOncR5bsXHyC+TUralWN3Z vjN+vtvh/VnZ6H7gbGcCHxkGVcZsjUBohan9HzuJySFdadJ36wnAlj/gqXJMwQC7 AC+wsg3CHENhi/PJqTchIv+5Zt+eoIyWHRJS/VEKHgc4x4h5hNpAAMQDWuYSeI7n /jmJWbWCADRxQi8jBCpKBwpRzIM40CRzvN2U+5HegEEe0MTYC+g+Y4TyMSmR0AsW BJ9hup2QI92Lan7naR9ptxIT7GbLCcjB4J/EFfrUdhMgBHm1RATXR3HwVz0wTcmb Tm7goIrpCwrTmG1Eo0/cDY09K2WKc2FRERzo5yndmnVT6amvA+1eyd6C2nOKM80N S3XAZ12/3V5t/dtvjk9hR6ECUPYsohk04tTrYWhutP7kdwBuLCR71Gsi2MVXxIyH dtIyZw3l/ismLs3uzDXdx06lAzxcj1/CkwNRkRt35b+5an0pCuV+mykQrM4Oa85O f2OSKDolcpH/hRRfK1uc =xy4v -----END PGP SIGNATURE----- --CXdVfMotnbxOCoC2X88lnEMiI1ncQONlt-- From owner-freebsd-current@freebsd.org Wed Nov 23 08:24:41 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D1473C5144B for ; Wed, 23 Nov 2016 08:24:41 +0000 (UTC) (envelope-from kiri@kx.openedu.org) Received: from kx.openedu.org (flets-sg1027.kamome.or.jp [202.216.24.27]) (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 68E2BA81; Wed, 23 Nov 2016 08:24:40 +0000 (UTC) (envelope-from kiri@kx.openedu.org) Received: from kx.openedu.org (kx.openedu.org [103.15.187.19]) by kx.openedu.org (8.14.5/8.14.5) with ESMTP id uAN8OWbR096300; Wed, 23 Nov 2016 17:24:33 +0900 (JST) (envelope-from kiri@kx.openedu.org) Message-Id: <201611230824.uAN8OWbR096300@kx.openedu.org> Date: Wed, 23 Nov 2016 17:24:32 +0900 From: KIRIYAMA Kazuhiko To: Allan Jude Cc: freebsd-current@freebsd.org Subject: Re: fatal: Fssh_packet_write_poll: Connection from xxx.xxx.xx.xx port yyyyy: Permission denied In-Reply-To: <2b9b6473-fc17-3aad-ee1a-4c20b340ec00@freebsd.org> References: <201611220737.uAM7bMSY072062@kx.openedu.org> <2b9b6473-fc17-3aad-ee1a-4c20b340ec00@freebsd.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.6 MULE XEmacs/21.4 (patch 22) (Instant Classic) (amd64--freebsd) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 08:24:41 -0000 At Tue, 22 Nov 2016 10:47:17 -0500, Allan Jude wrote: > > [1 Re: fatal: Fssh_packet_write_poll: Connection from xxx.xxx.xx.xx port yyyyy: Permission denied ] > [1.1 ] > On 2016-11-22 02:37, KIRIYAMA Kazuhiko wrote: > > Hi, all > > > > I've updated to HEAD(r308871) at 2 days ago, and also ports > > too(r426562). Then all stuffs including applications have > > been updated and tried to slogin to this host,but can't > > connect with the message `userauth_pubkey: key type ssh-dss > > not in PubkeyAcceptedKeyTypes [preauth]' in > > /var/log/auth.log. I found new OpenSSH-7.* has not been > > supported DSA and to connect from client with old ssh(lower > > than OpenSSH-7.0),set `ssh-dss' or some values set to > > relevant variables in /etc/ssh/sshd_config. According to [1] > > and [2] I've set these variables as below: > > > > PubkeyAcceptedKeyTypes=+ssh-dss > > HostKeyAlgorithms=+ssh-dss > > KexAlgorithms=+diffie-hellman-group-exchange-sha256 > > > > and successfully slogined: > > > > snip > > > > > And with the message `fatal: Fssh_packet_write_poll: > > Connection from xxx.xxx.xx.xx port yyyyy: Permission denied' > > in /var/log/auth.log: > > > > > > Nov 22 16:07:51 kx sshd[73878]: Accepted publickey for admin from xxx.xxx.xx.xx port 64147 ssh2: DSA SHA256:6uPsONRWeNkYjlj9BU4GZYUUeH60ZbUCB25jolvrvj8 > > Nov 22 16:07:51 kx sshd[73880]: fatal: Fssh_packet_write_poll: Connection from xxx.xxx.xx.xx port 64147: Permission denied > > > > > > Is there any suggesions? > > My environments are as follows: > > > > - Server: > > > > admin@kx:~ % uname -a > > FreeBSD kx.truefc.org 12.0-CURRENT FreeBSD 12.0-CURRENT #13 r308871M: Sun Nov 20 15:51:21 JST 2016 admin@kx.truefc.org:/usr/obj/usr/src/sys/XIJ amd64 > > admin@kx:~ % ssh -V > > OpenSSH_7.2p2, OpenSSL 1.0.2j-freebsd 26 Sep 2016 > > admin@kx:~ % > > > > - Client: > > > > kiri@kazu:~[995]% uname -a > > FreeBSD kazu.pis 9.2-STABLE FreeBSD 9.2-STABLE #5 r259404M: Mon Dec 16 00:12:52 JST 2013 admin@kazu.pis:/usr/obj/usr/src/sys/GENERIC amd64 > > kiri@kazu:~[996]% ssh -V > > OpenSSH_6.2p2, OpenSSL 0.9.8y 5 Feb 2013 > > kiri@kazu:~[997]% > > > > > > Best regards. > > > > > > [1] https://www.gentoo.org/support/news-items/2015-08-13-openssh-weak-keys.html > > [2] https://lists.freebsd.org/pipermail/freebsd-current/2016-August/062853.html > > > > --- > > KIRIYAMA Kazuhiko > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > > Newer versions of OpenSSH, like the one shipped in 11.0 and 12-current, > do not accept DSA keys anymore. You will need to use RSA keys, or the > newer ECDSA or ED25519 key types. Yes indeed :) So I've generated RSA key and scp again,but failed: kiri@kazu:~[1012]% scp -vvv tfc:/jails/desktop/commonjail/home/kiri/projects/xemacs/xemacs-packages/sdoc-mode-1.10-pkg.tar.gz ~/projects/xemacs/xemacs-packages/sdoc-mode-1.10-pkg.tar.gz Executing: program /usr/bin/ssh host tfc, user (unspecified), command scp -v -f /jails/desktop/commonjail/home/kiri/projects/xemacs/xemacs-packages/sdoc-mode-1.10-pkg.tar.gz OpenSSH_6.2p2, OpenSSL 0.9.8y 5 Feb 2013 debug1: Reading configuration data /home/kiri/.ssh/config debug1: /home/kiri/.ssh/config line 13: Applying options for tfc debug1: Reading configuration data /etc/ssh/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to xx.xxxxxx.xxx [yyy.yyy.yy.yy] port zzzzz. debug1: Connection established. debug1: could not open key file '/etc/ssh/ssh_host_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_dsa_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_ecdsa_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_rsa_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_dsa_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_ecdsa_key': Permission denied debug1: could not open key file '/etc/ssh/ssh_host_rsa_key': Permission denied debug3: Incorrect RSA1 identifier debug3: Could not load "/home/kiri/.ssh/id_rsa" as a RSA1 public key debug1: identity file /home/kiri/.ssh/id_rsa type 1 debug1: identity file /home/kiri/.ssh/id_rsa-cert type -1 debug3: Incorrect RSA1 identifier debug3: Could not load "/home/kiri/.ssh/id_dsa" as a RSA1 public key debug1: identity file /home/kiri/.ssh/id_dsa type 2 debug1: identity file /home/kiri/.ssh/id_dsa-cert type -1 debug1: identity file /home/kiri/.ssh/id_ecdsa type -1 debug1: identity file /home/kiri/.ssh/id_ecdsa-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.2_hpn13v11 FreeBSD-20130515 debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2 FreeBSD-20160310 debug1: match: OpenSSH_7.2 FreeBSD-20160310 pat OpenSSH* debug1: Remote is not HPN-aware debug2: fd 3 setting O_NONBLOCK debug3: put_host_port: [xx.xxxxxx.xxx]:zzzzz debug3: ssh_load_hostkeys: loading entries for host "[xx.xxxxxx.xxx]:zzzzz" from file "/home/kiri/.ssh/known_hosts" debug3: ssh_load_hostkeys: found key type ECDSA in file /home/kiri/.ssh/known_hosts:170 debug3: ssh_load_hostkeys: loaded 1 keys debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1 debug2: kex_parse_kexinit: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-sha1-etm@openssh.com debug1: kex: server->client aes128-ctr hmac-sha1-etm@openssh.com none debug2: mac_setup: found hmac-sha1-etm@openssh.com debug1: kex: client->server aes128-ctr hmac-sha1-etm@openssh.com none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA 41:61:5e:8c:03:c7:70:c4:e7:d8:52:56:2a:36:86:21 debug3: put_host_port: [yyy.yyy.yy.yy]:zzzzz debug3: put_host_port: [xx.xxxxxx.xxx]:zzzzz debug3: ssh_load_hostkeys: loading entries for host "[xx.xxxxxx.xxx]:zzzzz" from file "/home/kiri/.ssh/known_hosts" debug3: ssh_load_hostkeys: found key type ECDSA in file /home/kiri/.ssh/known_hosts:170 debug3: ssh_load_hostkeys: loaded 1 keys debug1: Host '[xx.xxxxxx.xxx]:zzzzz' is known and matches the ECDSA host key. debug1: Found key in /home/kiri/.ssh/known_hosts:170 debug1: ssh_ecdsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/kiri/.ssh/id_rsa (0x8028540d0), debug2: key: /home/kiri/.ssh/id_dsa (0x802854100), debug2: key: /home/kiri/.ssh/id_ecdsa (0x0), debug1: Authentications that can continue: publickey,keyboard-interactive debug3: start over, passed a different list publickey,keyboard-interactive debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/kiri/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 279 debug2: input_userauth_pk_ok: fp 39:bd:18:5c:13:30:7b:dc:41:17:a1:1c:4e:9b:93:35 debug3: sign_and_send_pubkey: RSA 39:bd:18:5c:13:30:7b:dc:41:17:a1:1c:4e:9b:93:35 debug1: read PEM private key done: type RSA debug1: Authentication succeeded (publickey). Authenticated to xx.xxxxxx.xxx ([yyy.yyy.yy.yy]:zzzzz). debug2: fd 4 setting O_NONBLOCK debug2: fd 5 setting O_NONBLOCK debug1: HPN to Non-HPN Connection debug1: Final hpn_buffer_size = 2097152 debug1: HPN Disabled: 0, HPN Buffer Size: 2097152 debug1: channel 0: new [client-session] debug1: Enabled Dynamic Window Scaling debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0 debug2: callback start debug2: fd 3 setting TCP_NODELAY debug3: packet_set_tos: set IP_TOS 0x08 debug2: client_session2_setup: id 0 debug1: Sending command: scp -v -f /jails/desktop/commonjail/home/kiri/projects/xemacs/xemacs-packages/sdoc-mode-1.10-pkg.tar.gz debug2: channel 0: request exec confirm 1 debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: channel 0: rcvd adjust 2097152 debug2: channel_input_status_confirm: type 99 id 0 debug2: exec request accepted on channel 0 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: channel 0: rcvd ext data 58 debug2: tcpwinsz: 65894 for connection: 3 Sending file modes: C0644 16613 sdoc-mode-1.10-pkg.tar.gz debug2: channel 0: written 58 to efd 6 debug2: tcpwinsz: 65894 for connection: 3 Sink: C0644 16613 sdoc-mode-1.10-pkg.tar.gz debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 sdoc-mode-1.10-pkg.tar.gz 0% 0 0.0KB/s --:-- ETAdebug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 sdoc-mode-1.10-pkg.tar.gz 0% 0 0.0KB/s --:-- ETAdebug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 sdoc-mode-1.10-pkg.tar.gz 0% 0 0.0KB/s --:-- ETAdebug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug2: tcpwinsz: 65894 for connection: 3 debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cc -1) debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK Connection to xx.xxxxxx.xxx closed by remote host. Transferred: sent 3312, received 19332 bytes, in 2.4 seconds Bytes per second: sent 1401.1, received 8178.3 debug1: Exit status -1 lost connection kiri@kazu:~[1013]% I don't know why remote server send fingerprint with ECDSA. Remote sshd server configuration as below: root@kx:~ # sshd -T port xxxxx protocol 2 addressfamily any listenaddress 0.0.0.0:xxxxx listenaddress [::]:xxxxx usepam no serverkeybits 1024 logingracetime 120 keyregenerationinterval 3600 x11displayoffset 10 maxauthtries 6 maxsessions 10 clientaliveinterval 0 clientalivecountmax 3 streamlocalbindmask 0177 permitrootlogin no ignorerhosts yes ignoreuserknownhosts no rhostsrsaauthentication no hostbasedauthentication no hostbasedusesnamefrompacketonly no rsaauthentication yes pubkeyauthentication yes kerberosauthentication no kerberosorlocalpasswd yes kerberosticketcleanup yes gssapiauthentication no gssapicleanupcredentials yes passwordauthentication no kbdinteractiveauthentication yes challengeresponseauthentication yes printmotd yes x11forwarding yes x11uselocalhost yes permittty yes permituserrc yes strictmodes yes tcpkeepalive yes permitemptypasswords no permituserenvironment no uselogin no compression delayed gatewayports no usedns yes allowtcpforwarding yes allowagentforwarding yes allowstreamlocalforwarding yes useprivilegeseparation sandbox fingerprinthash SHA256 useblacklist no pidfile /var/run/sshd.pid xauthlocation /usr/local/bin/xauth ciphers chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc macs umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 versionaddendum FreeBSD-20160310 kexalgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1 hostbasedacceptedkeytypes ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa hostkeyalgorithms ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa pubkeyacceptedkeytypes ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa loglevel INFO syslogfacility AUTH authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2 hostkey /etc/ssh/ssh_host_rsa_key hostkey /etc/ssh/ssh_host_dsa_key hostkey /etc/ssh/ssh_host_ecdsa_key hostkey /etc/ssh/ssh_host_ed25519_key subsystem sftp /usr/libexec/sftp-server maxstartups 10:30:100 permittunnel no ipqos lowdelay throughput rekeylimit 0 0 permitopen any root@kx:~ # And local server sshd configuration as below: root@kazu:~ # sshd -T port 22 protocol 2 addressfamily any listenaddress [::]:22 listenaddress 0.0.0.0:22 usepam 0 serverkeybits 1024 logingracetime 120 keyregenerationinterval 3600 x11displayoffset 10 maxauthtries 6 maxsessions 10 clientaliveinterval 0 clientalivecountmax 3 permitrootlogin no ignorerhosts yes ignoreuserknownhosts no rhostsrsaauthentication yes hostbasedauthentication no hostbasedusesnamefrompacketonly no rsaauthentication yes pubkeyauthentication yes kerberosauthentication no kerberosorlocalpasswd yes kerberosticketcleanup yes gssapiauthentication no gssapicleanupcredentials yes passwordauthentication no kbdinteractiveauthentication yes challengeresponseauthentication yes printmotd yes printlastlog yes x11forwarding yes x11uselocalhost yes strictmodes yes tcpkeepalive yes permitemptypasswords no permituserenvironment no uselogin no compression delayed gatewayports no usedns yes allowtcpforwarding yes useprivilegeseparation yes pidfile /var/run/sshd.pid xauthlocation /usr/local/bin/xauth versionaddendum FreeBSD-20130515 loglevel INFO syslogfacility AUTH authorizedkeysfile .ssh/authorized_keys hostkey /etc/ssh/ssh_host_rsa_key hostkey /etc/ssh/ssh_host_dsa_key hostkey /etc/ssh/ssh_host_ecdsa_key authenticationmethods subsystem sftp /usr/libexec/sftp-server maxstartups 10:30:100 permittunnel no ipqos lowdelay throughput permitopen any root@kazu:~ # > > -- > Allan Jude > > [2 OpenPGP digital signature ] > --- KIRIYAMA Kazuhiko From owner-freebsd-current@freebsd.org Wed Nov 23 14:28:04 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 333E6C51C47; Wed, 23 Nov 2016 14:28:04 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 5F46317B6; Wed, 23 Nov 2016 14:28:03 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id AC9661FE024; Wed, 23 Nov 2016 15:28:00 +0100 (CET) Subject: Optimising generated rules for SAT solving (5/12 are duplicates) To: Baptiste Daroussin References: <20150414200459.GE39658@ivaldir.etoilebsd.net> <20150421103454.GR1394@zxy.spb.ru> <5593D0AE.2010205@selasky.org> <416359ce-1dcd-1160-5c56-f120a0f6358f@selasky.org> <20160627115533.gqvdsmtzwnvrrfuo@ivaldir.etoilebsd.net> <0671148b-d7cd-f8ad-906d-a0baa1b98cf5@selasky.org> Cc: Slawa Olhovchenkov , ports@FreeBSD.org, FreeBSD Current From: Hans Petter Selasky Message-ID: Date: Wed, 23 Nov 2016 15:27:44 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <0671148b-d7cd-f8ad-906d-a0baa1b98cf5@selasky.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 14:28:04 -0000 FYI I've made a patch to hopefully optimise SAT solving in our pkg utility. https://github.com/freebsd/pkg/issues/1505 --HPS From owner-freebsd-current@freebsd.org Wed Nov 23 16:28:14 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFE9CC511FA for ; Wed, 23 Nov 2016 16:28:14 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 86E24929 for ; Wed, 23 Nov 2016 16:28:14 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by mail-yw0-x235.google.com with SMTP id a10so15791322ywa.3 for ; Wed, 23 Nov 2016 08:28:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuxi-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a4dV1UNarGyWvGAdbsieWM7u5xFfV+yfdggkgGB9VE0=; b=DSVOtHXHRuPep45Z8mMAOjYSJxHUdobXoD93Vj4CR8oso7Dxj+IpFQjg22NttxO8b0 SJdUpD8EnoaLAKi+FBK5VaHmfVhWnN7ZDo1euW45I3RhK59SGxa6cof/iGxJ8v9ExL7x 7I5QcVSjf4X9xhSTYX6XYfNE6yK5RX1IPqf+aO72hyv8prTRKuVzP+XGMrdS8f2H8IPf 50LSsmEEYZDR25yb/UTh6Dy/1n6NamkSu/W3DntByDFzXOMgTt09cV9fdP5eV6ptUPg1 Hfdx6kM6PWxFJwp3+gMeoKkJuHPN4cxxw0wdRU/9DmrwDCSJ3FEh9a/Yj4bBy1Wwvwan TWtQ== 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; bh=a4dV1UNarGyWvGAdbsieWM7u5xFfV+yfdggkgGB9VE0=; b=D+obxhSEgR1siXREIWmcchw8Wd9jMdem+07b6ok9ZZS6mmeSVeGowVktWFp3kKIMxp oE7wanh5gGM7/ZMfacgfNNB+RlKmPGWv4w8YEnwDGPtS7x23LLbtJwV/kllzuoZClH35 aWHcpLgQXMKJ8gkvDDL6XnDJFsszq7dwkQubtm/oTGdFc+tlY6htSb/dQVoxVHuop8+F GlKieERZgNt6cT8eYe/Abt34K9QscMbtgnqsRTBEoLImJH0mpszIWxDgNS9Y7Fu5rHLt GPyd4ucFsTSQuBVJtKRYmgCdyu0NpbGdwkc5FJ9lWxYXvR9TJ39bH9GIwEvgBEzcZEdD 9iJw== X-Gm-Message-State: AKaTC03Q68dBjRHD5a1ptzvKcov/nIWiQ6KiKmUR5XZ3wAItFBAs8YV18ki5kqhcgcL6iIUy9EYKx5t86WamMg== X-Received: by 10.13.200.3 with SMTP id k3mr5012608ywd.173.1479918493472; Wed, 23 Nov 2016 08:28:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.31.213 with HTTP; Wed, 23 Nov 2016 08:27:42 -0800 (PST) In-Reply-To: References: <20150414200459.GE39658@ivaldir.etoilebsd.net> <20150421103454.GR1394@zxy.spb.ru> <5593D0AE.2010205@selasky.org> <416359ce-1dcd-1160-5c56-f120a0f6358f@selasky.org> <20160627115533.gqvdsmtzwnvrrfuo@ivaldir.etoilebsd.net> <0671148b-d7cd-f8ad-906d-a0baa1b98cf5@selasky.org> From: Ed Schouten Date: Wed, 23 Nov 2016 17:27:42 +0100 Message-ID: Subject: Re: Optimising generated rules for SAT solving (5/12 are duplicates) To: Hans Petter Selasky Cc: Baptiste Daroussin , Slawa Olhovchenkov , ports@freebsd.org, FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 16:28:14 -0000 Hi Hans, 2016-11-23 15:27 GMT+01:00 Hans Petter Selasky : > I've made a patch to hopefully optimise SAT solving in our pkg utility. Nice! Do you by any chance have any numbers that show the performance improvements made by this change? Assuming that the SAT solver of pkg(1) uses an algorithm similar to DPLL[1], a change like this would affect performance linearly. My guess is therefore that the running time is reduced by approximately 5/12. Is this correct? By the way, why attach a zip file with a diff? GitHub's pull requests are awesome! :-) [1] Davis-Putnam-Logemann-Loveland algorithm: https://en.wikipedia.org/wiki/DPLL_algorithm -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 From owner-freebsd-current@freebsd.org Wed Nov 23 16:41:55 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 53176C516F5; Wed, 23 Nov 2016 16:41:55 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::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 1522D1451; Wed, 23 Nov 2016 16:41:55 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 473061FE024; Wed, 23 Nov 2016 17:41:52 +0100 (CET) Subject: Re: Optimising generated rules for SAT solving (5/12 are duplicates) To: Ed Schouten References: <20150414200459.GE39658@ivaldir.etoilebsd.net> <20150421103454.GR1394@zxy.spb.ru> <5593D0AE.2010205@selasky.org> <416359ce-1dcd-1160-5c56-f120a0f6358f@selasky.org> <20160627115533.gqvdsmtzwnvrrfuo@ivaldir.etoilebsd.net> <0671148b-d7cd-f8ad-906d-a0baa1b98cf5@selasky.org> Cc: Baptiste Daroussin , Slawa Olhovchenkov , ports@freebsd.org, FreeBSD Current From: Hans Petter Selasky Message-ID: Date: Wed, 23 Nov 2016 17:41:34 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 16:41:55 -0000 On 11/23/16 17:27, Ed Schouten wrote: > Hi Hans, > > 2016-11-23 15:27 GMT+01:00 Hans Petter Selasky : >> I've made a patch to hopefully optimise SAT solving in our pkg utility. > > Nice! Do you by any chance have any numbers that show the performance > improvements made by this change? Hi Ed, I tried measuring with "time", but figured out that it was doing a lot of other stuff too. Isolating this piece of code was not so easy. > Assuming that the SAT solver of > pkg(1) uses an algorithm similar to DPLL[1], a change like this would > affect performance linearly. My guess is therefore that the running > time is reduced by approximately 5/12. Is this correct? > > By the way, why attach a zip file with a diff? GitHub's pull requests > are awesome! :-) GitHub wouldn't allow me to make a .diff attachment. > > [1] Davis-Putnam-Logemann-Loveland algorithm: > https://en.wikipedia.org/wiki/DPLL_algorithm > --HPS From owner-freebsd-current@freebsd.org Wed Nov 23 16:48:11 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D9EEC51A5D for ; Wed, 23 Nov 2016 16:48:11 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A38E1A50 for ; Wed, 23 Nov 2016 16:48:11 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by mail-yw0-x236.google.com with SMTP id a10so16319492ywa.3 for ; Wed, 23 Nov 2016 08:48:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuxi-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CZPu7cK1D8qfoFPNeofTDJ6oMJg9IlkGkvfySL1pJk4=; b=EWS7ezIZcxavVdvPuXRxJ8dh4lxs5LMPC47INHCUO7GEnN3XlYYl8GZgXcir9KQdsQ E+dYvFPMgWpXw1qW2gjDUaKS0Bkho7DxXwQKW0od9lSwZPKyMxq721CTXBNxBvTSix34 KmzW8UZdecf9xA7Vez1jy99vWAaooELW5t4Eh1QlA1uXBVQFGTH86AJ0ZQSbQxPw6W95 LIelUgk7qXP8lTb0fkCyhKC/sI3xRPTMjzVGe2BqxMw4PY8k8wWX6WP8YzVmEMWj4qzk y/nKKZ8acWNFaAsAZi9Gwp9YkB4lWC7S9aTWYNYNls2vADgxKiqIuGODKILhxI8hcWa6 pWxg== 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; bh=CZPu7cK1D8qfoFPNeofTDJ6oMJg9IlkGkvfySL1pJk4=; b=AmSJrc4lhWlME4OB4siCojxh3ETV3PnAoH4uFX31OFTj8Zm+4przLk7/17FuU7BXJD JEl0g+iIFefst5xlKTUvD3aJTH2SAS6o8v6IbWiA9XttEqwJN7JzJ0qmj/XPp82oWRF4 9Zl9UE58f+19DkzyNocaGtfIveDkpQSaqTimZ628L5BwnSeY6vtwrup46vxCkkahurmd HioxTYCN4QUYg9lQa2+SZm/dKBrG0bvayCrrWZ6N/fs0lY0Jv/518xGqeYihkV4U7rkb fOCgFib8RGsORVQIXF13uQhWXNkAMDJtIFAK7sVuoi/ihom18JUb22D/P9fmLXJ9uinW AGEg== X-Gm-Message-State: AKaTC01zq3i0qmNT8j0IHw15NUardgOU0VzWbsDpmJwALMLuWSs869PrlwsbDgHTXdly4sVx4bSEvHC2vjdodg== X-Received: by 10.129.153.137 with SMTP id q131mr4270691ywg.169.1479919690307; Wed, 23 Nov 2016 08:48:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.31.213 with HTTP; Wed, 23 Nov 2016 08:47:39 -0800 (PST) In-Reply-To: References: <20150414200459.GE39658@ivaldir.etoilebsd.net> <20150421103454.GR1394@zxy.spb.ru> <5593D0AE.2010205@selasky.org> <416359ce-1dcd-1160-5c56-f120a0f6358f@selasky.org> <20160627115533.gqvdsmtzwnvrrfuo@ivaldir.etoilebsd.net> <0671148b-d7cd-f8ad-906d-a0baa1b98cf5@selasky.org> From: Ed Schouten Date: Wed, 23 Nov 2016 17:47:39 +0100 Message-ID: Subject: Re: Optimising generated rules for SAT solving (5/12 are duplicates) To: Hans Petter Selasky Cc: Baptiste Daroussin , Slawa Olhovchenkov , ports@freebsd.org, FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 16:48:11 -0000 2016-11-23 17:41 GMT+01:00 Hans Petter Selasky : > GitHub wouldn't allow me to make a .diff attachment. But there's absolutely no need for doing that in the first place! :-) 1. Go to https://github.com/freebsd/pkg 2. Click 'Fork' on the top right. This will probably create a https://github.com/hselasky/pkg 3. Check out that repository using git(1), create a separate branch and commit the changes to the SAT solver. 4. Go to https://github.com/hselasky/pkg and click on 'New pull request'. 5. Fill in the form. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 From owner-freebsd-current@freebsd.org Wed Nov 23 16:47:17 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 56B15C519DF; Wed, 23 Nov 2016 16:47:17 +0000 (UTC) (envelope-from annulen@yandex.ru) Received: from forward2o.cmail.yandex.net (forward2o.cmail.yandex.net [IPv6:2a02:6b8:0:1a72::287]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D0BDE199F; Wed, 23 Nov 2016 16:47:16 +0000 (UTC) (envelope-from annulen@yandex.ru) Received: from mxback5o.mail.yandex.net (mxback5o.mail.yandex.net [37.140.190.19]) by forward2o.cmail.yandex.net (Yandex) with ESMTP id 382FA20F9E; Wed, 23 Nov 2016 19:47:13 +0300 (MSK) Received: from web11o.yandex.ru (web11o.yandex.ru [95.108.205.111]) by mxback5o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id wxNkHdSoMi-lClGarhH; Wed, 23 Nov 2016 19:47:12 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1479919632; bh=bWWKRV/MHw8bg4jmWGbIywmL45wQHGulk4GGglnFkM4=; h=From:To:Cc:In-Reply-To:References:Subject:Message-Id:Date; b=diky/FkuWMRsOGhdHSQIzk0lJ7K8MG7nd7ib8CAT8Tf+LDccduahm9cSmOgGG8MKX bVI1g1TA6NEATb6jPT/j0g2z2nwl+tNqwTY8BfVNTp58RZFMcNWIpZreZYRpb5iiqh IJyYcZJkdjytb08BvW38cFg0Exj0gpdoito8fIAA= Authentication-Results: mxback5o.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by web11o.yandex.ru with HTTP; Wed, 23 Nov 2016 19:47:12 +0300 From: Konstantin Tokarev To: Hans Petter Selasky , Ed Schouten Cc: "ports@freebsd.org" , Baptiste Daroussin , FreeBSD Current , Slawa Olhovchenkov In-Reply-To: References: <20150414200459.GE39658@ivaldir.etoilebsd.net> <20150421103454.GR1394@zxy.spb.ru> <5593D0AE.2010205@selasky.org> <416359ce-1dcd-1160-5c56-f120a0f6358f@selasky.org> <20160627115533.gqvdsmtzwnvrrfuo@ivaldir.etoilebsd.net> <0671148b-d7cd-f8ad-906d-a0baa1b98cf5@selasky.org> Subject: Re: Optimising generated rules for SAT solving (5/12 are duplicates) MIME-Version: 1.0 Message-Id: <402001479919632@web11o.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Wed, 23 Nov 2016 19:47:12 +0300 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 X-Mailman-Approved-At: Wed, 23 Nov 2016 17:43:30 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 16:47:17 -0000 23.11.2016, 19:42, "Hans Petter Selasky" : > On 11/23/16 17:27, Ed Schouten wrote: >>  Hi Hans, >> >>  2016-11-23 15:27 GMT+01:00 Hans Petter Selasky : >>>  I've made a patch to hopefully optimise SAT solving in our pkg utility. >> >>  Nice! Do you by any chance have any numbers that show the performance >>  improvements made by this change? > > Hi Ed, > > I tried measuring with "time", but figured out that it was doing a lot > of other stuff too. Isolating this piece of code was not so easy. > >  > Assuming that the SAT solver of >>  pkg(1) uses an algorithm similar to DPLL[1], a change like this would >>  affect performance linearly. My guess is therefore that the running >>  time is reduced by approximately 5/12. Is this correct? >> >>  By the way, why attach a zip file with a diff? GitHub's pull requests >>  are awesome! :-) > > GitHub wouldn't allow me to make a .diff attachment. If you really want to be nasty and not submit your change as a pull request, GitHub allows you to paste your patch as a comment: ```diff ``` > >>  [1] Davis-Putnam-Logemann-Loveland algorithm: >>  https://en.wikipedia.org/wiki/DPLL_algorithm > > --HPS > _______________________________________________ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" -- Regards, Konstantin From owner-freebsd-current@freebsd.org Thu Nov 24 05:17:27 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78299C52220 for ; Thu, 24 Nov 2016 05:17:27 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3391AE7B for ; Thu, 24 Nov 2016 05:17:27 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-qt0-x22e.google.com with SMTP id c47so31082198qtc.2 for ; Wed, 23 Nov 2016 21:17:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=gCd5Xzm28093aMea/K/rXFPY0FWvsniSS0KOj2gtDsc=; b=elXVQp1Qa2mnACI9+wQ2HLM6D96WpynYURLaKNl+G7ekmbsfd7CVMioUsXCVgc/P4v GSC4Ca0KZzfB/FbXSrv2FCG1j3S1DA/Rqa8rhGm55VimGl0knk8BeqXvSrloCoLnIqj3 00+PU1iRYBQpqN6/dAdbQOgjlY2mARhsmtnnJTw87WYbGYcvqsEwv2MpXRQU2WYGTQrx FUZEfD/ZUAMpt0kk9hIeMttq/rgAc50vYbduHfjBFF6Af2yZamlmyeHwUYURAWl2PPip 2x7bTIMj2ZO8rgNVtJfkFlu6FHv1R4W4xVDVTOcMySmeA3EhvQVJfxGC7QPzfXXgz/8J bVUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=gCd5Xzm28093aMea/K/rXFPY0FWvsniSS0KOj2gtDsc=; b=Ztr78UB0KpEAiO2FMrKew9zhBY65eABjwgyELaUIcklSmVRNL3GdywWd9gI4z35MRR 8YmcBpg0jlUW+8Fhyun5UYRK0kPlXnFzy9EehfFYZWgAdyaQS0SLxVrFzYd3Tx8CZ5JM lnmxgQULdCLFy8C+KPsCE0YtBMTUJwyAt2O2aEBKVmOoLfKMrWD07RsvQRUjjXVyfFFI U86uHD55oWtmnXRVNnEDPwzSEu0OGnj9yEBUySntUToFqVts7dia2AK+hkBbyaJMPdWK QZYu+OzBFCw9kndKb8kVWP4PfY++yyXXkWI9oLWq5RGDznJdbZP/lC6vrwgmcciHlXBQ 9v9w== X-Gm-Message-State: AKaTC03mYgeMxFZk+I6QNgRFdDFGnYdd2WWbUA7sbOsZSUq49g141cQ5v0YaboZQMVmvb7ietz/IEeUoIJcQZg== X-Received: by 10.200.48.28 with SMTP id f28mr428224qte.247.1479964646258; Wed, 23 Nov 2016 21:17:26 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.12.166.129 with HTTP; Wed, 23 Nov 2016 21:17:25 -0800 (PST) From: Alan Somers Date: Wed, 23 Nov 2016 22:17:25 -0700 X-Google-Sender-Auth: dMyK9cP2ZidTlDMhvn-_UqVa7lA Message-ID: Subject: NFSv4 performance degradation with 12.0-CURRENT client To: FreeBSD CURRENT Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 05:17:27 -0000 I have a FreeBSD 10.3-RELEASE-p12 server exporting its home directories over both NFSv3 and NFSv4. I have a TrueOS client (based on 12.0-CURRENT on the drm-next-4.7 branch, built on 28-October) mounting the home directories over NFSv4. At first, everything is fine and performance is good. But if the client does a buildworld using sources on NFS and locally stored objects, performance slowly degrades. The degradation is most noticeable with metadata-heavy operations. For example, "ls -l" in a directory with 153 files takes less than 0.1 seconds right after booting. But the longer the buildworld goes on, the slower it gets. Eventually that same "ls -l" takes 19 seconds. When the home directories are mounted over NFSv3 instead, I see no degradation. top shows negligible CPU consumption on the server, and very high consumption on the client when using NFSv4 (nearly 100%). The NFS-using process is spending almost all of its time in system mode, and dtrace shows that almost all of its time is spent in ncl_getpages(). I have delegations disabled on the server. On the client, the home directories are nullfs mounted to two additional locations, and the buildworld was actually using one of those nullfs mounts, not the NFS mount directly. Any ideas? -Alan From owner-freebsd-current@freebsd.org Thu Nov 24 09:08:16 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CCE04C53A7F for ; Thu, 24 Nov 2016 09:08:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 491CA9A0; Thu, 24 Nov 2016 09:08:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id uAO98BwJ069627 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 24 Nov 2016 11:08:11 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uAO98BwJ069627 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uAO98B6a069626; Thu, 24 Nov 2016 11:08:11 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 24 Nov 2016 11:08:11 +0200 From: Konstantin Belousov To: Alan Somers Cc: FreeBSD CURRENT Subject: Re: NFSv4 performance degradation with 12.0-CURRENT client Message-ID: <20161124090811.GO54029@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) 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.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 09:08:16 -0000 On Wed, Nov 23, 2016 at 10:17:25PM -0700, Alan Somers wrote: > I have a FreeBSD 10.3-RELEASE-p12 server exporting its home > directories over both NFSv3 and NFSv4. I have a TrueOS client (based > on 12.0-CURRENT on the drm-next-4.7 branch, built on 28-October) > mounting the home directories over NFSv4. At first, everything is > fine and performance is good. But if the client does a buildworld > using sources on NFS and locally stored objects, performance slowly > degrades. The degradation is most noticeable with metadata-heavy > operations. For example, "ls -l" in a directory with 153 files takes > less than 0.1 seconds right after booting. But the longer the > buildworld goes on, the slower it gets. Eventually that same "ls -l" > takes 19 seconds. When the home directories are mounted over NFSv3 > instead, I see no degradation. > > top shows negligible CPU consumption on the server, and very high > consumption on the client when using NFSv4 (nearly 100%). The > NFS-using process is spending almost all of its time in system mode, > and dtrace shows that almost all of its time is spent in > ncl_getpages(). > > I have delegations disabled on the server. On the client, the home > directories are nullfs mounted to two additional locations, and the > buildworld was actually using one of those nullfs mounts, not the NFS > mount directly. > > Any ideas? Try stock FreeBSD first. If reproducable on the stock HEAD, can you point to the lines of ncl_getpages() where the time is spent ? Does reading of the problematic files, as opposed to mmaping it, also cause the behaviour ? E.g. try dd. There is really no time-unbounded loops in the ncl_getpages() itself. I could understand the situation if e.g. time is spent in getpbuf() or ncl_readrpc(), but not in ncl_getpages() directly. Also, as an experiment, you could see if HEAD after r308980 demonstrates any difference. From owner-freebsd-current@freebsd.org Thu Nov 24 12:13:52 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CA726C53F9C; Thu, 24 Nov 2016 12:13:52 +0000 (UTC) (envelope-from vsevolod@highsecure.ru) Received: from mail.highsecure.ru (mail6.highsecure.ru [IPv6:2a01:4f8:190:43b5::99]) (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 8853E19B; Thu, 24 Nov 2016 12:13:52 +0000 (UTC) (envelope-from vsevolod@highsecure.ru) Received: from secret-bunker.localdomain (unknown [81.145.134.172]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: vsevolod@highsecure.ru) by mail.highsecure.ru (Postfix) with ESMTPSA id 300A2300A6E; Thu, 24 Nov 2016 13:13:40 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by secret-bunker.localdomain (Postfix) with ESMTP id A4A1B2D11F5A; Thu, 24 Nov 2016 12:13:39 +0000 (GMT) Subject: Re: Optimising generated rules for SAT solving (5/12 are duplicates) To: Ed Schouten , Hans Petter Selasky References: <20150414200459.GE39658@ivaldir.etoilebsd.net> <20150421103454.GR1394@zxy.spb.ru> <5593D0AE.2010205@selasky.org> <416359ce-1dcd-1160-5c56-f120a0f6358f@selasky.org> <20160627115533.gqvdsmtzwnvrrfuo@ivaldir.etoilebsd.net> <0671148b-d7cd-f8ad-906d-a0baa1b98cf5@selasky.org> Cc: Baptiste Daroussin , Slawa Olhovchenkov , ports@freebsd.org, FreeBSD Current From: Vsevolod Stakhov Message-ID: Date: Thu, 24 Nov 2016 12:13:39 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=highsecure.ru; s=dkim; t=1479989621; bh=IxRdE/0FY7Fb0Jn5PUPm/AeIZq5adcAa1pj/EIve62A=; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=j05lhEUOI72/Ai643oIq7IaeaP+5r3mukm7REIajYukLuZe87YXg30jxbb6P5wyM3SnoZJuwlkIU+kMGHBjbT0JvENtGF8kwzlfqSWbaDz13yKqAZn0W5L0DOVx0+x8l4ZAVPLeD7S6DUvV0WmqpdtSnjUVrgSFTPeqNRBY2UDY= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 12:13:52 -0000 On 23/11/2016 16:27, Ed Schouten wrote: > Hi Hans, > > 2016-11-23 15:27 GMT+01:00 Hans Petter Selasky : >> I've made a patch to hopefully optimise SAT solving in our pkg utility. > > Nice! Do you by any chance have any numbers that show the performance > improvements made by this change? Assuming that the SAT solver of > pkg(1) uses an algorithm similar to DPLL[1], a change like this would > affect performance linearly. My guess is therefore that the running > time is reduced by approximately 5/12. Is this correct? There won't be any improvement if you just remove duplicates from SAT formula. This situation is handled by picosat internally and even for naive DPLL there is no significant influence of duplicate KNF clauses: once you've assumed all vars in some clause, you automatically resolve all duplicates. Is there any real improvement of SAT solver speed with this patch? From my experiences, SAT solving is negligible in terms of CPU time comparing to other tasks performed by pkg. > By the way, why attach a zip file with a diff? GitHub's pull requests > are awesome! :-) > > [1] Davis-Putnam-Logemann-Loveland algorithm: > https://en.wikipedia.org/wiki/DPLL_algorithm > -- Vsevolod Stakhov From owner-freebsd-current@freebsd.org Thu Nov 24 12:53:47 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81AE3C513F3 for ; Thu, 24 Nov 2016 12:53:47 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0073.outbound.protection.outlook.com [207.46.100.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A675CE3; Thu, 24 Nov 2016 12:53:46 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0192.CANPRD01.PROD.OUTLOOK.COM (10.165.218.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.8; Thu, 24 Nov 2016 12:53:44 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0734.014; Thu, 24 Nov 2016 12:53:43 +0000 From: Rick Macklem To: Konstantin Belousov , Alan Somers CC: FreeBSD CURRENT Subject: Re: NFSv4 performance degradation with 12.0-CURRENT client Thread-Topic: NFSv4 performance degradation with 12.0-CURRENT client Thread-Index: AQHSRhIPtzL8Jj0C/0q6PJtKKLQgMaDn2GqAgAA8DvY= Date: Thu, 24 Nov 2016 12:53:43 +0000 Message-ID: References: , <20161124090811.GO54029@kib.kiev.ua> In-Reply-To: <20161124090811.GO54029@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0192; 7:i+lVTn/RVieqIEIgczmSZnXcIVREpcZcRvUruZlgTTOOm7uOxJSvs9nBMYZvGo83KRD9pXMUkoSAVsz2iYqvVt0FBxvAvSxeST3QkNm4OGB9kHa/0poFxLa4Ul/I3MpugpiB+gkytBXCEgdgce5IsdC9b6ocUAYxs/1fj+sXmryPkL8nbQ8LglS0OjYdlYrA71JDnILxsbEFY6Xj5vavo6lzhzxbhI2PsmNoBBifPYG/iSHKpydWBa1HCMmWC99ROe2nclfJ5FdAsoxrfMz5/PNBGkzkblbnhi5GROhZBZCjz70qoD6B/wj8NGNpZV83bmu3P4ZPv745zRytIbow+PrhHqhuEcBGGhGK/S1CryM= x-ms-office365-filtering-correlation-id: a209d3d1-cc75-48c3-59be-08d41468ec33 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:YTXPR01MB0192; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(6045199)(6040361)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6061324)(6041248)(2016111802025)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(6043046); SRVR:YTXPR01MB0192; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0192; x-forefront-prvs: 0136C1DDA4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(199003)(189002)(39380400001)(39410400001)(8676002)(39060400001)(5001770100001)(189998001)(8936002)(81166006)(86362001)(97736004)(38730400001)(74482002)(6506003)(229853002)(3660700001)(305945005)(4326007)(2906002)(74316002)(7846002)(68736007)(5890100001)(9686002)(81156014)(102836003)(92566002)(76176999)(54356999)(50986999)(77096005)(3280700002)(101416001)(2900100001)(33656002)(122556002)(105586002)(106356001)(106116001)(5660300001)(7696004)(2950100002)(39400400001)(21314002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0192; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2016 12:53:43.5533 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0192 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 12:53:47 -0000 On Wed, Nov 23, 2016 at 10:17:25PM -0700, Alan Somers wrote: > I have a FreeBSD 10.3-RELEASE-p12 server exporting its home > directories over both NFSv3 and NFSv4. I have a TrueOS client (based > on 12.0-CURRENT on the drm-next-4.7 branch, built on 28-October) > mounting the home directories over NFSv4. At first, everything is > fine and performance is good. But if the client does a buildworld > using sources on NFS and locally stored objects, performance slowly > degrades. The degradation is most noticeable with metadata-heavy > operations. For example, "ls -l" in a directory with 153 files takes > less than 0.1 seconds right after booting. But the longer the > buildworld goes on, the slower it gets. Eventually that same "ls -l" > takes 19 seconds. When the home directories are mounted over NFSv3 > instead, I see no degradation. > > top shows negligible CPU consumption on the server, and very high > consumption on the client when using NFSv4 (nearly 100%). The > NFS-using process is spending almost all of its time in system mode, > and dtrace shows that almost all of its time is spent in > ncl_getpages(). > A couple of things you could do when it slow (as well as what Kostik sugges= ted): - nfsstat -c -e on client and nfsstat -e -s on server, to see what RPCs are= being done and how quickly. (nfsstat -s -e will also show you how big the DRC is, al= though a large DRC should show up as increased CPU consumption on the server) - capture packets with tcpdump -s 0 -w test.pcap host - then you can email me test.pcap as an attachment. I can look at it in w= ireshark and see if there seem to protocol and/or TCP issues. (You can look at i= n wireshark yourself, the look for NFS4ERR_xxx, TCP segment retransmits...) If you are using either "intr" or "soft" on the mounts, try without those m= ount options. (The Bugs section of mount_nfs recommends against using them. If an RPC fai= ls due to these options, something called a seqid# can be "out of sync" between clie= nt/server and that causes serious problems.) --> These seqid#s are not used by NFSv4.1, so you could try that by adding "minorversion=3D1" to your mount options. Good luck with it, rick From owner-freebsd-current@freebsd.org Thu Nov 24 13:05:44 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A54AAC51861; Thu, 24 Nov 2016 13:05:44 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 4C88F37B; Thu, 24 Nov 2016 13:05:43 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 0F6181FE024; Thu, 24 Nov 2016 14:05:35 +0100 (CET) Subject: Re: Optimising generated rules for SAT solving (5/12 are duplicates) To: Vsevolod Stakhov , Ed Schouten References: <20150414200459.GE39658@ivaldir.etoilebsd.net> <20150421103454.GR1394@zxy.spb.ru> <5593D0AE.2010205@selasky.org> <416359ce-1dcd-1160-5c56-f120a0f6358f@selasky.org> <20160627115533.gqvdsmtzwnvrrfuo@ivaldir.etoilebsd.net> <0671148b-d7cd-f8ad-906d-a0baa1b98cf5@selasky.org> Cc: Baptiste Daroussin , Slawa Olhovchenkov , ports@freebsd.org, FreeBSD Current From: Hans Petter Selasky Message-ID: <9b0469bb-ab2b-4992-1d40-de748163f2c8@selasky.org> Date: Thu, 24 Nov 2016 14:05:18 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------6177813FFD2C97BC114024A6" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 13:05:44 -0000 This is a multi-part message in MIME format. --------------6177813FFD2C97BC114024A6 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 11/24/16 13:13, Vsevolod Stakhov wrote: > On 23/11/2016 16:27, Ed Schouten wrote: >> Hi Hans, >> >> 2016-11-23 15:27 GMT+01:00 Hans Petter Selasky : >>> I've made a patch to hopefully optimise SAT solving in our pkg utility. >> >> Nice! Do you by any chance have any numbers that show the performance >> improvements made by this change? Assuming that the SAT solver of >> pkg(1) uses an algorithm similar to DPLL[1], a change like this would >> affect performance linearly. My guess is therefore that the running >> time is reduced by approximately 5/12. Is this correct? > > There won't be any improvement if you just remove duplicates from SAT > formula. This situation is handled by picosat internally and even for > naive DPLL there is no significant influence of duplicate KNF clauses: > once you've assumed all vars in some clause, you automatically resolve > all duplicates. > > Is there any real improvement of SAT solver speed with this patch? From > my experiences, SAT solving is negligible in terms of CPU time comparing > to other tasks performed by pkg. Hi, I added some code to measure the time for SAT solving. During my test run I'm seeing values in the range 8-10ms for both versions, so I consider that neglible. However, the unpatched version wants to reinstall 185 packages while the non-patched version wants to reinstall 1 package. That has a huge time influential. I'm not that familar with PKG that I can draw any conclusions from this. # Test1: echo "n" | /xxx/pkg/src/pkg-static upgrade --no-repo-update > b.txt # Test2: echo "n" | env PKG_NO_SORT=YES /xxx/pkg/src/pkg-static upgrade --no-repo-update > a.txt Please find the material attached including a debug version patch you can play with. --HPS --------------6177813FFD2C97BC114024A6 Content-Type: text/plain; charset=UTF-8; name="b.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="b.txt" Checking for upgrades (748 candidates): .......... done Processing candidates (748 candidates): . done Skipped 3702 identical rules Reiterate SAT solving took 0s and 7370 usecs The following 52 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: xapian-core: 1.2.23,1 -> 1.2.24,1 webp: 0.5.0 -> 0.5.1_1 webkit2-gtk3: 2.8.5_6 -> 2.8.5_7 webkit-gtk2: 2.4.11_4 -> 2.4.11_5 vlc: 2.2.4_3,4 -> 2.2.4_4,4 trousers: 0.3.13_1 -> 0.3.14 tiff: 4.0.6_2 -> 4.0.7 thunderbird: 45.4.0_2 -> 45.5.0_1 sqlite3: 3.15.1 -> 3.15.1_1 spidermonkey170: 17.0.0_2 -> 17.0.0_3 soundtouch: 1.9.2 -> 1.9.2_1 raptor2: 2.0.15_4 -> 2.0.15_5 qt5-core: 5.6.2 -> 5.6.2_1 qt4-corelib: 4.8.7_5 -> 4.8.7_6 polkit: 0.113_1 -> 0.113_2 pciids: 20161029 -> 20161119 openimageio: 1.6.12_2 -> 1.6.12_3 openblas: 0.2.18_1,1 -> 0.2.18_2,1 openal-soft: 1.17.2 -> 1.17.2_1 libx264: 0.148.2708 -> 0.148.2708_1 libvpx: 1.6.0 -> 1.6.0_1 libvisio01: 0.1.5_3 -> 0.1.5_4 libreoffice: 5.2.3_2 -> 5.2.3_3 libpci: 3.5.1 -> 3.5.2 libmspub01: 0.1.2_4 -> 0.1.2_5 libfreehand: 0.1.1_3 -> 0.1.1_4 libe-book: 0.1.2_5 -> 0.1.2_6 libcdr01: 0.1.3_1 -> 0.1.3_2 lcms2: 2.7_2 -> 2.8 inkscape: 0.91_8 -> 0.91_9 icu: 57.1,1 -> 58.1,1 harfbuzz: 1.3.3 -> 1.3.3_1 gstreamer1-plugins: 1.8.0 -> 1.8.0_1 gstreamer-plugins: 0.10.36_6,3 -> 0.10.36_7,3 gstreamer: 0.10.36_4 -> 0.10.36_5 gnupg: 2.1.15 -> 2.1.16 glib: 2.46.2_3 -> 2.46.2_4 gcc: 4.8.5_2 -> 4.9.4 firefox: 50.0_2,1 -> 50.0_4,1 firebird25-client: 2.5.6_1 -> 2.5.6_2 ffmpeg: 2.8.8_5,1 -> 2.8.8_8,1 dejavu: 2.35 -> 2.37 chromium: 52.0.2743.116_2 -> 52.0.2743.116_4 boost-libs: 1.55.0_13 -> 1.55.0_14 blender: 2.77a -> 2.77a_1 belle-sip: 1.5.0 -> 1.5.0_1 bash: 4.4 -> 4.4.5 argyllcms: 1.7.0_1 -> 1.7.0_2 OpenEXR: 2.2.0_5 -> 2.2.0_6 ImageMagick: 6.9.5.10,1 -> 6.9.5.10_1,1 GraphicsMagick: 1.3.24,1 -> 1.3.24_1,1 Installed packages to be REINSTALLED: baresip-0.4.19 (options changed) Number of packages to be upgraded: 51 Number of packages to be reinstalled: 1 The process will require 19 MiB more space. 446 MiB to be downloaded. Proceed with this action? [y/N]: --------------6177813FFD2C97BC114024A6 Content-Type: text/plain; charset=UTF-8; name="a.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="a.txt" Checking for upgrades (748 candidates): .......... done Processing candidates (748 candidates): . done Reiterate SAT solving took 0s and 5790 usecs The following 236 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: xapian-core: 1.2.23,1 -> 1.2.24,1 webp: 0.5.0 -> 0.5.1_1 webkit2-gtk3: 2.8.5_6 -> 2.8.5_7 webkit-gtk2: 2.4.11_4 -> 2.4.11_5 vlc: 2.2.4_3,4 -> 2.2.4_4,4 trousers: 0.3.13_1 -> 0.3.14 tiff: 4.0.6_2 -> 4.0.7 thunderbird: 45.4.0_2 -> 45.5.0_1 sqlite3: 3.15.1 -> 3.15.1_1 spidermonkey170: 17.0.0_2 -> 17.0.0_3 soundtouch: 1.9.2 -> 1.9.2_1 raptor2: 2.0.15_4 -> 2.0.15_5 qt5-core: 5.6.2 -> 5.6.2_1 qt4-corelib: 4.8.7_5 -> 4.8.7_6 polkit: 0.113_1 -> 0.113_2 pciids: 20161029 -> 20161119 openimageio: 1.6.12_2 -> 1.6.12_3 openblas: 0.2.18_1,1 -> 0.2.18_2,1 openal-soft: 1.17.2 -> 1.17.2_1 libx264: 0.148.2708 -> 0.148.2708_1 libvpx: 1.6.0 -> 1.6.0_1 libvisio01: 0.1.5_3 -> 0.1.5_4 libreoffice: 5.2.3_2 -> 5.2.3_3 libpci: 3.5.1 -> 3.5.2 libmspub01: 0.1.2_4 -> 0.1.2_5 libfreehand: 0.1.1_3 -> 0.1.1_4 libe-book: 0.1.2_5 -> 0.1.2_6 libcdr01: 0.1.3_1 -> 0.1.3_2 lcms2: 2.7_2 -> 2.8 inkscape: 0.91_8 -> 0.91_9 icu: 57.1,1 -> 58.1,1 harfbuzz: 1.3.3 -> 1.3.3_1 gstreamer1-plugins: 1.8.0 -> 1.8.0_1 gstreamer-plugins: 0.10.36_6,3 -> 0.10.36_7,3 gstreamer: 0.10.36_4 -> 0.10.36_5 gnupg: 2.1.15 -> 2.1.16 glib: 2.46.2_3 -> 2.46.2_4 gcc: 4.8.5_2 -> 4.9.4 firefox: 50.0_2,1 -> 50.0_4,1 firebird25-client: 2.5.6_1 -> 2.5.6_2 ffmpeg: 2.8.8_5,1 -> 2.8.8_8,1 dejavu: 2.35 -> 2.37 chromium: 52.0.2743.116_2 -> 52.0.2743.116_4 boost-libs: 1.55.0_13 -> 1.55.0_14 blender: 2.77a -> 2.77a_1 belle-sip: 1.5.0 -> 1.5.0_1 bash: 4.4 -> 4.4.5 argyllcms: 1.7.0_1 -> 1.7.0_2 OpenEXR: 2.2.0_5 -> 2.2.0_6 ImageMagick: 6.9.5.10,1 -> 6.9.5.10_1,1 GraphicsMagick: 1.3.24,1 -> 1.3.24_1,1 Installed packages to be REINSTALLED: yaml-cpp03-0.3.0 yajl-2.1.0 xvid-1.3.4,1 xcb-util-renderutil-0.3.9_1 xcb-util-keysyms-0.4.0_1 xcb-util-0.4.0_1,1 twolame-0.3.13_4 tpm-emulator-0.7.4_1 tinyxml-2.6.2_1 taglib-1.10 startup-notification-0.12_4 speexdsp-1.2.r3_1 speex-1.2.r2,1 speech-dispatcher-0.8.3_1 spandsp-0.0.6 snappy-1.1.3 serf-1.3.9_1 schroedinger-1.0.11_4 redland-1.0.17_4 readline-6.3.8 re2-20151101 rasqal-0.9.33 qt5-x11extras-5.6.2 qt5-widgets-5.6.2 python35-3.5.2 python27-2.7.12 popt-1.16_1 poppler-glib-0.46.0 poppler-0.46.0_2 pixman-0.34.0 perl5-5.24.1.r4 pcre-8.39 pangomm-2.36.0 pango-1.38.0_1 p11-kit-0.23.2 orc-0.4.25 opus-1.1.3 opensubdiv-3.0.5_2 openldap-client-2.4.44 openjpeg15-1.5.2_1 openjpeg-2.1.2_1 opencv2-core-2.4.13.1_1 opencolorio-1.0.9 opencollada-1.6.25 nss-3.27.1_1 nspr-4.13.1 npth-1.2 nettle-3.2 mythes-1.2.4 mpfr-3.1.5 mpc-1.0.3 lua52-5.2.4 libxslt-1.1.29 libxml2-2.9.4 libxcb-1.12 libwps-0.4.4 libwpg03-0.3.1 libwpd010-0.10.1 libwmf-0.2.8.4_15 libvorbis-1.3.5,3 libvdpau-1.1.1 libva-1.7.2 libv4l-1.6.3_2 libtheora-1.1.1_6 libtasn1-4.9 libsoup-2.52.2 libsndfile-1.0.27 libsigc++-2.4.1 libsecret-0.18.4 libsamplerate-0.1.9 librsvg2-2.40.16 librevenge-0.0.4_1 libpthread-stubs-0.3_6 libpciaccess-0.13.4 libpaper-1.1.24.4 libpagemaker-0.0.3 libogg-1.3.2_1,4 libodfgen01-0.1.6 libmwaw03-0.3.8 libmpeg2-0.5.1_6 libmatroska-1.4.5 libmad-0.15.1b_6 libltdl-2.4.6 liblqr-1-0.4.2 libidn-1.33_1 libiconv-1.14_9 libgltf-0.0.2_1 libglapi-11.2.2 libgcrypt-1.7.3 libfpx-1.3.1.4_1 libffi-3.2.1 libexttextcat-3.4.4 libevent2-2.0.22_1 libetonyek01-0.1.6,1 libepoxy-1.3.1 libedit-3.1.20150325_2,1 libdvdread-5.0.3 libdvdnav-5.0.3 libdvbpsi-1.3.0 libdrm-2.4.66,1 libdca-0.0.5_1 libcroco-0.6.11 libcmis-0.5.1 libcddb-1.3.2_4 libassuan-2.4.3 libantlr3c-3.4_1 libabw-0.1.1_1 liba52-0.7.4_3 libXxf86vm-1.1.4_1 libXvMC-1.0.10 libXv-1.0.11,1 libXtst-1.2.3 libXt-1.1.5,1 libXrender-0.9.10 libXrandr-1.5.1 libXmu-1.1.2_3,1 libXinerama-1.1.3_3,1 libXi-1.7.8,1 libXft-2.3.2_1 libXfixes-5.0.3 libXext-1.3.3_1,1 libXdmcp-1.1.2 libXdamage-1.1.4_3 libXcursor-1.1.14_3 libXcomposite-0.4.4_3,1 libXaw-1.0.13,2 libXau-1.0.8_3 libXScrnSaver-1.2.2_3 libX11-1.6.4,1 libSM-1.2.2_3,1 libIDL-0.8.14_2 libICE-1.0.9_1,1 libGLU-9.0.0_2 libGL-11.2.2 libEGL-11.2.2 jpeg-turbo-1.5.1 jbigkit-2.1_1 jasper-1.900.1_16 ilmbase-2.2.0 hyphen-2.8.8 hunspell-1.3.3 gtkspell-2.0.16_5 gtkmm24-2.24.4_2 gtk3-3.18.8_3 gtk2-2.24.29_2 gstreamer1-1.8.0 gsl-1.16_2 gnutls-3.4.16 gmp-5.1.3_3 glibmm-2.44.0,1 glew-1.13.0 giflib-5.1.4 gettext-runtime-0.19.8.1 gdk-pixbuf2-2.32.3_1 gconf2-3.2.6_4 gbm-11.2.2 freetype2-2.6.3 fontconfig-2.12.1,1 flac-1.3.1_2 fftw3-3.3.5 faad2-2.7_6,1 expat-2.2.0 espeak-1.48.04_1 enchant-1.6.0_5 dotconf-1.3_1 dbus-glib-0.104 dbus-1.8.20 db5-5.3.28_6 curl-7.51.0_1 cups-2.2.1 colord-1.2.11_1 clucene-2.3.3.4_7 cairomm-1.10.0_3 cairo-1.14.6_1,2 boehm-gc-7.6.0 bctoolbox-0.2.0 baresip-0.4.19 (options changed) avahi-app-0.6.31_5 atkmm-2.22.7 atk-2.18.0 at-spi2-atk-2.18.1 apr-1.5.2.1.5.4_2 alsa-lib-1.1.2 ORBit2-2.14.19_1 CoinMP-1.8.3 Number of packages to be upgraded: 51 Number of packages to be reinstalled: 185 The process will require 19 MiB more space. 491 MiB to be downloaded. Proceed with this action? [y/N]: --------------6177813FFD2C97BC114024A6 Content-Type: text/x-patch; name="0001-Optimise-SAT-solving.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Optimise-SAT-solving.patch" >From 135812278d74a3dd632713885ba47daa05a2b175 Mon Sep 17 00:00:00 2001 From: Hans Petter Selasky Date: Thu, 24 Nov 2016 13:35:37 +0100 Subject: [PATCH] Optimise SAT solving. Signed-off-by: Hans Petter Selasky --- libpkg/pkg_solve.c | 317 ++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 315 insertions(+), 2 deletions(-) diff --git a/libpkg/pkg_solve.c b/libpkg/pkg_solve.c index 9cf08e2..d50281f 100644 --- a/libpkg/pkg_solve.c +++ b/libpkg/pkg_solve.c @@ -1074,8 +1074,299 @@ pkg_solve_set_initial_assumption(struct pkg_solve_problem *problem, } } -int -pkg_solve_sat_problem(struct pkg_solve_problem *problem) +static int +pkg_solve_item_compare(const void *ppa, const void *ppb) +{ + struct pkg_solve_item *ia = *(struct pkg_solve_item **)ppa; + struct pkg_solve_item *ib = *(struct pkg_solve_item **)ppb; + int va = ia->var->order * ia->inverse; + int vb = ib->var->order * ib->inverse; + + if (va > vb) + return (1); + else if (va < vb) + return (-1); + return (0); +} + +static int +pkg_solve_rule_compare(const void *ppa, const void *ppb) +{ + struct pkg_solve_rule *ra = *(struct pkg_solve_rule **)ppa; + struct pkg_solve_rule *rb = *(struct pkg_solve_rule **)ppb; + struct pkg_solve_item *ia; + struct pkg_solve_item *ib; + size_t na = 0; + size_t nb = 0; + + LL_FOREACH(ra->items, ia) + na++; + LL_FOREACH(rb->items, ib) + nb++; + + if (na > nb) + return (1); + else if (na < nb) + return (-1); + + ia = ra->items; + ib = rb->items; + while (ia != 0 && ib != 0) { + int va = ia->var->order * ia->inverse; + int vb = ib->var->order * ib->inverse; + if (va > vb) + return (1); + else if (va < vb) + return (-1); + ia = ia->next; + ib = ib->next; + } + return (0); +} + +static int +pkg_solve_sat_problem_sub(struct pkg_solve_problem *problem) +{ + struct pkg_solve_rule **rule_array; + struct pkg_solve_rule *rule; + struct pkg_solve_item *item; + int res, iter = 0; + size_t skipped = 0; + size_t i; + size_t n; + bool need_reiterate = false; + const int *failed = NULL; + int attempt = 0; + struct pkg_solve_variable *var; + + rule_array = (struct pkg_solve_rule **)calloc(kv_size(problem->rules), sizeof(void *)); + if (rule_array == NULL) + return (EPKG_FATAL); + + n = kv_size(problem->rules); + for (i = 0; i != n; i++) { + size_t j; + size_t k; + + rule = kv_A(problem->rules, i); + rule_array[i] = rule; + + j = 0; + LL_FOREACH(rule->items, item) + j++; + + struct pkg_solve_item *item_array[j]; + + j = 0; + LL_FOREACH(rule->items, item) + item_array[j++] = item; + + mergesort(item_array, j, sizeof(void *), pkg_solve_item_compare); + + rule->items = 0; + for (k = 0; k != j; k++) { + /* if items are identical, skip them */ + if (k != j - 1 && + pkg_solve_item_compare(item_array + k, item_array + k + 1) == 0) { + free(item_array[k]); + continue; + } + item_array[k]->next = rule->items; + rule->items = item_array[k]; + } + } + + mergesort(rule_array, n, sizeof(void *), pkg_solve_rule_compare); + + for (i = 0; i != n; i++) { + /* if rules are identical, skip them */ + if (i != n - 1 && + pkg_solve_rule_compare(rule_array + i, rule_array + i + 1) == 0) { + skipped++; + continue; + } + rule = rule_array[i]; + LL_FOREACH(rule->items, item) { + picosat_add(problem->sat, item->var->order * item->inverse); + } + + picosat_add(problem->sat, 0); + pkg_debug_print_rule(rule); + } + + for (i = 0; i != n; i++) { + /* if rules are identical, skip them */ + if (i != n - 1 && + pkg_solve_rule_compare(rule_array + i, rule_array + i + 1) == 0) + continue; + rule = rule_array[i]; + pkg_solve_set_initial_assumption(problem, rule); + } + + free(rule_array); + + pkg_emit_notice("Skipped %lld identical rules", (long long)skipped); + +reiterate: + pkg_emit_notice("Reiterate"); + + res = pkg_solve_picosat_iter(problem, iter); + + if (res != PICOSAT_SATISFIABLE) { + /* + * in case we cannot satisfy the problem it appears by + * experience that the culprit seems to always be the latest of + * listed in the failed assumptions. + * So try to remove them for the given problem. + * To avoid endless loop allow a maximum of 10 iterations no + * more + */ + failed = picosat_failed_assumptions(problem->sat); + attempt++; + + /* get the last failure */ + while (*failed) { + failed++; + } + failed--; + + if (attempt >= 10) { + pkg_emit_error("Cannot solve problem using SAT solver"); + UT_string *sb; + utstring_new(sb); + + while (*failed) { + var = &problem->variables[abs(*failed) - 1]; + for (i = 0; i < kv_size(problem->rules); i++) { + rule = kv_A(problem->rules, i); + + if (rule->reason != PKG_RULE_DEPEND) { + LL_FOREACH(rule->items, item) { + if (item->var == var) { + pkg_print_rule_buf(rule, sb); + utstring_printf(sb, "%c", '\n'); + break; + } + } + } + } + + utstring_printf(sb, "cannot %s package %s, remove it from request? ", + var->flags & PKG_VAR_INSTALL ? "install" : "remove", var->uid); + + if (pkg_emit_query_yesno(true, utstring_body(sb))) { + var->flags |= PKG_VAR_FAILED; + } + + failed++; + need_reiterate = true; + } + utstring_clear(sb); + } else { + pkg_emit_notice("Cannot solve problem using SAT solver, trying another plan"); + var = &problem->variables[abs(*failed) - 1]; + + var->flags |= PKG_VAR_FAILED; + + need_reiterate = true; + } + +#if 0 + failed = picosat_next_maximal_satisfiable_subset_of_assumptions(problem->sat); + + while (*failed) { + struct pkg_solve_variable *var = &problem->variables[*failed - 1]; + + pkg_emit_notice("var: %s", var->uid); + + failed ++; + } + + return (EPKG_AGAIN); +#endif + } + else { + + /* Assign vars */ + for (i = 0; i < problem->nvars; i ++) { + int val = picosat_deref(problem->sat, i + 1); + struct pkg_solve_variable *var = &problem->variables[i]; + + if (val > 0) + var->flags |= PKG_VAR_INSTALL; + else + var->flags &= ~PKG_VAR_INSTALL; + + pkg_debug(2, "decided %s %s-%s to %s", + var->unit->pkg->type == PKG_INSTALLED ? "local" : "remote", + var->uid, var->digest, + var->flags & PKG_VAR_INSTALL ? "install" : "delete"); + } + + /* Check for reiterations */ + if ((problem->j->type == PKG_JOBS_INSTALL || + problem->j->type == PKG_JOBS_UPGRADE) && iter == 0) { + for (i = 0; i < problem->nvars; i ++) { + bool failed_var = false; + struct pkg_solve_variable *var = &problem->variables[i], *cur; + + if (!(var->flags & PKG_VAR_INSTALL)) { + LL_FOREACH(var, cur) { + if (cur->flags & PKG_VAR_INSTALL) { + failed_var = false; + break; + } + else if (cur->unit->pkg->type == PKG_INSTALLED) { + failed_var = true; + } + } + } + + /* + * If we want to delete local packages on installation, do one more SAT + * iteration to ensure that we have no other choices + */ + if (failed_var) { + pkg_debug (1, "trying to delete local package %s-%s on install/upgrade," + " reiterate on SAT", + var->unit->pkg->name, var->unit->pkg->version); + need_reiterate = true; + + LL_FOREACH(var, cur) { + cur->flags |= PKG_VAR_FAILED; + } + } + } + } + } + + if (need_reiterate) { + iter ++; + + /* Restore top-level assumptions */ + for (i = 0; i < problem->nvars; i ++) { + struct pkg_solve_variable *var = &problem->variables[i]; + + if (var->flags & PKG_VAR_TOP) { + if (var->flags & PKG_VAR_FAILED) { + var->flags ^= PKG_VAR_INSTALL | PKG_VAR_FAILED; + } + + picosat_assume(problem->sat, var->order * + (var->flags & PKG_VAR_INSTALL ? 1 : -1)); + } + } + + need_reiterate = false; + + goto reiterate; + } + + return (EPKG_OK); +} + +static int +pkg_solve_sat_problem_old(struct pkg_solve_problem *problem) { struct pkg_solve_rule *rule; struct pkg_solve_item *item; @@ -1103,6 +1394,7 @@ pkg_solve_sat_problem(struct pkg_solve_problem *problem) } reiterate: + pkg_emit_notice("Reiterate"); res = pkg_solve_picosat_iter(problem, iter); @@ -1259,6 +1551,27 @@ reiterate: return (EPKG_OK); } +int +pkg_solve_sat_problem(struct pkg_solve_problem *problem) +{ + struct timeval tv0; + gettimeofday(&tv0, NULL); + int err; + + if (getenv("PKG_NO_SORT") != NULL) + err = pkg_solve_sat_problem_old(problem); + else + err = pkg_solve_sat_problem_sub(problem); + struct timeval tv1; + gettimeofday(&tv1, NULL); + + timersub(&tv1, &tv0, &tv1); + + pkg_emit_notice("SAT solving took %llds and %lld usecs", (long long)tv1.tv_sec, (long long)tv1.tv_usec); + + return (err); +} + void pkg_solve_dot_export(struct pkg_solve_problem *problem, FILE *file) { -- 2.10.1 --------------6177813FFD2C97BC114024A6-- From owner-freebsd-current@freebsd.org Thu Nov 24 13:11:46 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3A6C8C51B37; Thu, 24 Nov 2016 13:11:46 +0000 (UTC) (envelope-from vsevolod@highsecure.ru) Received: from mail.highsecure.ru (mail6.highsecure.ru [IPv6:2a01:4f8:190:43b5::99]) (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 C2F81BCB; Thu, 24 Nov 2016 13:11:45 +0000 (UTC) (envelope-from vsevolod@highsecure.ru) Received: from secret-bunker.localdomain (unknown [81.145.134.172]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: vsevolod@highsecure.ru) by mail.highsecure.ru (Postfix) with ESMTPSA id 7C6BF30068F; Thu, 24 Nov 2016 14:11:43 +0100 (CET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by secret-bunker.localdomain (Postfix) with ESMTP id 97A9B2D12A2C; Thu, 24 Nov 2016 13:11:42 +0000 (GMT) Subject: Re: Optimising generated rules for SAT solving (5/12 are duplicates) To: Hans Petter Selasky , Ed Schouten References: <20150414200459.GE39658@ivaldir.etoilebsd.net> <20150421103454.GR1394@zxy.spb.ru> <5593D0AE.2010205@selasky.org> <416359ce-1dcd-1160-5c56-f120a0f6358f@selasky.org> <20160627115533.gqvdsmtzwnvrrfuo@ivaldir.etoilebsd.net> <0671148b-d7cd-f8ad-906d-a0baa1b98cf5@selasky.org> <9b0469bb-ab2b-4992-1d40-de748163f2c8@selasky.org> Cc: Baptiste Daroussin , Slawa Olhovchenkov , ports@freebsd.org, FreeBSD Current From: Vsevolod Stakhov Message-ID: <8c5cb2ea-54ab-c91b-5859-b6a73a2a7005@highsecure.ru> Date: Thu, 24 Nov 2016 13:11:42 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <9b0469bb-ab2b-4992-1d40-de748163f2c8@selasky.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=highsecure.ru; s=dkim; t=1479993103; bh=WJ0yP2AOr+gEFsfnG8Coy/NwLjJZAMZQtUTMAVxEIzA=; h=Subject:To:References:Cc:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ZvlDSmo9y7ivwX/0voW+uqpGQILpy1U91mP2GR6/UYDJVmVH4CWP9/BjSh0BBqMsyNNnL7HEwqpIELbUC2plkkVBmb8VS+RBQgj0EQDWpIQFj4szp7oMY1JdWllobjd1+2uumxRfGPyaBbNx/NbpRKWdXczBF0RLdgWspuUZLmE= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 13:11:46 -0000 On 24/11/2016 13:05, Hans Petter Selasky wrote: > On 11/24/16 13:13, Vsevolod Stakhov wrote: >> On 23/11/2016 16:27, Ed Schouten wrote: >>> Hi Hans, >>> >>> 2016-11-23 15:27 GMT+01:00 Hans Petter Selasky : >>>> I've made a patch to hopefully optimise SAT solving in our pkg utility. >>> >>> Nice! Do you by any chance have any numbers that show the performance >>> improvements made by this change? Assuming that the SAT solver of >>> pkg(1) uses an algorithm similar to DPLL[1], a change like this would >>> affect performance linearly. My guess is therefore that the running >>> time is reduced by approximately 5/12. Is this correct? >> >> There won't be any improvement if you just remove duplicates from SAT >> formula. This situation is handled by picosat internally and even for >> naive DPLL there is no significant influence of duplicate KNF clauses: >> once you've assumed all vars in some clause, you automatically resolve >> all duplicates. >> >> Is there any real improvement of SAT solver speed with this patch? From >> my experiences, SAT solving is negligible in terms of CPU time comparing >> to other tasks performed by pkg. > > Hi, > > I added some code to measure the time for SAT solving. During my test > run I'm seeing values in the range 8-10ms for both versions, so I > consider that neglible. However, the unpatched version wants to > reinstall 185 packages while the non-patched version wants to reinstall > 1 package. That has a huge time influential. I'm not that familar with > PKG that I can draw any conclusions from this. > > # Test1: > echo "n" | /xxx/pkg/src/pkg-static upgrade --no-repo-update > b.txt > > # Test2: > echo "n" | env PKG_NO_SORT=YES /xxx/pkg/src/pkg-static upgrade > --no-repo-update > a.txt > Then I don't understand how your patch should affect the solving procedure. If pkg tries to reinstall something without *reason* it is a good sign of bug in pkg itself and/or your database/repo and not in SAT solver. I'll try to review your issue but I'll likely need your local packages database for this test. -- Vsevolod Stakhov From owner-freebsd-current@freebsd.org Thu Nov 24 13:12:42 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6F1CC51DC3; Thu, 24 Nov 2016 13:12:42 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 C2E50E85; Thu, 24 Nov 2016 13:12:41 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 952F81FE024; Thu, 24 Nov 2016 14:12:39 +0100 (CET) Subject: Re: Optimising generated rules for SAT solving (5/12 are duplicates) To: Vsevolod Stakhov , Ed Schouten References: <20150414200459.GE39658@ivaldir.etoilebsd.net> <20150421103454.GR1394@zxy.spb.ru> <5593D0AE.2010205@selasky.org> <416359ce-1dcd-1160-5c56-f120a0f6358f@selasky.org> <20160627115533.gqvdsmtzwnvrrfuo@ivaldir.etoilebsd.net> <0671148b-d7cd-f8ad-906d-a0baa1b98cf5@selasky.org> <9b0469bb-ab2b-4992-1d40-de748163f2c8@selasky.org> Cc: Baptiste Daroussin , Slawa Olhovchenkov , ports@freebsd.org, FreeBSD Current From: Hans Petter Selasky Message-ID: <7315b5a9-5b2d-ddcf-c98f-0578b1a83d73@selasky.org> Date: Thu, 24 Nov 2016 14:12:22 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <9b0469bb-ab2b-4992-1d40-de748163f2c8@selasky.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 13:12:42 -0000 On 11/24/16 14:05, Hans Petter Selasky wrote: > the non-patched version wants to reinstall 1 package. Spelling: patched version wants to reinstall 1 package only. --HPS From owner-freebsd-current@freebsd.org Thu Nov 24 13:15:25 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5786C51FAB; Thu, 24 Nov 2016 13:15:25 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (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 0D4DF157; Thu, 24 Nov 2016 13:15:25 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id D521E1FE024; Thu, 24 Nov 2016 14:15:22 +0100 (CET) Subject: Re: Optimising generated rules for SAT solving (5/12 are duplicates) To: Vsevolod Stakhov , Ed Schouten References: <20150414200459.GE39658@ivaldir.etoilebsd.net> <20150421103454.GR1394@zxy.spb.ru> <5593D0AE.2010205@selasky.org> <416359ce-1dcd-1160-5c56-f120a0f6358f@selasky.org> <20160627115533.gqvdsmtzwnvrrfuo@ivaldir.etoilebsd.net> <0671148b-d7cd-f8ad-906d-a0baa1b98cf5@selasky.org> <9b0469bb-ab2b-4992-1d40-de748163f2c8@selasky.org> <8c5cb2ea-54ab-c91b-5859-b6a73a2a7005@highsecure.ru> Cc: Baptiste Daroussin , Slawa Olhovchenkov , ports@freebsd.org, FreeBSD Current From: Hans Petter Selasky Message-ID: <6a81db90-40fa-ec5f-9402-333091c333f2@selasky.org> Date: Thu, 24 Nov 2016 14:15:06 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <8c5cb2ea-54ab-c91b-5859-b6a73a2a7005@highsecure.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 13:15:25 -0000 On 11/24/16 14:11, Vsevolod Stakhov wrote: > On 24/11/2016 13:05, Hans Petter Selasky wrote: >> On 11/24/16 13:13, Vsevolod Stakhov wrote: >>> On 23/11/2016 16:27, Ed Schouten wrote: >>>> Hi Hans, >>>> >>>> 2016-11-23 15:27 GMT+01:00 Hans Petter Selasky : >>>>> I've made a patch to hopefully optimise SAT solving in our pkg utility. >>>> >>>> Nice! Do you by any chance have any numbers that show the performance >>>> improvements made by this change? Assuming that the SAT solver of >>>> pkg(1) uses an algorithm similar to DPLL[1], a change like this would >>>> affect performance linearly. My guess is therefore that the running >>>> time is reduced by approximately 5/12. Is this correct? >>> >>> There won't be any improvement if you just remove duplicates from SAT >>> formula. This situation is handled by picosat internally and even for >>> naive DPLL there is no significant influence of duplicate KNF clauses: >>> once you've assumed all vars in some clause, you automatically resolve >>> all duplicates. >>> >>> Is there any real improvement of SAT solver speed with this patch? From >>> my experiences, SAT solving is negligible in terms of CPU time comparing >>> to other tasks performed by pkg. >> >> Hi, >> >> I added some code to measure the time for SAT solving. During my test >> run I'm seeing values in the range 8-10ms for both versions, so I >> consider that neglible. However, the unpatched version wants to >> reinstall 185 packages while the non-patched version wants to reinstall >> 1 package. That has a huge time influential. I'm not that familar with >> PKG that I can draw any conclusions from this. >> >> # Test1: >> echo "n" | /xxx/pkg/src/pkg-static upgrade --no-repo-update > b.txt >> >> # Test2: >> echo "n" | env PKG_NO_SORT=YES /xxx/pkg/src/pkg-static upgrade >> --no-repo-update > a.txt >> > > Then I don't understand how your patch should affect the solving > procedure. If pkg tries to reinstall something without *reason* it is a > good sign of bug in pkg itself and/or your database/repo and not in SAT > solver. > > I'll try to review your issue but I'll likely need your local packages > database for this test. > Hi, Maybe it is a bug somewhere. I noticed some rules repeating the same variable two times for example. Send me the list of files you need off-list. Thank you! --HPS From owner-freebsd-current@freebsd.org Thu Nov 24 14:15:39 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6EE06C51B26 for ; Thu, 24 Nov 2016 14:15:39 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3447FB1F for ; Thu, 24 Nov 2016 14:15:38 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by mail-yw0-x22a.google.com with SMTP id i145so40297820ywg.2 for ; Thu, 24 Nov 2016 06:15:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuxi-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wIyWl5W1kyPHbAS3dL22waOwPPGYWpL7PIAqBZSOjL4=; b=xTTuLrw4QBBdD6+0H24pXRcjb8y8kKwZzNPbfpg9I6iXbeNtiFDRnmXDD0naUpC/J7 5UFgF0s+QQaMMY3Vyj5DXbcgMqj07Rme1qAoVjbCLivB4BRN9hIAp314who7rsF5+tu4 SxQmOcPyT5RiWwZZf5ko7ViBX+/ywt6s6YO3ybESI2iWyQVtXPJyv+jlYjPmlm4jkTW8 7BBUVR1h/BXTaBd3NHIcrQ4k3ioOdbdqfHKTy+3FNj8ihhPGHSXTwwC0kbxRLv7IVJRQ WFLZ0t6pSRc3on70l1zT+Iakm29DTNDH8WR3qk87OEa/pTIyWFOX2aMaYskVpZX01NjD P92g== 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; bh=wIyWl5W1kyPHbAS3dL22waOwPPGYWpL7PIAqBZSOjL4=; b=G/omEzNd0bTGaHOjkqS65wriPZhU7fhD1AldtbqI6fF//rdHobM6VI3VrccNpQtmPQ JgmluP7G75G+TbjO6cS4JTMfgxPx3SdwoWOQndKGu6yToyi//MupJ3jowvA60m2y8onu pEW7ryGDiRWPWyIDZ+vP70P4y2myc8xI8v2pzKnhQPa1dmFRW5/lKwET5ThyNr0etIlQ 0mNJTPOlH6e520rRxZlMfDohWmqFEokVK8vrVpRLNkr3zPwZ8oS8yVcVHYaowGQcCa+5 KzBBISNpguz3ffSrJVXmIiU/7M7as8q+MNBYtVOCTv+0KpXFwX9efiUCI/pawHpPOF/B DOJQ== X-Gm-Message-State: AKaTC024IIOXx3RyzUiRHhc/CUgl51gqaZIa8yF8njAafPUzGLc+0ynxSL/c0oRfSQiBR4tHtKQR3qZOAhdc+w== X-Received: by 10.13.196.194 with SMTP id g185mr3326291ywd.138.1479996937757; Thu, 24 Nov 2016 06:15:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.31.213 with HTTP; Thu, 24 Nov 2016 06:15:07 -0800 (PST) In-Reply-To: References: <20150414200459.GE39658@ivaldir.etoilebsd.net> <20150421103454.GR1394@zxy.spb.ru> <5593D0AE.2010205@selasky.org> <416359ce-1dcd-1160-5c56-f120a0f6358f@selasky.org> <20160627115533.gqvdsmtzwnvrrfuo@ivaldir.etoilebsd.net> <0671148b-d7cd-f8ad-906d-a0baa1b98cf5@selasky.org> From: Ed Schouten Date: Thu, 24 Nov 2016 15:15:07 +0100 Message-ID: Subject: Re: Optimising generated rules for SAT solving (5/12 are duplicates) To: Vsevolod Stakhov Cc: Hans Petter Selasky , Baptiste Daroussin , Slawa Olhovchenkov , ports@freebsd.org, FreeBSD Current Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 14:15:39 -0000 2016-11-24 13:13 GMT+01:00 Vsevolod Stakhov : > On 23/11/2016 16:27, Ed Schouten wrote: >> Hi Hans, >> >> 2016-11-23 15:27 GMT+01:00 Hans Petter Selasky : >>> I've made a patch to hopefully optimise SAT solving in our pkg utility. >> >> Nice! Do you by any chance have any numbers that show the performance >> improvements made by this change? Assuming that the SAT solver of >> pkg(1) uses an algorithm similar to DPLL[1], a change like this would >> affect performance linearly. My guess is therefore that the running >> time is reduced by approximately 5/12. Is this correct? > > There won't be any improvement if you just remove duplicates from SAT > formula. This situation is handled by picosat internally and even for > naive DPLL there is no significant influence of duplicate KNF clauses: > once you've assumed all vars in some clause, you automatically resolve > all duplicates. Exactly. This is why I've stated: it affects performance linearly. Referring to Wikipedia's pseudo-code of the algorithm: the number of calls to unit-propagate() and pure-literal-assign() drops linearly, but the recursion will stay the same. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 From owner-freebsd-current@freebsd.org Thu Nov 24 18:42:43 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88828C53DCA for ; Thu, 24 Nov 2016 18:42:43 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4809B686 for ; Thu, 24 Nov 2016 18:42:43 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-qk0-x236.google.com with SMTP id q130so57339163qke.1 for ; Thu, 24 Nov 2016 10:42:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=e/xIEb9MjL1zBdYzzxNGxnFR+JKV6JwtId2PDZWYnQk=; b=uzHGX8rAMWsO4c7SRdhP0QmcjLMVVQTGz8+u3Azsl433r/iwbjOOoxT78QmTAGys8D j6jWU2xQRlBWAUNBdqn4uwoArxYn2U7VOMEcPXaFo3Jf/GJZu9X1mBQ3ocHdJ65W5YiT kh4X4Vt4huabOxnPe2aW+MgQZaebCCgZetmL07/vd6gpEHdK9wZPLMWRiAiBiaE44iX3 Cw0ofEn1yFfZ1SHA7+4jVj4DyXAYj8Si8fBlmYnZ3bRPClPAUvdH8iS7lTXsTJHziRWV xrb+a9n9ktFZDdmmGzpCRTVHEquRJ+uQts1u5mSMOLALC+ZP3SAK/s+7/zQ5dS0iD4fp KsGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=e/xIEb9MjL1zBdYzzxNGxnFR+JKV6JwtId2PDZWYnQk=; b=NEwjZUjpdZuyKMe/AGmHD2guhzkgUFlpu/bVUaT7Uw5FoYIWn2JHu4D81fxiGqi7Kq jkp3Sa9C/aX2690+b9o679XD/PswGj8zOJid0LvJUrDOVtYPLCIoM4xLcZ9KuYUIYdtr E9vYmduvQ56HTdnVEx2B6uDNEMLGr1n42VozM+mpA8dUsEEN5/f9+vBogbT4MguZxUqH y44NgwSk1V1nWiomkgBdamG3r68yiLKkB2prAEScLbIjyd36V+HKxnlCzbDgqGMxrQ+J v0xyIKP4WxuX/Eu0JWC1Pgv1tIBmu2Nw2WCm18vs7r4nzdqVzFxsBUeUegrZy4cpEabk AZ7Q== X-Gm-Message-State: AKaTC02xNi2wQs6nnHlu5te4atsxfM/c115tkv+u6hDjwkftO1QLkLy6/hQhcHsMzM2uYpMnzds33AYMKeuTFw== X-Received: by 10.55.104.208 with SMTP id d199mr3214037qkc.222.1480012962295; Thu, 24 Nov 2016 10:42:42 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.12.166.129 with HTTP; Thu, 24 Nov 2016 10:42:41 -0800 (PST) In-Reply-To: References: <20161124090811.GO54029@kib.kiev.ua> From: Alan Somers Date: Thu, 24 Nov 2016 11:42:41 -0700 X-Google-Sender-Auth: fki14GctE6bn_JVtiMd53awAgRY Message-ID: Subject: Re: NFSv4 performance degradation with 12.0-CURRENT client To: Rick Macklem Cc: Konstantin Belousov , FreeBSD CURRENT Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 18:42:43 -0000 On Thu, Nov 24, 2016 at 5:53 AM, Rick Macklem wrote: > > On Wed, Nov 23, 2016 at 10:17:25PM -0700, Alan Somers wrote: >> I have a FreeBSD 10.3-RELEASE-p12 server exporting its home >> directories over both NFSv3 and NFSv4. I have a TrueOS client (based >> on 12.0-CURRENT on the drm-next-4.7 branch, built on 28-October) >> mounting the home directories over NFSv4. At first, everything is >> fine and performance is good. But if the client does a buildworld >> using sources on NFS and locally stored objects, performance slowly >> degrades. The degradation is most noticeable with metadata-heavy >> operations. For example, "ls -l" in a directory with 153 files takes >> less than 0.1 seconds right after booting. But the longer the >> buildworld goes on, the slower it gets. Eventually that same "ls -l" >> takes 19 seconds. When the home directories are mounted over NFSv3 >> instead, I see no degradation. >> >> top shows negligible CPU consumption on the server, and very high >> consumption on the client when using NFSv4 (nearly 100%). The >> NFS-using process is spending almost all of its time in system mode, >> and dtrace shows that almost all of its time is spent in >> ncl_getpages(). >> > A couple of things you could do when it slow (as well as what Kostik suggested): > - nfsstat -c -e on client and nfsstat -e -s on server, to see what RPCs are being done > and how quickly. (nfsstat -s -e will also show you how big the DRC is, although a > large DRC should show up as increased CPU consumption on the server) > - capture packets with tcpdump -s 0 -w test.pcap host > - then you can email me test.pcap as an attachment. I can look at it in wireshark > and see if there seem to protocol and/or TCP issues. (You can look at in wireshark > yourself, the look for NFS4ERR_xxx, TCP segment retransmits...) > > If you are using either "intr" or "soft" on the mounts, try without those mount options. > (The Bugs section of mount_nfs recommends against using them. If an RPC fails due to > these options, something called a seqid# can be "out of sync" between client/server and > that causes serious problems.) > --> These seqid#s are not used by NFSv4.1, so you could try that by adding > "minorversion=1" to your mount options. > > Good luck with it, rick I've reproduced the issue on stock FreeBSD 12, and I've also learned that nullfs is a required factor. Doing the buildworld directly on the NFS mount doesn't cause any slowdown, but doing a buildworld on the nullfs copy of the NFS mount does. The slowdown affects the base NFS mount as well as the nullfs copy. Here is the nfsstat output for both server and client duing "ls -al" on the client: nfsstat -e -s -z Server Info: Getattr Setattr Lookup Readlink Read Write Create Remove 800 0 121 0 0 2 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 8 Mknod Fsstat Fsinfo PathConf Commit LookupP SetClId SetClIdCf 0 0 0 0 1 3 0 0 Open OpenAttr OpenDwnGr OpenCfrm DelePurge DeleRet GetFH Lock 0 0 0 0 0 0 123 0 LockT LockU Close Verify NVerify PutFH PutPubFH PutRootFH 0 0 0 0 0 674 0 0 Renew RestoreFH SaveFH Secinfo RelLckOwn V4Create 0 0 0 0 0 0 Server: Retfailed Faults Clients 0 0 0 OpenOwner Opens LockOwner Locks Delegs 0 0 0 0 0 Server Cache Stats: Inprog Idem Non-idem Misses CacheSize TCPPeak 0 0 0 674 16738 16738 nfsstat -e -c -z Client Info: Rpc Counts: Getattr Setattr Lookup Readlink Read Write Create Remove 60 0 119 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 3 Mknod Fsstat Fsinfo PathConf Commit SetClId SetClIdCf Lock 0 0 0 0 0 0 0 0 LockT LockU Open OpenCfr 0 0 0 0 OpenOwner Opens LockOwner Locks Delegs LocalOwn LocalOpen LocalLOwn 5638 141453 0 0 0 0 0 0 LocalLock 0 Rpc Info: TimedOut Invalid X Replies Retries Requests 0 0 0 0 662 Cache Info: Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits Misses 1275 58 837 121 0 0 0 0 BioRLHits Misses BioD Hits Misses DirE Hits Misses 1 0 6 0 1 0 And here are the most popular stack traces of "ls -al", as observed by dtrace. The number beneath each stack is the number of times dtrace observed that exact stack: kernel`bcmp+0x21 kernel`vinactive+0xc6 kernel`vputx+0x30e kernel`kern_statat+0x165 kernel`sys_fstatat+0x2c kernel`amd64_syscall+0x314 kernel`vputx+0x30e kernel`NDFREE+0xaa kernel`sys___acl_get_link+0x82 kernel`amd64_syscall+0x314 kernel`0xffffffff80eb95fb 96 kernel`nfscl_doclose+0x383 kernel`vinactive+0xc6 kernel`vputx+0x30e kernel`NDFREE+0xaa kernel`sys___acl_get_link+0x82 kernel`amd64_syscall+0x314 kernel`0xffffffff80eb95fb 183 kernel`nfscl_doclose+0x383 kernel`vinactive+0xc6 kernel`vputx+0x30e kernel`kern_statat+0x165 kernel`sys_fstatat+0x2c kernel`amd64_syscall+0x314 kernel`0xffffffff80eb95fb 189 kernel`lock_delay+0x52 kernel`nfs_lookup+0x337 kernel`VOP_LOOKUP_APV+0xda kernel`lookup+0x6a2 kernel`namei+0x57e kernel`sys___acl_get_link+0x55 kernel`amd64_syscall+0x314 kernel`0xffffffff80eb95fb 194 kernel`lock_delay+0x52 kernel`ncl_getattrcache+0x28 kernel`nfs_getattr+0x92 kernel`VOP_GETATTR_APV+0xda kernel`vn_stat+0xa3 kernel`kern_statat+0xde kernel`sys_fstatat+0x2c kernel`amd64_syscall+0x314 kernel`0xffffffff80eb95fb 196 What role could nullfs be playing? From owner-freebsd-current@freebsd.org Thu Nov 24 20:35:50 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1602C530C5 for ; Thu, 24 Nov 2016 20:35:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 411C4E85; Thu, 24 Nov 2016 20:35:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id uAOKZgF8058397 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 24 Nov 2016 22:35:42 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uAOKZgF8058397 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uAOKZgm4058394; Thu, 24 Nov 2016 22:35:42 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 24 Nov 2016 22:35:42 +0200 From: Konstantin Belousov To: Alan Somers Cc: Rick Macklem , FreeBSD CURRENT Subject: Re: NFSv4 performance degradation with 12.0-CURRENT client Message-ID: <20161124203542.GU54029@kib.kiev.ua> References: <20161124090811.GO54029@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) 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.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 20:35:50 -0000 On Thu, Nov 24, 2016 at 11:42:41AM -0700, Alan Somers wrote: > On Thu, Nov 24, 2016 at 5:53 AM, Rick Macklem wrote: > > > > On Wed, Nov 23, 2016 at 10:17:25PM -0700, Alan Somers wrote: > >> I have a FreeBSD 10.3-RELEASE-p12 server exporting its home > >> directories over both NFSv3 and NFSv4. I have a TrueOS client (based > >> on 12.0-CURRENT on the drm-next-4.7 branch, built on 28-October) > >> mounting the home directories over NFSv4. At first, everything is > >> fine and performance is good. But if the client does a buildworld > >> using sources on NFS and locally stored objects, performance slowly > >> degrades. The degradation is most noticeable with metadata-heavy > >> operations. For example, "ls -l" in a directory with 153 files takes > >> less than 0.1 seconds right after booting. But the longer the > >> buildworld goes on, the slower it gets. Eventually that same "ls -l" > >> takes 19 seconds. When the home directories are mounted over NFSv3 > >> instead, I see no degradation. > >> > >> top shows negligible CPU consumption on the server, and very high > >> consumption on the client when using NFSv4 (nearly 100%). The > >> NFS-using process is spending almost all of its time in system mode, > >> and dtrace shows that almost all of its time is spent in > >> ncl_getpages(). > >> > > A couple of things you could do when it slow (as well as what Kostik suggested): > > - nfsstat -c -e on client and nfsstat -e -s on server, to see what RPCs are being done > > and how quickly. (nfsstat -s -e will also show you how big the DRC is, although a > > large DRC should show up as increased CPU consumption on the server) > > - capture packets with tcpdump -s 0 -w test.pcap host > > - then you can email me test.pcap as an attachment. I can look at it in wireshark > > and see if there seem to protocol and/or TCP issues. (You can look at in wireshark > > yourself, the look for NFS4ERR_xxx, TCP segment retransmits...) > > > > If you are using either "intr" or "soft" on the mounts, try without those mount options. > > (The Bugs section of mount_nfs recommends against using them. If an RPC fails due to > > these options, something called a seqid# can be "out of sync" between client/server and > > that causes serious problems.) > > --> These seqid#s are not used by NFSv4.1, so you could try that by adding > > "minorversion=1" to your mount options. > > > > Good luck with it, rick > > I've reproduced the issue on stock FreeBSD 12, and I've also learned > that nullfs is a required factor. Doing the buildworld directly on > the NFS mount doesn't cause any slowdown, but doing a buildworld on > the nullfs copy of the NFS mount does. The slowdown affects the base > NFS mount as well as the nullfs copy. Here is the nfsstat output for > both server and client duing "ls -al" on the client: > > nfsstat -e -s -z > > Server Info: > Getattr Setattr Lookup Readlink Read Write Create Remove > 800 0 121 0 0 2 0 0 > Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access > 0 0 0 0 0 0 0 8 > Mknod Fsstat Fsinfo PathConf Commit LookupP SetClId SetClIdCf > 0 0 0 0 1 3 0 0 > Open OpenAttr OpenDwnGr OpenCfrm DelePurge DeleRet GetFH Lock > 0 0 0 0 0 0 123 0 > LockT LockU Close Verify NVerify PutFH PutPubFH PutRootFH > 0 0 0 0 0 674 0 0 > Renew RestoreFH SaveFH Secinfo RelLckOwn V4Create > 0 0 0 0 0 0 > Server: > Retfailed Faults Clients > 0 0 0 > OpenOwner Opens LockOwner Locks Delegs > 0 0 0 0 0 > Server Cache Stats: > Inprog Idem Non-idem Misses CacheSize TCPPeak > 0 0 0 674 16738 16738 > > nfsstat -e -c -z > Client Info: > Rpc Counts: > Getattr Setattr Lookup Readlink Read Write Create Remove > 60 0 119 0 0 0 0 0 > Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access > 0 0 0 0 0 0 0 3 > Mknod Fsstat Fsinfo PathConf Commit SetClId SetClIdCf Lock > 0 0 0 0 0 0 0 0 > LockT LockU Open OpenCfr > 0 0 0 0 > OpenOwner Opens LockOwner Locks Delegs LocalOwn LocalOpen LocalLOwn > 5638 141453 0 0 0 0 0 0 > LocalLock > 0 > Rpc Info: > TimedOut Invalid X Replies Retries Requests > 0 0 0 0 662 > Cache Info: > Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits Misses > 1275 58 837 121 0 0 0 0 > BioRLHits Misses BioD Hits Misses DirE Hits Misses > 1 0 6 0 1 0 > > And here are the most popular stack traces of "ls -al", as observed by > dtrace. The number beneath each stack is the number of times dtrace > observed that exact stack: > > kernel`bcmp+0x21 > kernel`vinactive+0xc6 > kernel`vputx+0x30e > kernel`kern_statat+0x165 > kernel`sys_fstatat+0x2c > kernel`amd64_syscall+0x314 > kernel`vputx+0x30e > kernel`NDFREE+0xaa > kernel`sys___acl_get_link+0x82 > kernel`amd64_syscall+0x314 > kernel`0xffffffff80eb95fb > 96 > > kernel`nfscl_doclose+0x383 > kernel`vinactive+0xc6 > kernel`vputx+0x30e > kernel`NDFREE+0xaa > kernel`sys___acl_get_link+0x82 > kernel`amd64_syscall+0x314 > kernel`0xffffffff80eb95fb > 183 > > kernel`nfscl_doclose+0x383 > kernel`vinactive+0xc6 > kernel`vputx+0x30e > kernel`kern_statat+0x165 > kernel`sys_fstatat+0x2c > kernel`amd64_syscall+0x314 > kernel`0xffffffff80eb95fb > 189 > > kernel`lock_delay+0x52 > kernel`nfs_lookup+0x337 > kernel`VOP_LOOKUP_APV+0xda > kernel`lookup+0x6a2 > kernel`namei+0x57e > kernel`sys___acl_get_link+0x55 > kernel`amd64_syscall+0x314 > kernel`0xffffffff80eb95fb > 194 > > kernel`lock_delay+0x52 > kernel`ncl_getattrcache+0x28 > kernel`nfs_getattr+0x92 > kernel`VOP_GETATTR_APV+0xda > kernel`vn_stat+0xa3 > kernel`kern_statat+0xde > kernel`sys_fstatat+0x2c > kernel`amd64_syscall+0x314 > kernel`0xffffffff80eb95fb > 196 > > What role could nullfs be playing? Can you check two things: 1. Does NFSv3 mount used with nullfs your way cause the same issue, or not ? You already said that NFSv3 somehow was not affected, but due to discovery that nullfs is part of the scenario, can you, please, confirm that still. 2. If you add nocache option to the nullfs mount which degrades, does the problem go away ? From owner-freebsd-current@freebsd.org Thu Nov 24 22:45:56 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61989C54558 for ; Thu, 24 Nov 2016 22:45:56 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0067.outbound.protection.outlook.com [65.55.169.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C3B0B152; Thu, 24 Nov 2016 22:45:54 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0192.CANPRD01.PROD.OUTLOOK.COM (10.165.218.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.8; Thu, 24 Nov 2016 22:45:52 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0734.014; Thu, 24 Nov 2016 22:45:52 +0000 From: Rick Macklem To: Alan Somers CC: Konstantin Belousov , FreeBSD CURRENT Subject: Re: NFSv4 performance degradation with 12.0-CURRENT client Thread-Topic: NFSv4 performance degradation with 12.0-CURRENT client Thread-Index: AQHSRhIPtzL8Jj0C/0q6PJtKKLQgMaDn2GqAgAA8DvaAAGR2gIAAPUCR Date: Thu, 24 Nov 2016 22:45:51 +0000 Message-ID: References: <20161124090811.GO54029@kib.kiev.ua> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0192; 7:B+T3xELcAzR+RWF4UOq+Dx6hg0pf7HBouNN1bF6iVhUG85qUQPhzA56dNs2gz885OmHm8V5uA8JkKWmlj+ybmqq2nIatlN/h6q6ieHDkYFd8kVW7FIEmSLJQLSJpKsse9ACSmQG4kqvrXRg2EsrSJUu/gbSvDwbZhr/WlskIWELpbJkTNZEM5TZNwbXeux+2u8D+/SK7Iuqtl/U9lFU42tzit+4EgzMhce5QrfplP416+YNMLM7CjbAEPffJcjq4CiOst45IlNanFEh6rdjFX/HK84JXz38exHkHCbnhU/V5yUm94ALVCjCNRcJgWDVysYodrfuQdsAw8C0KWGHO6EMY04o30b92GHHZkb9qQKA= x-ms-office365-filtering-correlation-id: 23e8d186-abc7-4f68-e939-08d414bba4c2 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:YTXPR01MB0192; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(6045199)(6040361)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6061324)(6041248)(2016111802025)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(6043046); SRVR:YTXPR01MB0192; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0192; x-forefront-prvs: 0136C1DDA4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(199003)(189002)(8676002)(39060400001)(86362001)(39380400001)(189998001)(39410400001)(81166006)(97736004)(74482002)(8936002)(229853002)(38730400001)(6506003)(4326007)(2906002)(7846002)(305945005)(74316002)(68736007)(81156014)(9686002)(102836003)(3660700001)(92566002)(3280700002)(50986999)(54356999)(77096005)(76176999)(101416001)(2900100001)(106356001)(122556002)(106116001)(105586002)(33656002)(7696004)(93886004)(5660300001)(110136003)(6916009)(39400400001)(2950100002)(39450400002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0192; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2016 22:45:51.9417 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0192 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 22:45:56 -0000 asomers@gmail.com wrote: [stuff snipped] >I've reproduced the issue on stock FreeBSD 12, and I've also learned >that nullfs is a required factor. Doing the buildworld directly on >the NFS mount doesn't cause any slowdown, but doing a buildworld on >the nullfs copy of the NFS mount does. The slowdown affects the base >NFS mount as well as the nullfs copy. Here is the nfsstat output for >both server and client duing "ls -al" on the client: > >nfsstat -e -s -z If you do this again, avoid using "-z" and I think you'll see the Opens (be= low Server:) going up and up... > >Server Info: > Getattr Setattr Lookup Readlink Read Write Create R= emove > 800 0 121 0 0 2 0 = 0 > Rename Link Symlink Mkdir Rmdir Readdir RdirPlus A= ccess > 0 0 0 0 0 0 0 = 8 > Mknod Fsstat Fsinfo PathConf Commit LookupP SetClId SetC= lIdCf > 0 0 0 0 1 3 0 = 0 > Open OpenAttr OpenDwnGr OpenCfrm DelePurge DeleRet GetFH = Lock > 0 0 0 0 0 0 123 = 0 > LockT LockU Close Verify NVerify PutFH PutPubFH PutR= ootFH > 0 0 0 0 0 674 0 = 0 > Renew RestoreFH SaveFH Secinfo RelLckOwn V4Create > 0 0 0 0 0 0 >Server: >Retfailed Faults Clients > 0 0 0 >OpenOwner Opens LockOwner Locks Delegs > 0 0 0 0 0 Oops, I think this is an nfsstats bug. I don't normally use "-z", so I didn= 't notice it clears these counts and it probably should not, since they are "how many= of these that are currently allocated". I'll check this. (Not relevant to this issue, but needs fixin.;-) >Server Cache Stats: > Inprog Idem Non-idem Misses CacheSize TCPPeak > 0 0 0 674 16738 16738 > >nfsstat -e -c -z >Client Info: >Rpc Counts: > Getattr Setattr Lookup Readlink Read Write Create Re= move > 60 0 119 0 0 0 0 = 0 > Rename Link Symlink Mkdir Rmdir Readdir RdirPlus A= ccess > 0 0 0 0 0 0 0 = 3 > Mknod Fsstat Fsinfo PathConf Commit SetClId SetClIdCf = Lock > 0 0 0 0 0 0 0 = 0 > LockT LockU Open OpenCfr > 0 0 0 0 >OpenOwner Opens LockOwner Locks Delegs LocalOwn LocalOpen Loca= lLOwn > 5638 141453 0 0 0 0 0 = 0 Ok, I think this shows us the problem. 141453 opens is a lot and the client= would have to chek these every time another open is done (there goes all that CPU;-). Now, why has this occurred? Well, the NFSv4 client can't close NFSv4 Opens on a vnode until that vnode'= s v_usecount goes to 0. This is because mmap'd files might do I/O after the f= ile descriptor is closed. Now, hopefully Kostik will know something about nullfs and can help with th= is. My guess is that nullfs ends up acquiring a refcnt on the NFS vnode so the v_usecount doesn't go to 0 and, therefore, the client never closes the NFSv= 4 Opens. Kostik, do you know if this is the case and whether or not it can be change= d? >LocalLock > 0 >Rpc Info: >TimedOut Invalid X Replies Retries Requests > 0 0 0 0 662 >Cache Info: >Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits M= isses > 1275 58 837 121 0 0 0 = 0 >BioRLHits Misses BioD Hits Misses DirE Hits Misses > 1 0 6 0 1 0 > [more stuff snipped] >What role could nullfs be playing? As noted above, my hunch is that is acquiring a refcnt on the NFS client vn= ode such that the v_usecount doesn't go to zero (at least for a long time) and witho= ut a VOP_INACTIVE() on the NFSv4 vnode, the NFSv4 Opens don't get closed and accumulate. (If that isn't correct, it is somehow interfering with the client Closing t= he NFSv4 Opens in some other way.) rick From owner-freebsd-current@freebsd.org Fri Nov 25 08:41:13 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68817C52798 for ; Fri, 25 Nov 2016 08:41:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 12610253; Fri, 25 Nov 2016 08:41:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id uAP8f7QW033413 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 25 Nov 2016 10:41:07 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uAP8f7QW033413 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uAP8f6tE033410; Fri, 25 Nov 2016 10:41:06 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 25 Nov 2016 10:41:06 +0200 From: Konstantin Belousov To: Rick Macklem Cc: Alan Somers , FreeBSD CURRENT Subject: Re: NFSv4 performance degradation with 12.0-CURRENT client Message-ID: <20161125084106.GX54029@kib.kiev.ua> References: <20161124090811.GO54029@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) 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.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 08:41:13 -0000 On Thu, Nov 24, 2016 at 10:45:51PM +0000, Rick Macklem wrote: > asomers@gmail.com wrote: > >OpenOwner Opens LockOwner Locks Delegs LocalOwn LocalOpen LocalLOwn > > 5638 141453 0 0 0 0 0 0 > Ok, I think this shows us the problem. 141453 opens is a lot and the client would have > to chek these every time another open is done (there goes all that CPU;-). > > Now, why has this occurred? > Well, the NFSv4 client can't close NFSv4 Opens on a vnode until that vnode's > v_usecount goes to 0. This is because mmap'd files might do I/O after the file > descriptor is closed. > Now, hopefully Kostik will know something about nullfs and can help with this. > My guess is that nullfs ends up acquiring a refcnt on the NFS vnode so the > v_usecount doesn't go to 0 and, therefore, the client never closes the NFSv4 Opens. > Kostik, do you know if this is the case and whether or not it can be changed? You are absolutely right. Nullfs vnode keeps a reference to the lower vnode which is below the nullfs one, i.e. to the nfs vnode in this case. If cache option is specified for the nullfs mount (default), the nullfs vnodes are cached normally to avoid the cost of creating and destroying nullfs vnode on each operation, and related cost of the exclusive locks on the lower vnode. An answer to my question in the previous mail to try with nocache option would give the confirmation. Really, I suspected that v_hash is calculated differently for NFSv3 and v4 mounts, but if opens are accumulated until use ref is dropped, that would explain things as well. Assuming your diagnosis is correct, are you in fact stating that the current VFS KPI is flawed ? It sounds as if either some another callback or counter needs to exist to track number of mapping references to the vm object of the vnode, in addition to VOP_OPEN/VOP_CLOSE ? Currently a rough estimation of the number of mappings, which is sometimes slightly wrong, can be obtained by the expression vp->v_object->ref_count - vp->v_object->shadow_count > >LocalLock > > 0 > >Rpc Info: > >TimedOut Invalid X Replies Retries Requests > > 0 0 0 0 662 > >Cache Info: > >Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits Misses > > 1275 58 837 121 0 0 0 0 > >BioRLHits Misses BioD Hits Misses DirE Hits Misses > > 1 0 6 0 1 0 > > > [more stuff snipped] > >What role could nullfs be playing? > As noted above, my hunch is that is acquiring a refcnt on the NFS client vnode such > that the v_usecount doesn't go to zero (at least for a long time) and without > a VOP_INACTIVE() on the NFSv4 vnode, the NFSv4 Opens don't get closed and > accumulate. > (If that isn't correct, it is somehow interfering with the client Closing the NFSv4 Opens > in some other way.) The following patch should automatically unset cache option for nullfs mounts over NFSv4 filesystem. diff --git a/sys/fs/nfsclient/nfs_clvfsops.c b/sys/fs/nfsclient/nfs_clvfsops.c index 524a372..a7e9fe3 100644 --- a/sys/fs/nfsclient/nfs_clvfsops.c +++ b/sys/fs/nfsclient/nfs_clvfsops.c @@ -1320,6 +1320,8 @@ out: MNT_ILOCK(mp); mp->mnt_kern_flag |= MNTK_LOOKUP_SHARED | MNTK_NO_IOPF | MNTK_USES_BCACHE; + if ((VFSTONFS(mp)->nm_flag & NFSMNT_NFSV4) != 0) + mp->mnt_kern_flag |= MNTK_NULL_NOCACHE; MNT_IUNLOCK(mp); } return (error); diff --git a/sys/fs/nullfs/null_vfsops.c b/sys/fs/nullfs/null_vfsops.c index 49bae28..de05e8b 100644 --- a/sys/fs/nullfs/null_vfsops.c +++ b/sys/fs/nullfs/null_vfsops.c @@ -188,7 +188,8 @@ nullfs_mount(struct mount *mp) } xmp->nullm_flags |= NULLM_CACHE; - if (vfs_getopt(mp->mnt_optnew, "nocache", NULL, NULL) == 0) + if (vfs_getopt(mp->mnt_optnew, "nocache", NULL, NULL) == 0 || + (xmp->nullm_vfs->mnt_kern_flag & MNTK_NULL_NOCACHE) != 0) xmp->nullm_flags &= ~NULLM_CACHE; MNT_ILOCK(mp); diff --git a/sys/sys/mount.h b/sys/sys/mount.h index 94cabb6..b6f9fec 100644 --- a/sys/sys/mount.h +++ b/sys/sys/mount.h @@ -370,7 +370,8 @@ void __mnt_vnode_markerfree_active(struct vnode **mvp, struct mount *); #define MNTK_SUSPEND 0x08000000 /* request write suspension */ #define MNTK_SUSPEND2 0x04000000 /* block secondary writes */ #define MNTK_SUSPENDED 0x10000000 /* write operations are suspended */ -#define MNTK_UNUSED1 0x20000000 +#define MNTK_NULL_NOCACHE 0x20000000 /* auto disable cache for nullfs + mounts over this fs */ #define MNTK_LOOKUP_SHARED 0x40000000 /* FS supports shared lock lookups */ #define MNTK_NOKNOTE 0x80000000 /* Don't send KNOTEs from VOP hooks */ From owner-freebsd-current@freebsd.org Fri Nov 25 13:57:31 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95C99C54289 for ; Fri, 25 Nov 2016 13:57:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0D1BC31B; Fri, 25 Nov 2016 13:57:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id uAPDvPNU060868 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 25 Nov 2016 15:57:26 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uAPDvPNU060868 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uAPDvP1w060867; Fri, 25 Nov 2016 15:57:25 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 25 Nov 2016 15:57:25 +0200 From: Konstantin Belousov To: Rick Macklem Cc: Alan Somers , FreeBSD CURRENT Subject: Re: NFSv4 performance degradation with 12.0-CURRENT client Message-ID: <20161125135725.GD54029@kib.kiev.ua> References: <20161124090811.GO54029@kib.kiev.ua> <20161125084106.GX54029@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) 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.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 13:57:31 -0000 On Fri, Nov 25, 2016 at 12:54:07PM +0000, Rick Macklem wrote: > Well, ideally theer would be a VOP_MMAPDONE() or something like that, which > would tell the NFSv4 client that I/O is done on the vnode so it can close it. > If there was some way for the NFSv4 VOP_CLOSE() to be able to tell if the file > has been mmap'd, that would help since it could close the ones that are not > mmap'd on the last descriptor close. > (A counter wouldn't be as useful, since NFSv4 would have to keep checking it to > see if it can do the close yet, but it might still be doable.) I thought that the issue was in tracking any opens and mmaps, but from this reply it is not that clear. Do you need callback when all opens and mmaps have ended, or only opens and mmaps for write ? If later, we already have a suitable mechanism VOP_ADD_WRITECOUNT(). From owner-freebsd-current@freebsd.org Fri Nov 25 15:34:51 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A72CC54F53 for ; Fri, 25 Nov 2016 15:34:51 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 C0F3F9D8; Fri, 25 Nov 2016 15:34:50 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1cAIWP-000ZKR-A5>; Fri, 25 Nov 2016 16:34:41 +0100 Received: from x55b3ada4.dyn.telefonica.de ([85.179.173.164] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1cAIWO-001ZrP-VT>; Fri, 25 Nov 2016 16:34:41 +0100 Date: Fri, 25 Nov 2016 16:34:31 +0100 From: "O. Hartmann" To: Konstantin Belousov Cc: Alan Somers , Rick Macklem , FreeBSD CURRENT Subject: Re: NFSv4 performance degradation with 12.0-CURRENT client Message-ID: <20161125163431.693b1ce0@thor.walstatt.dynvpn.de> In-Reply-To: <20161124203542.GU54029@kib.kiev.ua> References: <20161124090811.GO54029@kib.kiev.ua> <20161124203542.GU54029@kib.kiev.ua> Organization: FU Berlin MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/BJZ1.xZRQDmXQvrv71sbaAx"; protocol="application/pgp-signature" X-Originating-IP: 85.179.173.164 X-ZEDAT-Hint: A X-Mailman-Approved-At: Fri, 25 Nov 2016 15:41:39 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 15:34:51 -0000 --Sig_/BJZ1.xZRQDmXQvrv71sbaAx Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Thu, 24 Nov 2016 22:35:42 +0200 Konstantin Belousov schrieb: > On Thu, Nov 24, 2016 at 11:42:41AM -0700, Alan Somers wrote: > > On Thu, Nov 24, 2016 at 5:53 AM, Rick Macklem wr= ote: =20 > > > > > > On Wed, Nov 23, 2016 at 10:17:25PM -0700, Alan Somers wrote: =20 > > >> I have a FreeBSD 10.3-RELEASE-p12 server exporting its home > > >> directories over both NFSv3 and NFSv4. I have a TrueOS client (based > > >> on 12.0-CURRENT on the drm-next-4.7 branch, built on 28-October) > > >> mounting the home directories over NFSv4. At first, everything is > > >> fine and performance is good. But if the client does a buildworld > > >> using sources on NFS and locally stored objects, performance slowly > > >> degrades. The degradation is most noticeable with metadata-heavy > > >> operations. For example, "ls -l" in a directory with 153 files takes > > >> less than 0.1 seconds right after booting. But the longer the > > >> buildworld goes on, the slower it gets. Eventually that same "ls -l" > > >> takes 19 seconds. When the home directories are mounted over NFSv3 > > >> instead, I see no degradation. > > >> > > >> top shows negligible CPU consumption on the server, and very high > > >> consumption on the client when using NFSv4 (nearly 100%). The > > >> NFS-using process is spending almost all of its time in system mode, > > >> and dtrace shows that almost all of its time is spent in > > >> ncl_getpages(). > > >> =20 > > > A couple of things you could do when it slow (as well as what Kostik = suggested): > > > - nfsstat -c -e on client and nfsstat -e -s on server, to see what RP= Cs are being > > > done and how quickly. (nfsstat -s -e will also show you how big the D= RC is, > > > although a large DRC should show up as increased CPU consumption on t= he server) > > > - capture packets with tcpdump -s 0 -w test.pcap host > > > - then you can email me test.pcap as an attachment. I can look at i= t in wireshark > > > and see if there seem to protocol and/or TCP issues. (You can loo= k at in > > > wireshark yourself, the look for NFS4ERR_xxx, TCP segment retransmits= ...) > > > > > > If you are using either "intr" or "soft" on the mounts, try without t= hose mount > > > options. (The Bugs section of mount_nfs recommends against using them= . If an RPC > > > fails due to these options, something called a seqid# can be "out of = sync" between > > > client/server and that causes serious problems.) =20 > > > --> These seqid#s are not used by NFSv4.1, so you could try that by a= dding =20 > > > "minorversion=3D1" to your mount options. > > > > > > Good luck with it, rick =20 > >=20 > > I've reproduced the issue on stock FreeBSD 12, and I've also learned > > that nullfs is a required factor. Doing the buildworld directly on > > the NFS mount doesn't cause any slowdown, but doing a buildworld on > > the nullfs copy of the NFS mount does. The slowdown affects the base > > NFS mount as well as the nullfs copy. Here is the nfsstat output for > > both server and client duing "ls -al" on the client: > >=20 > > nfsstat -e -s -z > >=20 > > Server Info: > > Getattr Setattr Lookup Readlink Read Write Create = Remove > > 800 0 121 0 0 2 0 = 0 > > Rename Link Symlink Mkdir Rmdir Readdir RdirPlus = Access > > 0 0 0 0 0 0 0 = 8 > > Mknod Fsstat Fsinfo PathConf Commit LookupP SetClId S= etClIdCf > > 0 0 0 0 1 3 0 = 0 > > Open OpenAttr OpenDwnGr OpenCfrm DelePurge DeleRet GetFH = Lock > > 0 0 0 0 0 0 123 = 0 > > LockT LockU Close Verify NVerify PutFH PutPubFH P= utRootFH > > 0 0 0 0 0 674 0 = 0 > > Renew RestoreFH SaveFH Secinfo RelLckOwn V4Create > > 0 0 0 0 0 0 > > Server: > > Retfailed Faults Clients > > 0 0 0 > > OpenOwner Opens LockOwner Locks Delegs > > 0 0 0 0 0 > > Server Cache Stats: > > Inprog Idem Non-idem Misses CacheSize TCPPeak > > 0 0 0 674 16738 16738 > >=20 > > nfsstat -e -c -z > > Client Info: > > Rpc Counts: > > Getattr Setattr Lookup Readlink Read Write Create = Remove > > 60 0 119 0 0 0 0 = 0 > > Rename Link Symlink Mkdir Rmdir Readdir RdirPlus = Access > > 0 0 0 0 0 0 0 = 3 > > Mknod Fsstat Fsinfo PathConf Commit SetClId SetClIdCf = Lock > > 0 0 0 0 0 0 0 = 0 > > LockT LockU Open OpenCfr > > 0 0 0 0 > > OpenOwner Opens LockOwner Locks Delegs LocalOwn LocalOpen L= ocalLOwn > > 5638 141453 0 0 0 0 0 = 0 > > LocalLock > > 0 > > Rpc Info: > > TimedOut Invalid X Replies Retries Requests > > 0 0 0 0 662 > > Cache Info: > > Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits = Misses > > 1275 58 837 121 0 0 0 = 0 > > BioRLHits Misses BioD Hits Misses DirE Hits Misses > > 1 0 6 0 1 0 > >=20 > > And here are the most popular stack traces of "ls -al", as observed by > > dtrace. The number beneath each stack is the number of times dtrace > > observed that exact stack: > >=20 > > kernel`bcmp+0x21 > > kernel`vinactive+0xc6 > > kernel`vputx+0x30e > > kernel`kern_statat+0x165 > > kernel`sys_fstatat+0x2c > > kernel`amd64_syscall+0x314 > > kernel`vputx+0x30e > > kernel`NDFREE+0xaa > > kernel`sys___acl_get_link+0x82 > > kernel`amd64_syscall+0x314 > > kernel`0xffffffff80eb95fb > > 96 > >=20 > > kernel`nfscl_doclose+0x383 > > kernel`vinactive+0xc6 > > kernel`vputx+0x30e > > kernel`NDFREE+0xaa > > kernel`sys___acl_get_link+0x82 > > kernel`amd64_syscall+0x314 > > kernel`0xffffffff80eb95fb > > 183 > >=20 > > kernel`nfscl_doclose+0x383 > > kernel`vinactive+0xc6 > > kernel`vputx+0x30e > > kernel`kern_statat+0x165 > > kernel`sys_fstatat+0x2c > > kernel`amd64_syscall+0x314 > > kernel`0xffffffff80eb95fb > > 189 > >=20 > > kernel`lock_delay+0x52 > > kernel`nfs_lookup+0x337 > > kernel`VOP_LOOKUP_APV+0xda > > kernel`lookup+0x6a2 > > kernel`namei+0x57e > > kernel`sys___acl_get_link+0x55 > > kernel`amd64_syscall+0x314 > > kernel`0xffffffff80eb95fb > > 194 > >=20 > > kernel`lock_delay+0x52 > > kernel`ncl_getattrcache+0x28 > > kernel`nfs_getattr+0x92 > > kernel`VOP_GETATTR_APV+0xda > > kernel`vn_stat+0xa3 > > kernel`kern_statat+0xde > > kernel`sys_fstatat+0x2c > > kernel`amd64_syscall+0x314 > > kernel`0xffffffff80eb95fb > > 196 > >=20 > > What role could nullfs be playing? =20 >=20 > Can you check two things: > 1. Does NFSv3 mount used with nullfs your way cause the same issue, or no= t ? > You already said that NFSv3 somehow was not affected, but due to > discovery that nullfs is part of the scenario, can you, please, confirm > that still. > 2. If you add nocache option to the nullfs mount which degrades, does the > problem go away ? > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" I'm curious if this problem could also affect "poudriere" if related to nul= lfs. --Sig_/BJZ1.xZRQDmXQvrv71sbaAx Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmeBi/TL7Cfr+/54/6AFwPsD/k3wFAlg4WgcACgkQ6AFwPsD/ k3yYXQf+IAI5FYcnC59lB5fXMYmpflTJLmlB1eRVU6Em8n1fHfmxhIaIJbosLdGo Jg2+hirLdk79ViSC8jqwYVTOy8fFfp426T33UlvbUKJHz9pQMErw/7A+QBUcyipu nMqZZA06Mi7AGtU112QaxeQXWO9VxRajfW2Jxu6qURgUs7qM5VybgkeLbTOb9sUL m9g+fXsKnScVDhrB1kRfbBcAx6DMuHnym53HJ+xzHS/8OCHw7rpRVaIHqfM2NVMm HhCEe19BHhDWYe7kriI/HR80eFdZTnp1pK00knYuXc58Zd0fGmqPwXu8vraT8+tr NQfDFiw4XfIqXnxXulZAiFPO2nyBZg== =5mzf -----END PGP SIGNATURE----- --Sig_/BJZ1.xZRQDmXQvrv71sbaAx-- From owner-freebsd-current@freebsd.org Fri Nov 25 16:27:28 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79829C5521D for ; Fri, 25 Nov 2016 16:27:28 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0057.outbound.protection.outlook.com [65.55.169.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CD669BB5; Fri, 25 Nov 2016 16:27:27 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0191.CANPRD01.PROD.OUTLOOK.COM (10.165.218.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.8; Fri, 25 Nov 2016 12:54:07 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0734.014; Fri, 25 Nov 2016 12:54:07 +0000 From: Rick Macklem To: Konstantin Belousov CC: Alan Somers , FreeBSD CURRENT Subject: Re: NFSv4 performance degradation with 12.0-CURRENT client Thread-Topic: NFSv4 performance degradation with 12.0-CURRENT client Thread-Index: AQHSRhIPtzL8Jj0C/0q6PJtKKLQgMaDn2GqAgAA8DvaAAGR2gIAAPUCRgACtAACAAEDk+w== Date: Fri, 25 Nov 2016 12:54:07 +0000 Message-ID: References: <20161124090811.GO54029@kib.kiev.ua> , <20161125084106.GX54029@kib.kiev.ua> In-Reply-To: <20161125084106.GX54029@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-microsoft-exchange-diagnostics: 1; YTXPR01MB0191; 7:sL9s3+/xPzFcGglA6ptksDBcjAjZfiyhEuKuzgXwVeHZQrGdkdQHzH9pzsKGwOziFneHlBhLHAd8GBhTGmzQ6VRDWikMy5YBVMnsZesmGQhN0kNy33wKQhQWjEIrAGBvMS4rypHD+zUiFllGqBv+k/ihYWGoI2N914dccSmA1mJ4MiahPTULsnJ+hE5N06L+1ML5jtNzmWkRoSJ/sexoinrieyvV5hVjAx4mGi8S+InxTLxe4FXrRZacWZ2sIx8LBC9Rqa0/EOx0pd2iNypXHan0qSIIqqv9IvDwS0VXc7POdQMaoC79ig04sqTQ5bxN4uifLNRfH7T67M0/jcDGqn7nvzrNKM0+oaNf6OZeFDM= x-ms-office365-filtering-correlation-id: 856dee4b-f28f-43ab-a19f-08d415322497 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:YTXPR01MB0191; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6045199)(6060326)(6040361)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(6061324)(2016111802025)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(6043046); SRVR:YTXPR01MB0191; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0191; x-forefront-prvs: 01371B902F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(24454002)(199003)(38730400001)(101416001)(81156014)(81166006)(7846002)(68736007)(77096005)(74316002)(39410400001)(39380400001)(2900100001)(8936002)(97736004)(229853002)(92566002)(6506003)(93886004)(74482002)(2906002)(189998001)(39060400001)(4326007)(3280700002)(8676002)(2950100002)(1411001)(39450400002)(86362001)(3660700001)(122556002)(6916009)(105586002)(106356001)(110136003)(54356999)(7696004)(102836003)(106116001)(50986999)(5660300001)(76176999)(305945005)(9686002)(33656002)(39400400001); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0191; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2016 12:54:07.0936 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0191 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 16:27:28 -0000 Konstantin Belousov wrote: >On Thu, Nov 24, 2016 at 10:45:51PM +0000, Rick Macklem wrote: >> asomers@gmail.com wrote: >> >OpenOwner Opens LockOwner Locks Delegs LocalOwn LocalOpen L= ocalLOwn >> > 5638 141453 0 0 0 0 0 = 0 >> Ok, I think this shows us the problem. 141453 opens is a lot and the cli= ent would have >> to chek these every time another open is done (there goes all that CPU;-= ). >> >> Now, why has this occurred? >> Well, the NFSv4 client can't close NFSv4 Opens on a vnode until that vno= de's >> v_usecount goes to 0. This is because mmap'd files might do I/O after th= e file >> descriptor is closed. >> Now, hopefully Kostik will know something about nullfs and can help with= this. >> My guess is that nullfs ends up acquiring a refcnt on the NFS vnode so t= he >> v_usecount doesn't go to 0 and, therefore, the client never closes the N= FSv4 Opens. >> Kostik, do you know if this is the case and whether or not it can be cha= nged? >You are absolutely right. Nullfs vnode keeps a reference to the lower >vnode which is below the nullfs one, i.e. to the nfs vnode in this case. >If cache option is specified for the nullfs mount (default), the nullfs >vnodes are cached normally to avoid the cost of creating and destroying >nullfs vnode on each operation, and related cost of the exclusive locks >on the lower vnode. > >An answer to my question in the previous mail to try with nocache >option would give the confirmation. Really, I suspected that v_hash >is calculated differently for NFSv3 and v4 mounts, but if opens are >accumulated until use ref is dropped, that would explain things as well. Hopefully Alan can test this and let us know if "nocache" on the nullfs mou= nt fixes the problem. >Assuming your diagnosis is correct, are you in fact stating that the >current VFS KPI is flawed ? It sounds as if either some another callback >or counter needs to exist to track number of mapping references to the >vm object of the vnode, in addition to VOP_OPEN/VOP_CLOSE ? > >Currently a rough estimation of the number of mappings, which is sometimes >slightly wrong, can be obtained by the expression > vp->v_object->ref_count - vp->v_object->shadow_count Well, ideally theer would be a VOP_MMAPDONE() or something like that, which would tell the NFSv4 client that I/O is done on the vnode so it can close i= t. If there was some way for the NFSv4 VOP_CLOSE() to be able to tell if the f= ile has been mmap'd, that would help since it could close the ones that are not mmap'd on the last descriptor close. (A counter wouldn't be as useful, since NFSv4 would have to keep checking i= t to see if it can do the close yet, but it might still be doable.) > >> >LocalLock >> > 0 >> >Rpc Info: >> >TimedOut Invalid X Replies Retries Requests >> > 0 0 0 0 662 >> >Cache Info: >> >Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits = Misses >> > 1275 58 837 121 0 0 0 = 0 >> >BioRLHits Misses BioD Hits Misses DirE Hits Misses >> > 1 0 6 0 1 0 >> > >> [more stuff snipped] >> >What role could nullfs be playing? >> As noted above, my hunch is that is acquiring a refcnt on the NFS client= vnode such >> that the v_usecount doesn't go to zero (at least for a long time) and wi= thout >> a VOP_INACTIVE() on the NFSv4 vnode, the NFSv4 Opens don't get closed an= d >> accumulate. >> (If that isn't correct, it is somehow interfering with the client Closin= g the NFSv4 Opens >> in some other way.) >> >The following patch should automatically unset cache option for nullfs >mounts over NFSv4 filesystem. > >diff --git a/sys/fs/nfsclient/nfs_clvfsops.c b/sys/fs/nfsclient/nfs_clvfso= ps.c >index 524a372..a7e9fe3 100644 >--- a/sys/fs/nfsclient/nfs_clvfsops.c >+++ b/sys/fs/nfsclient/nfs_clvfsops.c >@@ -1320,6 +1320,8 @@ out: > MNT_ILOCK(mp); > mp->mnt_kern_flag |=3D MNTK_LOOKUP_SHARED | MNTK_NO_IOPF | > MNTK_USES_BCACHE; >+ if ((VFSTONFS(mp)->nm_flag & NFSMNT_NFSV4) !=3D 0) >+ mp->mnt_kern_flag |=3D MNTK_NULL_NOCACHE; > MNT_IUNLOCK(mp); > } > return (error); >diff --git a/sys/fs/nullfs/null_vfsops.c b/sys/fs/nullfs/null_vfsops.c >index 49bae28..de05e8b 100644 >--- a/sys/fs/nullfs/null_vfsops.c >+++ b/sys/fs/nullfs/null_vfsops.c >@@ -188,7 +188,8 @@ nullfs_mount(struct mount *mp) > } > > xmp->nullm_flags |=3D NULLM_CACHE; >- if (vfs_getopt(mp->mnt_optnew, "nocache", NULL, NULL) =3D=3D 0) >+ if (vfs_getopt(mp->mnt_optnew, "nocache", NULL, NULL) =3D=3D 0 || >+ (xmp->nullm_vfs->mnt_kern_flag & MNTK_NULL_NOCACHE) !=3D 0) > xmp->nullm_flags &=3D ~NULLM_CACHE; > > MNT_ILOCK(mp); >diff --git a/sys/sys/mount.h b/sys/sys/mount.h >index 94cabb6..b6f9fec 100644 >--- a/sys/sys/mount.h >+++ b/sys/sys/mount.h >@@ -370,7 +370,8 @@ void __mnt_vnode_markerfree_active(struct vno= de **mvp, >struct mount *); >#define MNTK_SUSPEND 0x08000000 /* request write suspensio= n */ >#define MNTK_SUSPEND2 0x04000000 /* block secondary writes = */ >#define MNTK_SUSPENDED 0x10000000 /* write operations are su= spended */ >-#define MNTK_UNUSED1 0x20000000 >+#define MNTK_NULL_NOCACHE 0x20000000 /* auto disable cache f= or nullfs >+ mounts over this fs */ >#define MNTK_LOOKUP_SHARED 0x40000000 /* FS supports shared lock looku= ps */ > #define MNTK_NOKNOTE 0x80000000 /* Don't send KNOTEs from = VOP hooks */ If the "nocache" option fixes Alan's problem, then I think a patch like thi= s is a good idea. Does unionfs suffer from the same issue? - I just took a glance and it doesn't have a "nocache" mount option. I can probably do a little test later to-day to see if unionfs seems to suf= fer from the same "accumulating opens" issue. Thanks for looking at this, rick From owner-freebsd-current@freebsd.org Fri Nov 25 16:35:10 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4397C55522 for ; Fri, 25 Nov 2016 16:35:10 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 09C0CF2 for ; Fri, 25 Nov 2016 16:35:09 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.walstatt.dynvpn.de ([85.179.173.164]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MgHHO-1cP7Jr1PKY-00Nj9v for ; Fri, 25 Nov 2016 17:35:01 +0100 Date: Fri, 25 Nov 2016 17:34:51 +0100 From: "O. Hartmann" To: FreeBSD CURRENT Subject: r309145: mutex.h:369:5: error: 'LOCK_DEBUG' is not defined Message-ID: <20161125173451.3edcfcfe@thor.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/SlZSOsRyJdc_Xr=C7f2f88u"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:Okqd/SNgYFEBbXqzJ818CurzbxoTE30OPySOsCLd5oCdi8p6DVO rfbtHcabQOxpE4MY0bxwNVX9TrJ+hoxULKPQP1KJmQKL8+FHwAMFS7YpHhWHxcFucA82NoX pte1n/xAeSPIDoNYfKk4y6gtVND8qN6QunukxjCakzrQaQ/xKcZUoDXdxMgujInfeqsosq+ k9EQ5KZsI70NKr6Ozj6PQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:zECm8aP/8Uk=:GzdFAxdtF/v/EGmH+/8P6S 9Ufmj379YU7+q0au5CN0rOczElDvmYA4o8vQb+41Ky12uc4qweVFYphGJgPDN6SykUgmq0v9C pvdUYMZpTV6cW3l7gEWnNNfMWvRhSjLd1kIgY1r+DWdlGtaAukJ+A5dfKxbbRpVgpeaEJu8LC leYXssUMN5vlA5IvIPFO20FuKWOKSN26K7rJXywhJD2SrI8M0XAGskCW1FwPXCypnfbyuoAez /3H5/ZVT3x3BZMma8VA1fKC3eHw4S/V3stTCdchEmK8arRKcI9RvVgX4U5NdPWVQc9SV4s1aY FGzfCUT5y/wP6RVSYhq1WkzFmyYX7oCGgOQ2rkqxoHML48x4yDbc7EkKcdbB4eFrcQMca3x1o iWz/A4/clXgkXYGnkaPZbDp4swyaQ/Mmhs7sdzF6k2pzx5t1llWolDvl/+QJjbbNaW3Rkqmr5 W11wFNi4BT3GwZtBOTLDu+v/i6GrirD2aUCJrk0292A4m+zIlfCVX/Rew/g1rl+Vu6ghzLzsH eVG9p5gRGZa6fCEmfYq5qasqx5B0S6gQHBYv67Lwh1iXz+p6dvH/UH8tENRCPqo9NXYlvzrZf Kh9eEsXEF471gcc1HviI4Gj8DJoumdYmIwbb41+NcxKsFJUw4f/evFSUC/ok1rDPzenNde8V/ Dea6jLPtRkJnJYRZ/I1tLwDyOKIIJtY/Na00oeQIEjTRdhokgN7/kIOtlD3gX+stOTaSmn0D5 nUfZe0NlTtZ+i/4fvB3dKF71CGLtpeXWmxhc1QYT5MjgqDQ91qY5xFnuSeM= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 16:35:10 -0000 --Sig_/SlZSOsRyJdc_Xr=C7f2f88u Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Recent sources do not build kernel due to: [...] Building /usr/obj/usr/src/sys/SB21X1/ipsec_mbuf.o In file included from /usr/src/sys/netipsec/ipsec_mbuf.c:43: In file included from /usr/src/sys/netipsec/ipsec.h:46: In file included from /usr/src/sys/netipsec/keydb.h:38: /usr/src/sys/sys/mutex.h:367:2: error: LOCK_DEBUG not defined, include before #error LOCK_DEBUG not defined, include be= fore ^ /usr/src/sys/sys/mutex.h:369:5: error: 'LOCK_DEBUG' is not defined, evaluat= es to 0 [-Werror,-Wundef] #if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) ^ 2 errors generated. *** Error code 1 regards, oh --Sig_/SlZSOsRyJdc_Xr=C7f2f88u Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWDhoKwAKCRDS528fyFhY lNWbAgCl0NRCr9Q1uFQVrcZjHnzYkxyMViimmWO1FpVWoUnC8SZ+SSPowq9hMOuz /HYpR7dPS26UXHPj91HdeUCrCAQ3Af4xzCHQT5QdfGAmDr60XNRBeirj8tP2B8r8 99apGBp0YlKHK4SFkkdJWIsEDdZvoC77n3e+XUcxgRXTmhC2fH6h =JWCK -----END PGP SIGNATURE----- --Sig_/SlZSOsRyJdc_Xr=C7f2f88u-- From owner-freebsd-current@freebsd.org Fri Nov 25 18:20:43 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 639A9C556F4 for ; Fri, 25 Nov 2016 18:20:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 51DBE5F8 for ; Fri, 25 Nov 2016 18:20:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 4B31AC556F3; Fri, 25 Nov 2016 18:20:43 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4AC96C556F2 for ; Fri, 25 Nov 2016 18:20:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 010C85F7 for ; Fri, 25 Nov 2016 18:20:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 09E3C10A981 for ; Fri, 25 Nov 2016 13:20:40 -0500 (EST) From: John Baldwin To: current@freebsd.org Subject: Please test EARLY_AP_STARTUP Date: Fri, 25 Nov 2016 10:20:36 -0800 Message-ID: <7005233.xZtqgRZ2t6@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-PRERELEASE; KDE/4.14.10; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Fri, 25 Nov 2016 13:20:40 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 18:20:43 -0000 I plan to enable EARLY_AP_STARTUP on x86 in a week on HEAD. Some folks have been testing it for the last week or so which has exposed some additional things to fix. I think I've resolved most of those in one way or another, but it will make things smoother if other folks can start testing this over the next few days before it is enabled by default. (To enable, add 'options EARLY_AP_STARTUP' to your kernel config.) Note that non-x86 platforms should eventually adopt this, but I don't think any of them are ready yet. -- John Baldwin From owner-freebsd-current@freebsd.org Fri Nov 25 21:42:55 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2CFA3C550CB for ; Fri, 25 Nov 2016 21:42:55 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D8DC4E91 for ; Fri, 25 Nov 2016 21:42:54 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-qt0-x229.google.com with SMTP id w33so75362848qtc.3 for ; Fri, 25 Nov 2016 13:42:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Iv4XOvndzqgPLsrvvUXPseGdY7ZBwntxYi9UkuJ7Z9o=; b=nVHEodGCj9n7fvplt8eVMwxUpxCk39A+e2olR+8lS70hHVGf6YhffpbKmI64jYswqY ujJNMrfDVKyq13MLsralPOt3+rRbpRtVL3lxl/7Gu7PsE01hoIgTg7Wp6M8WmFx30zHk jh7LswrCkitUk9J60rg0QWRUsIq1zjo0PLzSArfruha3MXd0ajtA5kuvoFaoELZvNHJa eUu9rerHrPlBaf/fE0GJC8ZPmwSuBVQVZFzgH974UuCAmv8NxGalBQYkADOc9CH0pRGI wRMhHhsXLDgWc1aKKzmXntzPMIpfkS3Mv44ep3e+kEX7bgD8XLBDM/QpKIm/t38Rf+VG uBmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Iv4XOvndzqgPLsrvvUXPseGdY7ZBwntxYi9UkuJ7Z9o=; b=ZTnKeUZ/h+3d71HHG6sp2Y+r9K0R4/1PR8B9gyUisV02gltdn6XR15ia3nL2UT8Yc/ ot5QQ//OXm30ybuiy1STzCCgd/B2ET1hntcPqSkphIZi2HdRYOi5e6Mo3AOQX0cqYm65 pRO/TqQb/3bPGSeTovrCyc5JoLVa4uc5oDk4TWOSK+Z3QSP30jI6PUn5dYHK8H7ydzlq FqC+EnmJ/CbzqI+I2w4SekliRsXmV3VBAvTcMc9d6gUcjtlGnBeiEq7C34pLhXEx2PEN A4Yg62v11OqLzuO1Dw29kuSMni7uI3/8v+JfhQXrjkgKD+2Iiak2SeGFlfFkvBNENDZG Rx6w== X-Gm-Message-State: AKaTC03pg8JoBaxKi6QhgS2K1OhH58HL785TUqobELeZy2ZNxx3u3zHxbpRR1rYfqObM/n0b/qQL1mw8pZxWdw== X-Received: by 10.200.48.28 with SMTP id f28mr9975891qte.247.1480110173948; Fri, 25 Nov 2016 13:42:53 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.12.166.129 with HTTP; Fri, 25 Nov 2016 13:42:53 -0800 (PST) In-Reply-To: <20161125135725.GD54029@kib.kiev.ua> References: <20161124090811.GO54029@kib.kiev.ua> <20161125084106.GX54029@kib.kiev.ua> <20161125135725.GD54029@kib.kiev.ua> From: Alan Somers Date: Fri, 25 Nov 2016 14:42:53 -0700 X-Google-Sender-Auth: G0BdaBcCmb9nLA5osDn-7eOb9sA Message-ID: Subject: Re: NFSv4 performance degradation with 12.0-CURRENT client To: Konstantin Belousov Cc: Rick Macklem , FreeBSD CURRENT Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 21:42:55 -0000 On Fri, Nov 25, 2016 at 6:57 AM, Konstantin Belousov wrote: > On Fri, Nov 25, 2016 at 12:54:07PM +0000, Rick Macklem wrote: >> Well, ideally theer would be a VOP_MMAPDONE() or something like that, which >> would tell the NFSv4 client that I/O is done on the vnode so it can close it. >> If there was some way for the NFSv4 VOP_CLOSE() to be able to tell if the file >> has been mmap'd, that would help since it could close the ones that are not >> mmap'd on the last descriptor close. >> (A counter wouldn't be as useful, since NFSv4 would have to keep checking it to >> see if it can do the close yet, but it might still be doable.) > > I thought that the issue was in tracking any opens and mmaps, but from this > reply it is not that clear. Do you need callback when all opens and mmaps > have ended, or only opens and mmaps for write ? If later, we already have > a suitable mechanism VOP_ADD_WRITECOUNT(). Mounting nullfs with the nocache option, ad kib suggested, fixed the problem. Also, applying kib's patch and then mounting nullfs with default options also fixed the problem. Here is the nfsstat output for "ls -al" when using kib's patch. Notice the client has far fewer opens: nfsstat -s -e -z Server Info: Getattr Setattr Lookup Readlink Read Write Create Remove 494 0 0 0 0 1 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit LookupP SetClId SetClIdCf 0 0 0 0 0 0 0 0 Open OpenAttr OpenDwnGr OpenCfrm DelePurge DeleRet GetFH Lock 0 0 0 0 0 0 0 0 LockT LockU Close Verify NVerify PutFH PutPubFH PutRootFH 0 0 0 0 0 494 0 0 Renew RestoreFH SaveFH Secinfo RelLckOwn V4Create 0 0 0 0 0 0 Server: Retfailed Faults Clients 0 0 0 OpenOwner Opens LockOwner Locks Delegs 0 0 0 0 0 Server Cache Stats: Inprog Idem Non-idem Misses CacheSize TCPPeak 0 0 0 495 17280 17280 nfsstat -c -e -z Client Info: Rpc Counts: Getattr Setattr Lookup Readlink Read Write Create Remove 14 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit SetClId SetClIdCf Lock 0 0 0 0 0 0 0 0 LockT LockU Open OpenCfr 0 0 0 0 OpenOwner Opens LockOwner Locks Delegs LocalOwn LocalOpen LocalLOwn 592 588 0 0 0 0 0 0 LocalLock 0 Rpc Info: TimedOut Invalid X Replies Retries Requests 0 0 0 0 494 Cache Info: Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits Misses 1439 12 960 0 0 0 0 0 BioRLHits Misses BioD Hits Misses DirE Hits Misses 1 0 4 0 1 0 Thanks for the help, guys. From owner-freebsd-current@freebsd.org Sat Nov 26 07:46:26 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03F22C56ADC for ; Sat, 26 Nov 2016 07:46:26 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 59A98EA2 for ; Sat, 26 Nov 2016 07:46:24 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.walstatt.dynvpn.de ([85.179.173.164]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lhfu5-1cWLn03JlR-00mr6H; Sat, 26 Nov 2016 08:46:11 +0100 Date: Sat, 26 Nov 2016 08:46:07 +0100 From: "O. Hartmann" To: David Wolfskill Cc: FreeBSD CURRENT Subject: Re: r309145: mutex.h:369:5: error: 'LOCK_DEBUG' is not defined Message-ID: <20161126084607.1c8ced25@thor.walstatt.dynvpn.de> In-Reply-To: <20161125164051.GS22600@albert.catwhisker.org> References: <20161125173451.3edcfcfe@thor.walstatt.dynvpn.de> <20161125164051.GS22600@albert.catwhisker.org> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/XRfVUX21H/u2UaVJoLZnFrs"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:rkb5BBxxw5Kz+aHZNomgQyfR6i9BEpOy3gSbq9cZcfiKpmgH4x0 71iOz7g0Jm1X5JiGv87IZ5WGyPzeoUnALWVjP1V03OPW6fSwhhrZi/solijd1CxaS6JL9NR sUY1U/Vs/mOqSmac/NShQV2ZjqHfPzVt+r7Z5VRrjt9wjNjQlAylp2/FVrK169FZ1kVvVGO t4VfuS11X7i+/btYQai4w== X-UI-Out-Filterresults: notjunk:1;V01:K0:Tairwx9Wk50=:LBTAHT+PBWfH9/sChClaKl w2sH9l9S9CifMpF2Qx37HzxTW5IP6lbvDgTPorQVGsVx+1tJ78bJg26lNVln9tnwfq3ILc/Dk 42DOZJU+w7iypy8nre/tQuQ4NRLnEa+eiBa217ApGzpafOHHuvpfSRfU9QQXQE7VKNvrCcjOQ ifIc1amXWAndO1HEwExn4VA6AGJbcOwHjuI6eJWRjFvHiJFmUsjHwxZnT2oQb/D+txc9uBWQV AK9hmxMaFC86WhvyaKsH62x1AdmmnE1jDcu3nnkuAmxOptvu0MkkFQt6oeY1AhDscO8DWWw5m vxRZnmYy5OUfoDjv6i19/3p/0RkpYrhVBHAD6ej0xI5TaqRrZ8Z0jQ7+Dz2GYANtTeBadPpLy 3zRt3Nu7xVKzeBj5pGoWc6Wv0hsDeCMsDEetphuWZVwCj86pxynxVXgcUa2/RS3DsYI3DDzzJ 9KaWitWp13kcPauHsHsWb3EdbHSl35sKYOtjZA8Ljt9Ilj/dAPfdNrKNiPZhcjvPxb8bFmu3z 3i1yVa6duBudXd2ud6Tyx8UCb3CxEaNUykj7x2fePsRFkjYxEKVUCVFbIqZlrltHv6hwVScPM pC0wxw7MEM2hSezE4jQrHT78APG/odu58HF5kOngg+lqz+uTgWNIRLvH0R8FNA6iMOSiMs2tt poiZFJDZSzsZcRk1XuZP0Q52l+Gp7X+FUceR5x7+NArgNHnQvLDbhBgtm8S57bBpsv/YEVq2j u7R6cgNhRloOyW+Hsax1Hi8alB4EkpowZoX9dAlUhtyAcUSqUZbxIE5fPUY= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 07:46:26 -0000 --Sig_/XRfVUX21H/u2UaVJoLZnFrs Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Fri, 25 Nov 2016 08:40:51 -0800 David Wolfskill schrieb: > On Fri, Nov 25, 2016 at 05:34:51PM +0100, O. Hartmann wrote: > > Recent sources do not build kernel due to: > >=20 > > [...] > > Building /usr/obj/usr/src/sys/SB21X1/ipsec_mbuf.o > > In file included from /usr/src/sys/netipsec/ipsec_mbuf.c:43: > > In file included from /usr/src/sys/netipsec/ipsec.h:46: > > In file included from /usr/src/sys/netipsec/keydb.h:38: > > /usr/src/sys/sys/mutex.h:367:2: error: LOCK_DEBUG not defined, include = > > before #error LOCK_DEBUG not defined, include before > > ^ > > /usr/src/sys/sys/mutex.h:369:5: error: 'LOCK_DEBUG' is not defined, eva= luates to 0 > > [-Werror,-Wundef] #if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) > > ^ > > 2 errors generated. > > *** Error code 1 > >=20 > >=20 [...] I blindly followed the advice of the compiler error spit out and included = the line #include before=20 #include and siehe da!, it worked and I can compile the kernel again (I have IPSEC e= nabled in my kernel config files on all systems). Kind regards, Oliver --Sig_/XRfVUX21H/u2UaVJoLZnFrs Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWDk9vwAKCRDS528fyFhY lORSAgCmInqyL9DZ/iHZ55rxeOUS0VCFfUcA22KSu1Uu+MI/G504LcsZmIB1YxHH bsBIsk6kPAk0hBRIPdCymf+ixi4hAgCD2+R/vOQ1qAW6usa9h7atidnupr2j3dRV MclVZY2EBe9Hl3XhVhf2e3XHq909sCdHkdf5yeFruCsN84B7ABVM =LeZr -----END PGP SIGNATURE----- --Sig_/XRfVUX21H/u2UaVJoLZnFrs-- From owner-freebsd-current@freebsd.org Sat Nov 26 09:21:33 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0924BC57E5C for ; Sat, 26 Nov 2016 09:21:33 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id ECA87DE for ; Sat, 26 Nov 2016 09:21:32 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id EC031C57E5B; Sat, 26 Nov 2016 09:21:32 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EBAD5C57E5A for ; Sat, 26 Nov 2016 09:21:32 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 B1E7ADB for ; Sat, 26 Nov 2016 09:21:32 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cAZAi-000Cnr-5M for current@freebsd.org; Sat, 26 Nov 2016 12:21:24 +0300 Date: Sat, 26 Nov 2016 12:21:24 +0300 From: Slawa Olhovchenkov To: current@freebsd.org Subject: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161126092124.GM57876@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 09:21:33 -0000 I am try to enable NUMA in bios and can't boot FreeBSD. Boot stoped after next messages: === Booting... KDB: debugger backends: ddb KDB: current backend: ddb === This is verbose boot. No reaction to ~^B, NMI. Same for head and 10.3-RELEASE. Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. On slight different hardware (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) 10.3 boot ok w/ BIOS NUMA enabled. From owner-freebsd-current@freebsd.org Sat Nov 26 15:57:53 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EA18FC55B11 for ; Sat, 26 Nov 2016 15:57:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id D3B048E4 for ; Sat, 26 Nov 2016 15:57:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id D31A9C55B10; Sat, 26 Nov 2016 15:57:53 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D2CF5C55B0F for ; Sat, 26 Nov 2016 15:57:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6E8A28E3 for ; Sat, 26 Nov 2016 15:57:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id uAQFvldL038475 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 26 Nov 2016 17:57:47 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uAQFvldL038475 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uAQFvli5038474; Sat, 26 Nov 2016 17:57:47 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 26 Nov 2016 17:57:47 +0200 From: Konstantin Belousov To: Slawa Olhovchenkov Cc: current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161126155747.GF54029@kib.kiev.ua> References: <20161126092124.GM57876@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161126092124.GM57876@zxy.spb.ru> User-Agent: Mutt/1.7.1 (2016-10-04) 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.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 15:57:54 -0000 On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov wrote: > I am try to enable NUMA in bios and can't boot FreeBSD. > Boot stoped after next messages: > > === > Booting... > KDB: debugger backends: ddb > KDB: current backend: ddb So at least the hammer_time() has a chance to initialize the console. Do you have serial console ? Set the loader tunable debug.late_console to 1 and see if any NMI reaction appear. > === > > This is verbose boot. > No reaction to ~^B, NMI. > > Same for head and 10.3-RELEASE. > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. Is there a BIOS option for 'on-chip cluster' or 'HPC computing' ? What if you try to frob it ? > > On slight different hardware > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > 10.3 boot ok w/ BIOS NUMA enabled. I think the only way to debug this is to add printf() lines to hammer_time() to see where does it break. Note that amd64_kdb_init() call succeeded, so you can start bisect the code from there. From owner-freebsd-current@freebsd.org Sat Nov 26 15:59:06 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A5715C55C23 for ; Sat, 26 Nov 2016 15:59:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8EB36A1D for ; Sat, 26 Nov 2016 15:59:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 8E19CC55C22; Sat, 26 Nov 2016 15:59:06 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8DBF7C55C21 for ; Sat, 26 Nov 2016 15:59:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0DEA6A1C for ; Sat, 26 Nov 2016 15:59:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id uAQFx1Yg038583 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 26 Nov 2016 17:59:01 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uAQFx1Yg038583 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uAQFx1v2038582; Sat, 26 Nov 2016 17:59:01 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 26 Nov 2016 17:59:01 +0200 From: Konstantin Belousov To: Slawa Olhovchenkov Cc: current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161126155901.GG54029@kib.kiev.ua> References: <20161126092124.GM57876@zxy.spb.ru> <20161126155747.GF54029@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161126155747.GF54029@kib.kiev.ua> User-Agent: Mutt/1.7.1 (2016-10-04) 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.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 15:59:06 -0000 On Sat, Nov 26, 2016 at 05:57:47PM +0200, Konstantin Belousov wrote: > On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov wrote: > > I am try to enable NUMA in bios and can't boot FreeBSD. > > Boot stoped after next messages: > > > > === > > Booting... > > KDB: debugger backends: ddb > > KDB: current backend: ddb > So at least the hammer_time() has a chance to initialize the console. > Do you have serial console ? Set the loader tunable debug.late_console > to 1 and see if any NMI reaction appear. Err, sorry. Set it to 0. > > > === > > > > This is verbose boot. > > No reaction to ~^B, NMI. > > > > Same for head and 10.3-RELEASE. > > > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > Is there a BIOS option for 'on-chip cluster' or 'HPC computing' ? > What if you try to frob it ? > > > > > On slight different hardware > > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > > 10.3 boot ok w/ BIOS NUMA enabled. > > I think the only way to debug this is to add printf() lines to hammer_time() > to see where does it break. Note that amd64_kdb_init() call succeeded, > so you can start bisect the code from there. > From owner-freebsd-current@freebsd.org Sat Nov 26 16:07:24 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 27C92C55F6D for ; Sat, 26 Nov 2016 16:07:24 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 159C0E74 for ; Sat, 26 Nov 2016 16:07:24 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 1213CC55F6C; Sat, 26 Nov 2016 16:07:24 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 119CCC55F6B for ; Sat, 26 Nov 2016 16:07:24 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 CAA70E73 for ; Sat, 26 Nov 2016 16:07:23 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cAfVY-000Oq9-5f; Sat, 26 Nov 2016 19:07:20 +0300 Date: Sat, 26 Nov 2016 19:07:20 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161126160720.GF99742@zxy.spb.ru> References: <20161126092124.GM57876@zxy.spb.ru> <20161126155747.GF54029@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161126155747.GF54029@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 16:07:24 -0000 On Sat, Nov 26, 2016 at 05:57:47PM +0200, Konstantin Belousov wrote: > On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov wrote: > > I am try to enable NUMA in bios and can't boot FreeBSD. > > Boot stoped after next messages: > > > > === > > Booting... > > KDB: debugger backends: ddb > > KDB: current backend: ddb > So at least the hammer_time() has a chance to initialize the console. > Do you have serial console ? Set the loader tunable debug.late_console Via ipmi sol > to 1 and see if any NMI reaction appear. I am try this late. > > === > > > > This is verbose boot. > > No reaction to ~^B, NMI. > > > > Same for head and 10.3-RELEASE. > > > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > Is there a BIOS option for 'on-chip cluster' or 'HPC computing' ? No > What if you try to frob it ? > > > > > On slight different hardware > > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > > 10.3 boot ok w/ BIOS NUMA enabled. > > I think the only way to debug this is to add printf() lines to hammer_time() > to see where does it break. Note that amd64_kdb_init() call succeeded, > so you can start bisect the code from there. > I am not expert in this code. From owner-freebsd-current@freebsd.org Sat Nov 26 16:14:08 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91B3AC572BA for ; Sat, 26 Nov 2016 16:14:08 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7F3532E9 for ; Sat, 26 Nov 2016 16:14:08 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 7E861C572B8; Sat, 26 Nov 2016 16:14:08 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E28FC572B6 for ; Sat, 26 Nov 2016 16:14:08 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 41A542E8 for ; Sat, 26 Nov 2016 16:14:08 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cAfc6-000P2Q-6E; Sat, 26 Nov 2016 19:14:06 +0300 Date: Sat, 26 Nov 2016 19:14:06 +0300 From: Slawa Olhovchenkov To: Konstantin Belousov Cc: current@freebsd.org Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161126161406.GG99742@zxy.spb.ru> References: <20161126092124.GM57876@zxy.spb.ru> <20161126155747.GF54029@kib.kiev.ua> <20161126160720.GF99742@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161126160720.GF99742@zxy.spb.ru> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 16:14:08 -0000 On Sat, Nov 26, 2016 at 07:07:20PM +0300, Slawa Olhovchenkov wrote: > On Sat, Nov 26, 2016 at 05:57:47PM +0200, Konstantin Belousov wrote: > > > On Sat, Nov 26, 2016 at 12:21:24PM +0300, Slawa Olhovchenkov wrote: > > > I am try to enable NUMA in bios and can't boot FreeBSD. > > > Boot stoped after next messages: > > > > > > === > > > Booting... > > > KDB: debugger backends: ddb > > > KDB: current backend: ddb > > So at least the hammer_time() has a chance to initialize the console. > > Do you have serial console ? Set the loader tunable debug.late_console > > Via ipmi sol > > > to 1 and see if any NMI reaction appear. > > I am try this late. > > > > === > > > > > > This is verbose boot. > > > No reaction to ~^B, NMI. > > > > > > Same for head and 10.3-RELEASE. > > > > > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > > Is there a BIOS option for 'on-chip cluster' or 'HPC computing' ? > > No > > > What if you try to frob it ? > > > > > > > > On slight different hardware > > > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > > > 10.3 boot ok w/ BIOS NUMA enabled. > > > > I think the only way to debug this is to add printf() lines to hammer_time() > > to see where does it break. Note that amd64_kdb_init() call succeeded, > > so you can start bisect the code from there. > > > > I am not expert in this code. I am think code halted in later getmemsize() (or before it), I am don't see any messages from init_ops.parse_memmap()/native_parse_memmap(). From owner-freebsd-current@freebsd.org Sat Nov 26 16:22:43 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D310FC57587 for ; Sat, 26 Nov 2016 16:22:43 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 37A749FB for ; Sat, 26 Nov 2016 16:22:42 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.walstatt.dynvpn.de ([85.179.169.168]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M0bo2-1d0qrE3Eyc-00usSo for ; Sat, 26 Nov 2016 17:22:34 +0100 Date: Sat, 26 Nov 2016 17:22:10 +0100 From: "O. Hartmann" To: FreeBSD CURRENT Subject: CURRENT: kernel fails to compile when "options IPSEC" Message-ID: <20161125173451.3edcfcfe@thor.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/f06qZ8kaCR/WH34RskMA8DT"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:14tnfhibfELYT1jFxOo87fXq9/oQ8now5l8JZ0ZvMVVQwcYCPQO nEbzAmJ7Mm6Nx5d7PA0dkRGtyKOvz7xak3N+XHOz04KUULaSosy591kZ8XRoy6cbkoxW+Pw ih4NEIg6AlWKY0b+oI8Rwf5if/j2FH2s/AhXlPKu6AUEvu26GLUFAydqRlylfjs4WsWXPBF /BCIC9jrBzZ4iaziiQ3ig== X-UI-Out-Filterresults: notjunk:1;V01:K0:+dypQvN986c=:5fXY25l2uNLDkDVOObdOg4 Ej+6KnknW/SLlLOCug1f7E8lRXZsCxgXaGqtC+WxbANHXntH2lPdZcKXp8chwNOuCcpQ8kb8z JL33hJ6Qafld4fsxxxlKIuHvZwYrM8VTjQoSxHO0GiQUg02jyDS7y/xx5MWKPcVKITZl66HDJ NxWV6+9kQkKZBAvQh2GARJcXrcbE+mHRsxPOjypYie8Jbh+WlJA8FgFs8+FqkfacTog0wBiqa 51FE8AC9kAYHMh+H8HhJZtiJ0dF2A5pgueiUaRHVESLOGYXqjh/YgMHwhbYCP9igJKfoYzDBW y9F7dGvrAOvDWUzQmR5S9Ympd5dZxtOWlF0ovSx59TKqLkwHfCa4CBX4LiNls/9qRbBc4X8IZ 1iK2e2mUJMK6bDQm0R8ctEbeqsIo+hEUVcvJ0+2YOyHY4fCDqEdj5CuooTVqevaGMTVUPQ0AU VRNyv0Y8582y3CxOKeXzDib/MwrB9xeaNAXcQQouLSyQA59IzX8Mootcn3oGQvIvljOY5LqjA KBYQxxxUPGykg5y1Cws/Bx2fTaQZEw6mNtEJo3Uy90LgIOSdCFyH8jIq3R7G3rLfK96e62eMn WipS8qLgCYGPCMMPayLwL/cUbKCeq1caiTmgxJMS+NTZHEuBTfJS8r3SCDkHTOuID8XI9h4hN aeOwdqUvMaG/98B2AREbTG+qh+O0W0kmnpub5Og3k2CuEA7wj8ZreJZgGG5Vj6lZEtRAwxsL1 1cftARq9FXf9hPVw5bsE7gncDpT5i1jEUlLGkOhqQS4p04XYRkukjMyo4m0= X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 16:22:43 -0000 --Sig_/f06qZ8kaCR/WH34RskMA8DT Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Recent sources (309143-309194) do not build kernel due to: [...] Building /usr/obj/usr/src/sys/SB21X1/ipsec_mbuf.o In file included from /usr/src/sys/netipsec/ipsec_mbuf.c:43: In file included from /usr/src/sys/netipsec/ipsec.h:46: In file included from /usr/src/sys/netipsec/keydb.h:38: /usr/src/sys/sys/mutex.h:367:2: error: LOCK_DEBUG not defined, include before #error LOCK_DEBUG not defined, include be= fore ^ /usr/src/sys/sys/mutex.h:369:5: error: 'LOCK_DEBUG' is not defined, evaluat= es to 0 [-Werror,-Wundef] #if LOCK_DEBUG > 0 || defined(MUTEX_NOINLINE) ^ 2 errors generated. *** Error code 1 This error can be avoided by following the suggestion made, patching sys/ne= tipsec/keydb.h: --- sys/netipsec/keydb.h (revision 309194) +++ sys/netipsec/keydb.h (working copy) @@ -35,6 +35,8 @@ =20 #ifdef _KERNEL =20 +#include + #include =20 #include Can someone please fix this? I'm not sure whether the include is the correct palce in this = case or has to show up earlier in the include-chain. oh --Sig_/f06qZ8kaCR/WH34RskMA8DT Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWDm2sgAKCRDS528fyFhY lAAzAf9Qe0ZZFn0cRXgFsCZqtOS9hQDtaDQfHGfLnAOTehtxr2r38sNz46TZFkQj Z6GbYp8t+m4mtCZcYbFhO6m7AMd/Af9a1ps+56AwbTx3SRaQBnEwKVVm6bWUIiBY NfOLy1236DUk6vcA3iD8fQLPU3TkZtUy0TF7VvYpHGApFjvJuSmU =1q/b -----END PGP SIGNATURE----- --Sig_/f06qZ8kaCR/WH34RskMA8DT-- From owner-freebsd-current@freebsd.org Sat Nov 26 17:35:09 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6575C57FE4 for ; Sat, 26 Nov 2016 17:35:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id A77A866A for ; Sat, 26 Nov 2016 17:35:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id A6CC8C57FE3; Sat, 26 Nov 2016 17:35:09 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6600C57FE2 for ; Sat, 26 Nov 2016 17:35:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7232F669 for ; Sat, 26 Nov 2016 17:35:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x22a.google.com with SMTP id c21so163412105ioj.1 for ; Sat, 26 Nov 2016 09:35:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tdw+cFN6Lg2B2Pc6oFGPOA8Vq5p56RphT/VG+HL4xzQ=; b=RCphDouodmSeyoayX38uF60YORx2y4RvdpwNWz6CtJfaRkSrTJMDJGXJLnQspGrelk j+V7ucqOcm9cus8laTlOcu85jo8SHIqb8mTDYcrh51+mIjhcOyUikTTQvOPFWmQUAkn4 DaNDRETIUMEJBq1YlV3PJYQDBz57aJGESji0hb9Y1tHS+Dp098VZDtv/gTQWbeWb6UGr 0q5KoqOuJFa+YGB4q9fDQWuPrU5R+IDOepGkL0Juuay3RhIA7w73MnCAXx6ys9tN3Su+ 7H7IcLjjMgCcNOvSXqtYbvfWd2MHmtEUnNmgS+v/O1+0Nn5sCuETLpTpKzSXiiH0xk98 6CBw== 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; bh=tdw+cFN6Lg2B2Pc6oFGPOA8Vq5p56RphT/VG+HL4xzQ=; b=RkG8IqeUImBqCO/yY/qka4+9KKUBR7r7uLOto3iT9NwxaN6p5kR0junxeBLAIHHTLq jSctVhJsUC5qWcVdOgXcVoheC92HeVq6Yd3gIDubY1Y9F1H3qTAmLbDgyrSLeIFPgJ8p 1TB5Ecn5bnKN2RuJDKLmDlRCr+qpOyCw0Dq9n6vFvb4Ewb3jN+oEJ21gO4cHIit2v3UK dNqyYcUJ+DW7+RmYQGx8y33rP+BjRztH1GnRPh393aIHvYB+7GTG+ktL9bhdJOZUPxvN YNMA4XMB8BMDb375TKq1/+E5G3k4tdevEUe8AGg2ZZ14eUQg6VxbMFzTVdsbK554Pwwm YSww== X-Gm-Message-State: AKaTC03pekE+c4n27WmIN7Mc2Gju6BeVHm04sgW7IC0/+Qi9cGaNxJTASZbQ/HoTqqgIBoanky2b0OYoDNR13A== X-Received: by 10.107.36.144 with SMTP id k138mr11830745iok.177.1480181708712; Sat, 26 Nov 2016 09:35:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.39.134 with HTTP; Sat, 26 Nov 2016 09:35:08 -0800 (PST) In-Reply-To: <20161126092124.GM57876@zxy.spb.ru> References: <20161126092124.GM57876@zxy.spb.ru> From: Adrian Chadd Date: Sat, 26 Nov 2016 09:35:08 -0800 Message-ID: Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD To: Slawa Olhovchenkov Cc: "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 17:35:09 -0000 It may be something to do with memory topology parsing. Maybe we need some more debugging there to try and catch it. -a On 26 November 2016 at 01:21, Slawa Olhovchenkov wrote: > I am try to enable NUMA in bios and can't boot FreeBSD. > Boot stoped after next messages: > > === > Booting... > KDB: debugger backends: ddb > KDB: current backend: ddb > === > > This is verbose boot. > No reaction to ~^B, NMI. > > Same for head and 10.3-RELEASE. > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > > On slight different hardware > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > 10.3 boot ok w/ BIOS NUMA enabled. > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sat Nov 26 17:37:56 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 44B12C571F8 for ; Sat, 26 Nov 2016 17:37:56 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 321768D4 for ; Sat, 26 Nov 2016 17:37:56 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 316E6C571F7; Sat, 26 Nov 2016 17:37:56 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 31170C571F6 for ; Sat, 26 Nov 2016 17:37:56 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 E7F218D3 for ; Sat, 26 Nov 2016 17:37:55 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cAgvB-0001SI-BP; Sat, 26 Nov 2016 20:37:53 +0300 Date: Sat, 26 Nov 2016 20:37:53 +0300 From: Slawa Olhovchenkov To: Adrian Chadd Cc: "current@freebsd.org" Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161126173753.GH99742@zxy.spb.ru> References: <20161126092124.GM57876@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 17:37:56 -0000 On Sat, Nov 26, 2016 at 09:35:08AM -0800, Adrian Chadd wrote: > It may be something to do with memory topology parsing. Maybe we need > some more debugging there to try and catch it. What debug you need? > On 26 November 2016 at 01:21, Slawa Olhovchenkov wrote: > > I am try to enable NUMA in bios and can't boot FreeBSD. > > Boot stoped after next messages: > > > > === > > Booting... > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > === > > > > This is verbose boot. > > No reaction to ~^B, NMI. > > > > Same for head and 10.3-RELEASE. > > > > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. > > > > On slight different hardware > > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) > > 10.3 boot ok w/ BIOS NUMA enabled. > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sat Nov 26 17:44:51 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88817C57484 for ; Sat, 26 Nov 2016 17:44:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 68C4AD0E for ; Sat, 26 Nov 2016 17:44:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 680D4C57483; Sat, 26 Nov 2016 17:44:51 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 67AB0C57482 for ; Sat, 26 Nov 2016 17:44:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3299FD0D for ; Sat, 26 Nov 2016 17:44:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x231.google.com with SMTP id m5so30534191ioe.3 for ; Sat, 26 Nov 2016 09:44:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xgxVjkecYc1fU1HK4l/c42kzxk1e/ui9rzTpJpBQbQg=; b=GFSNJwiHi5iLNvIvh6HCFMTSveaXHaejZLMgQIEAK4gSstB4B/1DlpveVs7szrVr1V TPSZfwcXXKdpMt5qY3jzr7Pmc/9HYy6Sn2gyZ3lSW8Bk8xyXFl158dnQmf/uC4MgdVWU bjA1YWdSP7HBxNx9hOAIyguofCSQ4TrLYYk5nKSy9lalzu4p78dXL3SWqieN8cwlFPil myuqSpLKpGJvtUhXqBgB+7A9Mm00QfKutvr2VnZRhT3d6E5YXxDkUAJPd6P++i2/s0rE DU24OVj+XZ52XaX9NNJ47whbys3J1Z1P4wyekTAkWkodmUMUcweY3+KOCe/Gt0/FyM75 qdiw== 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; bh=xgxVjkecYc1fU1HK4l/c42kzxk1e/ui9rzTpJpBQbQg=; b=AR6KcLFxUMr7b1n5iLgaoWqf+GpkRBpQwx0uebuofM0io45wBSbyliuiox1C0ruRpc gZtKHCm/QkBdrMQNBuonNAIaIRWImE8ISbmy/JNoYYWCM7pqjPxVcj00E4JZo9bzj0nU UDPv7N/zFxFcmEXbrJfFf0KMvPJ5G1K+pnE+2HJGstSL5U/uNippcIV+6OL4oHLQ17+8 FufIpjBCdMkRtnnH4xyc7o8/WP5JbY0FASHOqqQgou4pTJIpFigZgP6sYK48sdoBpPQl +WQDgfE/sup9wffjAfEIwHIIy6gRF2f4vsIIAcbpluxcYUBRbNJ03KhyRYidsEIn3heb I7UA== X-Gm-Message-State: AKaTC03z9u4qugR9h6K/zliPH62X+zpLydsaisivwwyY4KUz9d9K+g2nMTTksG7OoBI8b4gB0fn8KDTAWv3piw== X-Received: by 10.107.192.194 with SMTP id q185mr11205733iof.129.1480182290605; Sat, 26 Nov 2016 09:44:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.39.134 with HTTP; Sat, 26 Nov 2016 09:44:49 -0800 (PST) In-Reply-To: <20161126173753.GH99742@zxy.spb.ru> References: <20161126092124.GM57876@zxy.spb.ru> <20161126173753.GH99742@zxy.spb.ru> From: Adrian Chadd Date: Sat, 26 Nov 2016 09:44:49 -0800 Message-ID: Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD To: Slawa Olhovchenkov Cc: "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 17:44:51 -0000 The ACPI SRAT parsing code - sys/x86/acpica/srat.c . I'd start by enabling bootverbose - adds one echo (SLIT.Localities and the table); adds CPU affinity info (legacy, XAPIC, ACPI) and other locality stuff. -adrian On 26 November 2016 at 09:37, Slawa Olhovchenkov wrote: > On Sat, Nov 26, 2016 at 09:35:08AM -0800, Adrian Chadd wrote: > >> It may be something to do with memory topology parsing. Maybe we need >> some more debugging there to try and catch it. > > What debug you need? > >> On 26 November 2016 at 01:21, Slawa Olhovchenkov wrote: >> > I am try to enable NUMA in bios and can't boot FreeBSD. >> > Boot stoped after next messages: >> > >> > === >> > Booting... >> > KDB: debugger backends: ddb >> > KDB: current backend: ddb >> > === >> > >> > This is verbose boot. >> > No reaction to ~^B, NMI. >> > >> > Same for head and 10.3-RELEASE. >> > >> > Hardware is Supermicro X10DRi, Dual E5-2650v4, 256GB RAM. >> > >> > On slight different hardware >> > (Supermicro X10DRi w/ old BIOS, Dual E5-2640v3, 128GB RAM) >> > 10.3 boot ok w/ BIOS NUMA enabled. >> > >> > _______________________________________________ >> > freebsd-current@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-current >> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sat Nov 26 17:57:35 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94E22C57928 for ; Sat, 26 Nov 2016 17:57:35 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8014E850 for ; Sat, 26 Nov 2016 17:57:35 +0000 (UTC) (envelope-from jhs@berklix.com) Received: by mailman.ysv.freebsd.org (Postfix) id 7C4B8C57927; Sat, 26 Nov 2016 17:57:35 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7BF40C57926 for ; Sat, 26 Nov 2016 17:57:35 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from land.berklix.org (land.berklix.org [144.76.10.75]) (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 1E40A84F for ; Sat, 26 Nov 2016 17:57:34 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from mart.js.berklix.net (p5083C3BA.dip0.t-ipconnect.de [80.131.195.186]) (authenticated bits=128) by land.berklix.org (8.15.2/8.15.2) with ESMTPA id uAQHvPo1074246 for ; Sat, 26 Nov 2016 17:57:25 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by mart.js.berklix.net (8.14.3/8.14.3) with ESMTP id uAQHvIo3061458 for ; Sat, 26 Nov 2016 18:57:18 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.7/8.14.7) with ESMTP id uAQHv6rm078055 for ; Sat, 26 Nov 2016 18:57:18 +0100 (CET) (envelope-from jhs@berklix.com) Message-Id: <201611261757.uAQHv6rm078055@fire.js.berklix.net> To: current@FreeBSD.org Subject: boot fails on Table SSDT at 0x... From: "Julian H. Stacey" Organization: http://berklix.eu BSD Linux Unix Consultants, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.eu/free/ X-From: http://www.berklix.eu/~jhs/ Date: Sat, 26 Nov 2016 18:57:06 +0100 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 17:57:35 -0000 Hi current@FreeBSD.org I was running FreeBSD lapr.js.berklix.net 12.0-CURRENT FreeBSD 12.0-CURRENT #12753: Tue Nov 22 23:31:24 CET 2016 jhs@lapr.js.berklix.net:/data/release/12.0-CURRENT/usr/src/sys/amd64/compile/LAPR.small amd64 I updated to .ctm_status src-cur 12757 .svn_revision 309126 did a make world, built a new custom kernel with same config as before & now laptop boot fails after Table SSDT at 0x... ACPI: No SRAT table found I took a pic of frozen screen, & I have svn here, I need to research & provide more info to whoever ? so this just initial info to whoever's working in the area. Debug suggestions & syntax welcome. I'll build a generic kernel next. If I may be slow responding, sorry, DSL modem problems here too, hence getting an initial error report out while I can. Cheers, Julian -- Julian Stacey, BSD Linux Unix Sys Eng Consultant Munich Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable. http://berklix.eu/brexit/#stolen_votes From owner-freebsd-current@freebsd.org Sat Nov 26 18:38:56 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2AFD5C5796B for ; Sat, 26 Nov 2016 18:38:56 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 DV Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 14A50114 for ; Sat, 26 Nov 2016 18:38:56 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from Xins-MBP.ut.rhv.delphij.net (unknown [IPv6:2601:646:8882:752a:5d7a:6033:e9d4:859d]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 8A9A91193B; Sat, 26 Nov 2016 10:38:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1480185535; x=1480199935; bh=e2Cjb7OLLY9uYopfthgNNuCd/pC7EswC2+zJ3V0lun4=; h=Cc:To:From:Subject:Date; b=1iNTtZcSpj2kXZxgtRP/IaVCPD5JcNg+fvkVAPLU8dFTMl3q4n0zNCV8AHdQwlPig TVf1tsJdrBM8vNmZ2nfPtNsJ0OqjO3Hfek2tpcuESymPgKGpIYpS8QlrWPq7JDomUO DnzoJwv6VSbjwxWLtvaoW18ImtIXDZMpKMifKsno= Cc: d@delphij.net To: FreeBSD Current From: Xin Li Subject: Panic with some recent changes (between r309016 and r309184) Message-ID: Date: Sat, 26 Nov 2016 10:38:49 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lFwOMsre2GFQDVGsG5DijhhftEHOr9ooA" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 18:38:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lFwOMsre2GFQDVGsG5DijhhftEHOr9ooA Content-Type: multipart/mixed; boundary="emB0JaVMfQppGrGDPFUpxVvHmKc85dm7V"; protected-headers="v1" From: Xin Li To: FreeBSD Current Cc: d@delphij.net Message-ID: Subject: Panic with some recent changes (between r309016 and r309184) --emB0JaVMfQppGrGDPFUpxVvHmKc85dm7V Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Is this known? The traceback: panic: vm_page_assert_xbusied: page 0xfffff807fae225b0 not exclusive busy @ /usr/src/sys/vm/vm_pager.c:263 cpuid =3D 5 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0a528ea620 vpanic() at vpanic+0x186/frame 0xfffffe0a528ea6a0 kassert_panic() at kassert_panic+0x126/frame 0xfffffe0a528ea710 vm_pager_assert_in() at vm_pager_assert_in+0x6f/frame 0xfffffe0a528ea740 vm_pager_get_pages_async() at vm_pager_get_pages_async+0x26/frame 0xfffffe0a528ea780 vn_sendfile() at vn_sendfile+0xc85/frame 0xfffffe0a528ea9e0 sys_sendfile() at sys_sendfile+0x11a/frame 0xfffffe0a528eaa70 amd64_syscall() at amd64_syscall+0x2f9/frame 0xfffffe0a528eabf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0a528eabf0 --- syscall (393, FreeBSD ELF64, sys_sendfile), rip =3D 0x8040eb47a, rsp = =3D 0x7fffffffea58, rbp =3D 0x7fffffffeb00 --- KDB: enter: panic Cheers, --emB0JaVMfQppGrGDPFUpxVvHmKc85dm7V-- --lFwOMsre2GFQDVGsG5DijhhftEHOr9ooA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYOda8AAoJEJW2GBstM+nsdOkQAIenAUjyaIcQpl6N64y7rTct 657L6D0SiJ4RX66ubK679w/9VveItcj62Aimpt32va24GzIQPdqQU4OvuuZC27GY 9oAWqVwjffJmt57RXHEDp0RfhAi/rdQw+L2TEEzhvYiJD9mVrXu2hkmRMfQJ9dLd mHv0eEjGD6SuUL1JgUtQxeQ5+3iqhwDCFzzw9PEBuS9oOnQi5Ry2I7DRsxRUxiBi llBBverQhzsTWpTyYIfJTWt2o0PhNdLi5iYNHx5sggmqXTC8x3Wn8MO4y4QsYyVT L2dabNwsCYmKVis9iRGUbcFUhwhyVx5m7Vt2t6Dr25J1DdhCXtrnAY4pI6CUO+jn CmaXFi1u5GQ0kKRjgnJdBTsKks9sks8t8T0sZyjWb9XGuvkEBi5wCxffkSJzd2HP EVxJ/Drj2fj+bEWaFz9JOGwZmCMexr6Yc9AX5tTQPRKlakDIjKgi5gXe1yz2+2kc ARhSxV63LA2/kNxtD7jZPWamZJChb+dKlZL4LJofDY0Tk2m34TT1+kiHkVJdNqno cwAIXG6ijYuobkebLACGvNokV1SUSPqEl4CtEfG6NSU566eNpDvQ1eXOrKk1pKqW RSGYvmF8pvnZWrj3Dh8SVPkJGB9XOfpVvYodTcsISazB2sqLf9JtWcuMKRxu18rq dc2O3WLIRwSFrYCQY/nW =FZJD -----END PGP SIGNATURE----- --lFwOMsre2GFQDVGsG5DijhhftEHOr9ooA-- From owner-freebsd-current@freebsd.org Sat Nov 26 18:39:47 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 00F6DC57A22 for ; Sat, 26 Nov 2016 18:39:47 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id E1B1E25A for ; Sat, 26 Nov 2016 18:39:46 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id E11ABC57A20; Sat, 26 Nov 2016 18:39:46 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E0CEAC57A1F for ; Sat, 26 Nov 2016 18:39:46 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 A52B7258 for ; Sat, 26 Nov 2016 18:39:46 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cAht1-0003HC-Mg; Sat, 26 Nov 2016 21:39:43 +0300 Date: Sat, 26 Nov 2016 21:39:43 +0300 From: Slawa Olhovchenkov To: Adrian Chadd Cc: "current@freebsd.org" Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161126183943.GI99742@zxy.spb.ru> References: <20161126092124.GM57876@zxy.spb.ru> <20161126173753.GH99742@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 18:39:47 -0000 On Sat, Nov 26, 2016 at 09:44:49AM -0800, Adrian Chadd wrote: > The ACPI SRAT parsing code - sys/x86/acpica/srat.c . > > I'd start by enabling bootverbose - adds one echo (SLIT.Localities and > the table); adds CPU affinity info (legacy, XAPIC, ACPI) and other > locality stuff. I am use r308809 of HEAD. From owner-freebsd-current@freebsd.org Sat Nov 26 21:49:02 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E8AA9C576E8 for ; Sat, 26 Nov 2016 21:49:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id A6967879 for ; Sat, 26 Nov 2016 21:49:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id A59B4C576E7; Sat, 26 Nov 2016 21:49:02 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A5015C576E5 for ; Sat, 26 Nov 2016 21:49:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A465862 for ; Sat, 26 Nov 2016 21:49:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x22a.google.com with SMTP id c21so168723723ioj.1 for ; Sat, 26 Nov 2016 13:49:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JaNJQIn7ys9xBvJPIf7R8JCSmICDW1eyrgJ6qy65cZA=; b=YbwyxFYKM2ICsSd0b3OJx23BkbgRyyVFLpT/BX+EkZcY24+WI+KI3nji5DetGwv6Wv 2Mbc6AQAInpmP7T1NNUZWhGEGBhZIOVq96jGYyMuOWA+JCw3nn3nfu2S8yX1N/nM+l/C YsZecYYP4VtgbZQmoo8IufE7bYNr5RQNwRQEX6LHpPQxCZMk3uSxj03BGRloVe9OV/H4 +XBB7FWvxA7TKR66BhX6SQ5zWKsMPR2UkUBbrWU5Y0na2RhoeIxaaIIbXbOzA1KMeVwQ ZryTczPj4YSgqaTnJ5q8MIbNpGOPUlyTSSZKrqxP0QwdC8zJEbn1gWcyFI5Mn1SK7lGf gN7w== 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; bh=JaNJQIn7ys9xBvJPIf7R8JCSmICDW1eyrgJ6qy65cZA=; b=QWRU3reSEDsIOq/0jd1kZwSZa2bZlYSFH/vXYaDjf60mUcf8PYz3TE0pDze0vysvZf WqzdsV676H0O1WxnhLCmj/tFcLQjJ10URTnq6QPAe/D+SEmHXqAsQ2Ic1unMzBAsfmX8 R1CAwMq0fU/iBeFaI1Epfr3zB2OQujWAr0FZdqwYTCvpDnz0MaJ7Qfl4486aDJi9cbgq 8ZlwQzTOmAnj3r+aHDNN0yk3VkL+8Rl8+ZQ5CdH885/q1YkyQ0ha51cwJBXXM00tiLqz Oz4lqp7jAecYdUZgAQXCE98g9+na38+NGqnpprFTFF5Pv3W3tWuZ7H2F2pzrjEeYkLw9 d/tA== X-Gm-Message-State: AKaTC03aXFmPvLieaVRpsWCNnP50vKin34DSlrgvOumuRhNZM24YYR6PYuOCr14vEB/2FB8CLXfyzor+wvjriw== X-Received: by 10.36.58.85 with SMTP id m82mr12309865itm.29.1480196941587; Sat, 26 Nov 2016 13:49:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.39.134 with HTTP; Sat, 26 Nov 2016 13:49:00 -0800 (PST) In-Reply-To: <20161126183943.GI99742@zxy.spb.ru> References: <20161126092124.GM57876@zxy.spb.ru> <20161126173753.GH99742@zxy.spb.ru> <20161126183943.GI99742@zxy.spb.ru> From: Adrian Chadd Date: Sat, 26 Nov 2016 13:49:00 -0800 Message-ID: Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD To: Slawa Olhovchenkov Cc: "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 21:49:03 -0000 Ok. So boot verbose and let's see what it says. -adrian On 26 November 2016 at 10:39, Slawa Olhovchenkov wrote: > On Sat, Nov 26, 2016 at 09:44:49AM -0800, Adrian Chadd wrote: > >> The ACPI SRAT parsing code - sys/x86/acpica/srat.c . >> >> I'd start by enabling bootverbose - adds one echo (SLIT.Localities and >> the table); adds CPU affinity info (legacy, XAPIC, ACPI) and other >> locality stuff. > > I am use r308809 of HEAD. From owner-freebsd-current@freebsd.org Sat Nov 26 21:51:42 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C332EC5785D for ; Sat, 26 Nov 2016 21:51:42 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id AE881BF9 for ; Sat, 26 Nov 2016 21:51:42 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id ADE9EC5785C; Sat, 26 Nov 2016 21:51:42 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD936C5785B for ; Sat, 26 Nov 2016 21:51:42 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 67B1FBF8 for ; Sat, 26 Nov 2016 21:51:42 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cAksl-0008sb-KM; Sun, 27 Nov 2016 00:51:39 +0300 Date: Sun, 27 Nov 2016 00:51:39 +0300 From: Slawa Olhovchenkov To: Adrian Chadd Cc: "current@freebsd.org" Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161126215139.GJ99742@zxy.spb.ru> References: <20161126092124.GM57876@zxy.spb.ru> <20161126173753.GH99742@zxy.spb.ru> <20161126183943.GI99742@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 21:51:42 -0000 On Sat, Nov 26, 2016 at 01:49:00PM -0800, Adrian Chadd wrote: > Ok. So boot verbose and let's see what it says. See first message: it's already verbose boot. Yes, only 3 lines. > > On 26 November 2016 at 10:39, Slawa Olhovchenkov wrote: > > On Sat, Nov 26, 2016 at 09:44:49AM -0800, Adrian Chadd wrote: > > > >> The ACPI SRAT parsing code - sys/x86/acpica/srat.c . > >> > >> I'd start by enabling bootverbose - adds one echo (SLIT.Localities and > >> the table); adds CPU affinity info (legacy, XAPIC, ACPI) and other > >> locality stuff. > > > > I am use r308809 of HEAD. From owner-freebsd-current@freebsd.org Sat Nov 26 21:55:17 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 17C9BC57B7C for ; Sat, 26 Nov 2016 21:55:17 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id EA407F0C for ; Sat, 26 Nov 2016 21:55:16 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id E98DFC57B7A; Sat, 26 Nov 2016 21:55:16 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E9346C57B79 for ; Sat, 26 Nov 2016 21:55:16 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B27A5F0A for ; Sat, 26 Nov 2016 21:55:16 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x22b.google.com with SMTP id j65so174051490iof.0 for ; Sat, 26 Nov 2016 13:55:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Sj2VYiHXj9ffTL0xWHyKbeJU8XGkgZRNnRGsE7x/PZQ=; b=Tk6zJEWQlTDBeF0en2SrgSMn9DbDBEug7+okqhizP9JJD3Q51RK1+oYH36q2qWVLr2 MPppmeL+c/j1Xkp2WqbbebBDgcR320d8EIfV0HR4thF258seApV2rkxzswsEvCu344AD KUowhV8Chzqxlj7OsAmDFCNsd0YTMvz6uhbYa+0XIbK2ISc05Y/xEEUVPt42b87015Ma Px5QAXx5FuuMUokwPztKqIkNOAP1/L21xRDcSvWLxEEzyWGEMpSwyIHKjwIlNcv+hth9 6eZTPvbPpmn/UzTyEVc52/jnHi9EQ0r76mUVnMK82koYt2WL+gVtXFZCQ4p/3u/fqn0Z Tk1Q== 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; bh=Sj2VYiHXj9ffTL0xWHyKbeJU8XGkgZRNnRGsE7x/PZQ=; b=ITZ7GKU7ac4zY9RaAGp8EYnd01VirmAQ73IvxctTHt6/BcP7a/p7wNxaid1hdvOmq0 2rONaCv7O6DmwnrwQ/+6ftBEvQ1LJBuxc1UrFylacXufrexrR1ghc0SuQFJ6G3nJsou+ 2ww03DmO+lKTsHwUrRPybLSyjI0Y5byrBa+DMOnggcTuHrY7TZCKJNhxGUFVhYIlQJPK hG4zoJu3bg3ipLWyzKqlsSWYVGRvHWOWmVPuxRt21XJU8Et5kmHA2zlC2/Ht9mWrNYfD uCUpYe2MJyRGUL1Lj+T1AzV7It7bcq1di3Pxeey4omzR5Gt56xcWfXbnSOFGibagk2TI PbTQ== X-Gm-Message-State: AKaTC03gwxw72b4dNpGFfY/eskCpiHogrp1DueC1xDS23PI+xQ+0RMN431+QF3cggKkvP9YTq3adKH7Y4IARXA== X-Received: by 10.107.192.194 with SMTP id q185mr11722517iof.129.1480197316099; Sat, 26 Nov 2016 13:55:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.39.134 with HTTP; Sat, 26 Nov 2016 13:55:14 -0800 (PST) In-Reply-To: <20161126215139.GJ99742@zxy.spb.ru> References: <20161126092124.GM57876@zxy.spb.ru> <20161126173753.GH99742@zxy.spb.ru> <20161126183943.GI99742@zxy.spb.ru> <20161126215139.GJ99742@zxy.spb.ru> From: Adrian Chadd Date: Sat, 26 Nov 2016 13:55:14 -0800 Message-ID: Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD To: Slawa Olhovchenkov Cc: "current@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 21:55:17 -0000 ok, hm. then i don' know offhand, not without putting in printf debugging. :) -a On 26 November 2016 at 13:51, Slawa Olhovchenkov wrote: > On Sat, Nov 26, 2016 at 01:49:00PM -0800, Adrian Chadd wrote: > >> Ok. So boot verbose and let's see what it says. > > See first message: it's already verbose boot. > Yes, only 3 lines. > >> >> On 26 November 2016 at 10:39, Slawa Olhovchenkov wrote: >> > On Sat, Nov 26, 2016 at 09:44:49AM -0800, Adrian Chadd wrote: >> > >> >> The ACPI SRAT parsing code - sys/x86/acpica/srat.c . >> >> >> >> I'd start by enabling bootverbose - adds one echo (SLIT.Localities and >> >> the table); adds CPU affinity info (legacy, XAPIC, ACPI) and other >> >> locality stuff. >> > >> > I am use r308809 of HEAD. From owner-freebsd-current@freebsd.org Sat Nov 26 21:59:18 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96817C57C7B for ; Sat, 26 Nov 2016 21:59:18 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8121BD5 for ; Sat, 26 Nov 2016 21:59:18 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id 7D7DAC57C7A; Sat, 26 Nov 2016 21:59:18 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7D1FBC57C79 for ; Sat, 26 Nov 2016 21:59:18 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (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 3ECE0D4 for ; Sat, 26 Nov 2016 21:59:18 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cAl08-00096k-9u; Sun, 27 Nov 2016 00:59:16 +0300 Date: Sun, 27 Nov 2016 00:59:16 +0300 From: Slawa Olhovchenkov To: Adrian Chadd Cc: "current@freebsd.org" Subject: Re: Enabling NUMA in BIOS stop booting FreeBSD Message-ID: <20161126215916.GK99742@zxy.spb.ru> References: <20161126092124.GM57876@zxy.spb.ru> <20161126173753.GH99742@zxy.spb.ru> <20161126183943.GI99742@zxy.spb.ru> <20161126215139.GJ99742@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 21:59:18 -0000 On Sat, Nov 26, 2016 at 01:55:14PM -0800, Adrian Chadd wrote: > ok, hm. then i don' know offhand, not without putting in printf debugging. :) I am not expert in this code, I am need you patches for printf debugging. > On 26 November 2016 at 13:51, Slawa Olhovchenkov wrote: > > On Sat, Nov 26, 2016 at 01:49:00PM -0800, Adrian Chadd wrote: > > > >> Ok. So boot verbose and let's see what it says. > > > > See first message: it's already verbose boot. > > Yes, only 3 lines. > > > >> > >> On 26 November 2016 at 10:39, Slawa Olhovchenkov wrote: > >> > On Sat, Nov 26, 2016 at 09:44:49AM -0800, Adrian Chadd wrote: > >> > > >> >> The ACPI SRAT parsing code - sys/x86/acpica/srat.c . > >> >> > >> >> I'd start by enabling bootverbose - adds one echo (SLIT.Localities and > >> >> the table); adds CPU affinity info (legacy, XAPIC, ACPI) and other > >> >> locality stuff. > >> > > >> > I am use r308809 of HEAD. From owner-freebsd-current@freebsd.org Sat Nov 26 23:19:29 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9453AC575DD for ; Sat, 26 Nov 2016 23:19:29 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0056.outbound.protection.outlook.com [207.46.100.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 33F66929; Sat, 26 Nov 2016 23:19:28 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YQBPR01MB0180.CANPRD01.PROD.OUTLOOK.COM (10.169.141.138) by YQBPR01MB0177.CANPRD01.PROD.OUTLOOK.COM (10.169.141.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.13; Sat, 26 Nov 2016 23:19:19 +0000 Received: from YQBPR01MB0180.CANPRD01.PROD.OUTLOOK.COM ([10.169.141.138]) by YQBPR01MB0180.CANPRD01.PROD.OUTLOOK.COM ([10.169.141.138]) with mapi id 15.01.0747.015; Sat, 26 Nov 2016 23:19:19 +0000 From: Rick Macklem To: Konstantin Belousov CC: Alan Somers , FreeBSD CURRENT Subject: Re: NFSv4 performance degradation with 12.0-CURRENT client Thread-Topic: NFSv4 performance degradation with 12.0-CURRENT client Thread-Index: AQHSRhIPtzL8Jj0C/0q6PJtKKLQgMaDn2GqAgAA8DvaAAGR2gIAAPUCRgACtAACAAEDk+4AAF32AgAIr5lw= Date: Sat, 26 Nov 2016 23:19:19 +0000 Message-ID: References: <20161124090811.GO54029@kib.kiev.ua> <20161125084106.GX54029@kib.kiev.ua> , <20161125135725.GD54029@kib.kiev.ua> In-Reply-To: <20161125135725.GD54029@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-office365-filtering-correlation-id: d7cbc0f0-5feb-476c-dec9-08d41652a64e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:YQBPR01MB0177; x-microsoft-exchange-diagnostics: 1; YQBPR01MB0177; 7:MLbEy7c2EqOeZIQcMF9hHAqv0yfPWZ2tdmmAQ30VuprSfgRd2TOtTgP4g6Ak64gVCdAdE5qAnbu6sGwyRNgdtG4RfrXJ6P57Xo5Q22wJCTLkTa8wtG68LCwKeA8KEL8QHvlb33H7iYuHRg5Gu6TzdhrPZUmNGlXsjXI6v6fK8E4lYwErbEBaI08M65C1dwYrbs2Dhgp2FRWnST3Geo2cAw7sX063ypRrCH+0NeZGUDOgkizBqIU0yTmw+2K484SuB24fGuvDzyVYYgVi2yrPQl3uPX2JhQSRtJJhD89cN+/px2G7mhrLPIL5vSbm4Wl0H0C2rSQEsrRsQFqYgPETxUENwjl04Mh0G18OrF0xEppgyoEAl2S4/44NeDf5+MnIQNbaHrB0hOSNIw8ZtoLMCSukopu5anFUM1masB9WoMnYnrHjASWNk9MeA/ztaN765eLhRVVsvDqbQZmSVOpocA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(6040361)(6045199)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(6061324)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(2016111802025)(6043046)(6042181); SRVR:YQBPR01MB0177; BCL:0; PCL:0; RULEID:; SRVR:YQBPR01MB0177; x-forefront-prvs: 0138CD935C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(189002)(199003)(74316002)(74482002)(305945005)(189998001)(9686002)(3280700002)(7846002)(102836003)(105586002)(5660300001)(8936002)(81166006)(68736007)(106116001)(81156014)(106356001)(8676002)(97736004)(3660700001)(2950100002)(92566002)(76176999)(101416001)(1411001)(50986999)(6916009)(86362001)(39060400001)(110136003)(93886004)(2906002)(122556002)(54356999)(7696004)(33656002)(4326007)(77096006)(38730400001)(2900100001)(6506003)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:YQBPR01MB0177; H:YQBPR01MB0180.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Nov 2016 23:19:19.8047 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR01MB0177 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 23:19:29 -0000 Konstantin Belousov wrote: [stuff snipped] >I thought that the issue was in tracking any opens and mmaps, but from thi= s >reply it is not that clear. Do you need callback when all opens and mmaps >have ended, or only opens and mmaps for write ? If later, we already have >a suitable mechanism VOP_ADD_WRITECOUNT(). Not quite. The NFSv4 client needs to Close the NFSv4 Open after all I/O on the file has been done. This applies to both reads and writes. Since mmap'd files can generate I/O after the VOP_CLOSE(), the NFSv4 client can't do the NFSv4 Close in VOP_CLOSE(). Since it can't do it then, it waits until VOP_INACTIVE() to do the NFSv4 Cl= ose. This might be improved by: - A flag that indicates that an open file descriptor has been mmap()d, whic= h VOP_CLOSE() could check to decide if it can do the NFSv4 Close. (ie. It could do the NFSv4 Close if the file descriptor hasn't been mmap(= )d.) - If the system knows when mmap()d I/O is done (the process has terminated?= ), it could do a VOP_MMAP_IO_DONE() and the NFSv4 client would do the NFSv4 = Close in it. --> I don't know if this is feasible and I suspect if it could be done, t= hat it would usually happen just before VOP_INACTIVE(). { This case of nullfs ca= ching was an exception, I think? } Does this clarify it? rick